Move .lang files to separate directory

That will require some fiddling within the code. We should no longer use relative paths in all bits of code.
Intended behaviour: default search directory for .lang files should be predefined. and not implied to be the same as binary directory.
Current behaviour: Statula searches current directory for .lang file. This caused minor issue with #6 .

Done in 5bb374153bedf744c349f557e26202f607f0af3b. Not closing this for now in case there are some issues.


Update to Spring 5.2.4.RELEASE_1

5.2.4.RELEASE_1
Is the current OSGi Version of the Spring framework as provided by the Apache ServiceMix team. Update to this version.

Done!


Feature/add basic UI

OOP school library: add basic UI
Hi good reviewer,

These are the project requirements for this milestone:

Create a app.rb file that will serve as your console app entry-point. Write methods to do the following:

List all books.
List all people.
Create a person (teacher or student, not a plain Person).
Create a book.
Create a rental.
List all rentals for a given person id.

In main.rb define the entry point method called main that is invoked at the end of the file. This method does the following:

Present the user with a list of options to perform.
Lets users choose an option.
If needed, ask for parameters for the option.
Have a way to quit the app.

Thank you @sja-thedude.


Cy-tests Repositories modals

Description
This PR covers:
THEEDGE-2536 - [UI] Add test to cover RemoveModal.js
THEEDGE-2535 - [UI] Add test to cover EditModal.js
THEEDGE-2534 - [UI] Add test to cover AddModal.js
Fixes # (issue)
Type of change
What is it?

[ ] Bug fix (non-breaking change which fixes an issue)
[X ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ X] Tests update

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ X] I have added tests that prove my fix is effective or that my feature works
[ X] New and existing unit tests pass locally with my changes
[ X] I run npm run lint:js:fix to check that my code is properly formatted

Codecov Report
Base: 30.68% // Head: 30.68% // No change to project coverage :thumbsup:

Coverage data is based on head (1f9948c) compared to base (e2b2195).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #539   +/-   ##
=======================================
  Coverage   30.68%   30.68%
=======================================
  Files         125      125
  Lines        2656     2656
  Branches      806      806
=======================================
  Hits          815      815
  Misses       1689     1689
  Partials      152      152

Impacted Files
Coverage Δ

src/Routes/Repositories/modals/RemoveModal.js
0.00% <ø> (ø)

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

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


repo: Dev 1.22.6

Signed-off-by: Ryan Northey<EMAIL_ADDRESS>Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

gh action is failing due to clang versioning - seems like there are some workarounds here https://github.com/circleci/circleci-images/issues/430

/docs

@mattklein123 we are trying to fix CI for this branch elsewhere (https://github.com/envoyproxy/envoy/pull/23842) but the change in this PR should probably already have happened so thinking we might force land this


WIP: Implementation of to_string datetime function

Converts given timestamp into given string format.
Signed-off-by: Girjesh Rajoria<EMAIL_ADDRESS>

the _fn_to_string::operator contain a repeat pattern
if (std::regex_search(res, m, ...))
{
....
.... res = std::regex_replace( ..... ) ;
}
per each new row, the operator calls to each of regex_search , upon it's true, a replace is executed.
in the case of new format (dynamic) it need to iterate all of these /if (std::regex_search(res, m, ...))/
but in the case it's fix string (the common use case), it's not efficient to iterate each of these std::regex_search
it should be done once.
one way to that is to use vector of replace functions, to establish it once and executed per each new row, this will save all the call regex_search
bellow a piece of code to demonstrate that
std::vector<std::function<std::string(std::string&,std::smatch,std::regex)> > func_vector;

auto my_f = [&](std::string& res,std::smatch mtc,std::regex rg)
{
  res = std::regex_replace(res, rg, std::to_string(new_ptime.date().year()));
  return res;
};

func_vector.push_back( my_f );

the functions-vector should build once on to-string-operator construction similar to like-operator/to-timestamp-operator

the operator contains only the dynamic use case i.e. it calls prepare per each new row.
the syntax definitions, should contain 2 rules
one for constant format
and the other for dynamic format
and to attach the correct operator per each rule.


remove URL column from all tables

Changes done,

Removed URL column
Added Hyperlinks

Fix #8
Kindly Review.

Looks good!


Stuck with curl HTTP/0.9 issue

Hi- new user so sorry if I'm doing something stupid.
I've tried lots of combinations for the proxy Firefox 55/58/102/105, Chrome 58, iOS 111/13
using curl to https://www.yahoo.com and https://www.bing.com with and without the curl --http2 flag and I always get the curl HTTP/0.9 error
(with Firefox 102)
$ curl -v -k --proxy http://localhost:8080 https://www.bing.com --http2
*   Trying <IP_ADDRESS>:8080...
* Connected to localhost (<IP_ADDRESS>) port 8080 (#0)
* allocate connect buffer
* Establish HTTP proxy tunnel to www.bing.com:443
> CONNECT www.bing.com:443 HTTP/1.1
> Host: www.bing.com:443
> User-Agent: curl/7.88.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
< Date: Thu, 24 Aug 2023 13:29:59 GMT
< Transfer-Encoding: chunked
* Ignoring Transfer-Encoding in CONNECT 200 response
<
* CONNECT phase completed
* CONNECT tunnel established, response 200
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=localhost
*  start date: Aug 24 12:43:45 2023 GMT
*  expire date: Aug 23 12:43:45 2024 GMT
*  issuer: CN=localhost
*  SSL certificate verify result: self-signed certificate (18), continuing anyway.
* using HTTP/1.x
> GET / HTTP/1.1
> Host: www.bing.com
> User-Agent: curl/7.88.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Received HTTP/0.9 when not allowed
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (1) Received HTTP/0.9 when not allowed

Thank you for your report. There did encounter an issue with the code while handling ALPN. We have resolved it and submitted the fix. You can retry it with the latest release.


Fix wrong instruction of TFLite iOS profiling tool

Change to "Product > Profile" from "Product > Scheme"

@googlebot I signed it!

@yyoon could you review this PR?

Thanks, @hajuho :)

@abattery @yyoon nice to see you again :)


Distinction between syllabus and textbook

Re: syllabus.md, I tend to think of inferentialthinking.com as the textbook and data8.org/ as the syllabus. The latter links to the textbook, assignments, and all other course info. Should data8.org be mentioned here?

Good point - I'll take a pass through and see how I can clean that up, will ping here when it's done!

latest version more explicitly separates these two, so I think I'll close this, but reopen if you have other ideas!


Restore accidentally removed file

Accidentally removed "bin/Notebooks/PyRadiomics Example.ipynb", restoring.

@JoostJM, this should remove the accidentally removed file in #236


Fix Alembic Migration: has table checks

Feature or Bugfix

Bugfix

Detail

Fix has_table() check to ensure dropping the tables if the exists as part of alembic migration upgrade

Relates

https://github.com/data-dot-all/dataall/issues/1165

Security
Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

Does this PR introduce or modify any input fields or queries - this includes
fetching data from storage outside the application (e.g. a database, an S3 bucket)? No

Is the input sanitized? N/A
What precautions are you taking before deserializing the data you consume? N/A
Is injection prevented by parametrizing queries? N/A
Have you ensured no eval or similar functions are used? N/A

Does this PR introduce any functionality or component that requires authorization? No

How have you ensured it respects the existing AuthN/AuthZ mechanisms? N/A
Are you logging failed auth attempts? N/A

Are you using or adding any cryptographic features? No

Do you use a standard proven implementations? N/A
Are the used keys controlled by the customer? Where are they stored? N/A

Are you introducing any new policies/roles/users? No

Have you used the least-privilege principle? How? N/A

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

Check passed: All 'extra' tables are not created after 'make upgrade-db' of the clean DB
Problem. make generate-migrations creates a non empty migration. It means, smth was not tracked by our migrations, so maybe, we have to create another migration script.
@dlpzx  have a look please

def upgrade():
    # ### commands auto generated by Alembic - please adjust! ###
    op.alter_column('dataset_lock', 'isLocked',
               existing_type=sa.BOOLEAN(),
               nullable=True)
    # ### end Alembic commands ###

def downgrade():
    # ### commands auto generated by Alembic - please adjust! ###
    op.alter_column('dataset_lock', 'isLocked',
               existing_type=sa.BOOLEAN(),
               nullable=False)
    # ### end Alembic commands ###

@noah-paige good with me

@noah-paige good with me

Should be fixed now

Could you please add it as a new migration?
E.g. customer may want to upgrade their current DB (without dropping) and then create their own migrations.
Changes in past migrations won't help here(

Could you please add it as a new migration? E.g. customer may want to upgrade their current DB (without dropping) and then create their own migrations. Changes in past migrations won't help here(

For the has table fix it is only an issue on fresh deployments right? For existing data.all deployments that then run that script it should be fine
For the dataset lock we aren't changing the DB or the way we create the dataset_locks table - instead we are changing the model class object for DatasetLock() so I think it should be fine here right?

Hm, I see. Ok, then it should be fine.


Added support for static bokeh png rendering

The bokeh 0.12.6 release will add static png rendering support and this PR exposes this support at the bokeh renderer level. Because rendering to png is so slow this is not particularly useful for working interactively but will be very useful for generating output which can be embedded in any document, including the thumbnails for our gallery.

Happy to merge this simple addition. My only worry is we need to keep testing it to make sure it continues to work as the Bokeh export API evolves. Might be worth having a unit test that just checks that a PNG file is generated (without trying to check the contents).

Might be worth having a unit test that just checks that a PNG file is generated (without trying to check the contents).

Sounds reasonable.

I suppose getting this unit tests working means updating the bokeh version on Travis. Alternatively, we could annotate such tests like we do with 'optional' to skip them for now...

Alternatively, we could annotate such tests like we do with 'optional' to skip them for now...

It is marked optional, just like the other bokeh renderer tests.

It is marked optional, just like the other bokeh renderer tests.

We need a new annotation as Travis runs all tests (doesn't use -a '!optional') right now. I'm proposing an annotation that means 'don't run on travis yet' or 'will be run on travis once ready and this annotation is removed'.

I'm proposing an annotation that means 'don't run on travis yet' or 'will be run on travis once ready and this annotation is removed'.

Seems easier to just add a SkipTest that checks the bokeh version for now.

Seems easier to just add a SkipTest that checks the bokeh version for now.

Good idea.

There is no need to ever remove the version check for the SkipTest either. When you say 'for now', I am happy with 'forever'! :-)

The pr builds are green so I'll merge once the push build is green as well.


Support creating a PEX from a venv.

This would close the circle and we have all the infra to do this. Currently resolution from a fixed set of Distributions is buried in PEXEnvirronment but could be lifted out. The Virtualenv class would just need to grow iter_distributions to make all this work. That could be implemented via pkg_resources.WorkingSet() in a subprocess using the venv interpreter since a WorkingSet is an iterator of Distibutions.

The wrinkle here is only dist-info distributions work with PEXes isolation scheme. That isolation scheme requires a wheel name and that can only be reconstructed from a dist-info distribution with a WHEEL metadata file with a Tag entry. If the venv is populated via Pip - a common case to be sure - any sdists are installed via a different scheme that uses egg-info and provides know way to directly derive a wheel name.

I guess the safe option for sdists is to adopt the most specific platfrom tag of the venv's interpreter. That would treat every distribution in the venv installed from an sdist as if it were platform specific even when this was un-true. The upshot would be the resulting PEX file is not as portable as it should be. For example, if the venv constinaed one distribution installed from an sdist that was in fact universal (py2.py3), the PEX created from that venv would only be able to run under the venv interpreter (say CPython 3.9 on Linux). To mitigate surprise, a warning could be emitted for each distribution gathered into the PEX that was derived from an sdist and not a wheel.

To mitigate surprise, a warning could be emitted for each distribution gathered into the PEX that was derived from an sdist and not a wheel.

That sounds reasonable.
Maybe point out that building a wheel beforehand can provide a workaround. It's likely not obvious to everyone that you can prebuild an sdist and have Pex use the resulting wheel.

It's likely not obvious to everyone that you can prebuild an sdist and have Pex use the resulting wheel.

It might not be obvious, but Pex is not involved here. They created the venv with some tool. Pip, Poetry - who knows. What exactly would you say to a Poetry user for example? (I don't think there is actually an answer to that one). How about a Pip user? (There is an answer to that one).

I like providing a useful error message. I really don't like educating the world and misleading them as a result down to some arbitrary level of detail. When things get complex, they get complex, The user needs to buck up and read at that point. I guess the real issue is where to draw the line. I favor simple, totally correct advice. I think you favor advice that solves some % of users problems right away like a stack overflow answer thats mostly right? IOW better to get some % of users unblocked thatn worry about confusing some smaller % of users?

They created the venv with some tool. Pip, Poetry - who knows. What exactly would you say to a Poetry user for example? (I don't think there is actually an answer to that one). How about a Pip user? (There is an answer to that one).

Thumbs Up.

I really meant for you to answer those. Do you have verbage I'm missing that explains this stuff? If you do and it doesn't lie I'm happy to use it.

I think you favor advice that solves some % of users problems right away like a stack overflow answer thats mostly right? IOW better to get some % of users unblocked thatn worry about confusing some smaller % of users?

Ideally, give the right answer to the majority of users while pointing out this might not be the correct prognosis. You may need to do more digging.
https://github.com/pantsbuild/pants/pull/12107 is a good example of what I think is helpful, including discussion about Pants users being engineers and what we can expect them to know. I like Tom's point about data scientists. The error tries to hedge that these are only two likely culprits. (Although it should probably hedge even more!)
--

What exactly would you say to a Poetry user for example?

Good question. I think I would say something like this:

If you need more portability, consider pre-building the sdist and creating your venv with the resulting wheel file rather than an sdist, such as by installing the requirement {req.project_name} with a local file.

I would not give a guide on how to do this with pip and Poetry, I agree with you there. My intent is to give a hint that can help a motivated user know what direction to take, rather than having to brainstorm the workaround themself.

I've found an obvious-after-the-fact way to stomp out the need for a long-winded partial truth by actually just re-resolving any non-dist-info dists intransitively using the existing machinery so that this can work on all venvs with no exception.


updated build script for unforking of python-openzwave

Description:
Updated build script now that python-openzwave should be operational.
Related issue (if applicable): #817
Also associated with https://github.com/balloob/home-assistant.io/pull/266
Checklist:

[ ] Local tests with tox run successfully.
[ ] TravisCI does not fail. Your PR cannot be merged unless CI is green!
[ ] Fork is up to date and was rebased on the dev branch before creating the PR.
[ ] Commits have been squashed.
If code communicates with devices:

[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

Woohooo ! ! :tada::tada::tada::tada::tada: Really awesome.

The call to sudo is breaking the auto build of Docker because it does not have sudo (already runs as root).

Fixed stuff in #1437

Ah, was slightly worried about that. Thanks for fixing.

Looks like the install script still calls sudo. Build still broken.
Docker hub shows the log weird like this
make[1]: Leaving directory '/usr/src/app/build/python-openzwave/openzwave'
sudo /usr/local/bin/python3 setup-lib.py install
make: sudo: Command not found
Makefile:217: recipe for target 'install-lib' failed
make: *** [install-lib] Error 127
Removing intermediate container 8c27285df93e
The command '/bin/sh -c script/build_python_openzwave' returned a non-zero code: 2

Try 3: I will apt-get install sudo in the Dockerfile…

That's a pain. If Try 3 doesn't work I can give you install commands that eliminate the need for the install script. I think it'd just be:
cd openzwave
make install
cd ..
python3 setup-lib.py install
python3 setup-api.py install
python3 setup-manager.py install
python3 setup-web.py install

Try 3 worked. Let's keep it like this. I don't want to have to maintain our own install script.

:+1:  Fantastic.

Docker now gives me this error message:
16-02-28 21:35:09 homeassistant.bootstrap: Error during setup of component zwave
Traceback (most recent call last):
  File "/usr/src/app/homeassistant/bootstrap.py", line 106, in _setup_component
    if not component.setup(hass, config):
  File "/usr/src/app/homeassistant/components/zwave.py", line 175, in setup
    DEFAULT_ZWAVE_CONFIG_PATH),)
  File "/usr/local/lib/python3.4/site-packages/pyozwweb-0.3.0b8-py3.4.egg/openzwave/option.py", line 76, in __init__
    libopenzwave.PyOptions.__init__(self, config_path=config_path, user_path=user_path, cmd_line=cmd_line)
  File "src-lib/libopenzwave/libopenzwave.pyx", line 582, in libopenzwave.PyOptions.__init__ (src-lib/libopenzwave/libopenzwave.cpp:7780)
libopenzwave.LibZWaveException: "LibOpenZwave Generic Exception : Can't find config directory /usr/local/share/python-openzwave/config"

What location does the config live now? Because it would be great if we can create a symlink to /usr/local/share/python-openzwave/config in the Dockerfile to make it just work.

Should be somewhere like /usr/local/lib/python3.4/dist-packages/libopenzwave-0.3.0b8-py3.4-linux-x86_64.egg/config. Symlink sounds like a good idea. I can work on figuring out how to predict that path.

So, the python-openzwave build system does not explicitly install openzwave as its own thing, which is why the config ends up in that annoying location as part of the egg. However, if you were to add:
cd openzwave
make install
cd ..

Then the installation would proceed just fine but the config info would be installed to
/usr/local/etc/openzwave, which must be where the openzwave people have decided to put it. In that case, it'd be really easy to add a symlink for the docker build:
ln -s /usr/local/etc/openzwave /usr/local/share/python-openzwave/config

Should we make that a part of the build script or would that be docker
specific?
On Sun, Feb 28, 2016, 22:07 Nick Touran<EMAIL_ADDRESS>wrote:

So, the python-openzwave build system does not explicitly install
openzwave as its own thing, which is why the config ends up in that
annoying location as part of the egg. However, if you were to add:
cd openzwave
make installcd ..
Then the installation would proceed just fine but the config info would be
installed to
/usr/local/etc/openzwave, which must be where the openzwave people have
decided to put it. In that case, it'd be really easy to add a symlink for
the docker build:
ln -s /usr/local/etc/openzwave /usr/local/share/python-openzwave/config
—
Reply to this email directly or view it on GitHub
https://github.com/balloob/home-assistant/pull/1436#issuecomment-190058710
.

Could we make a symlink to the config in the openzwave folder?
On Sun, Feb 28, 2016, 22:17 Paulus Schoutsen<EMAIL_ADDRESS>wrote:

Should we make that a part of the build script or would that be docker
specific?
On Sun, Feb 28, 2016, 22:07 Nick Touran<EMAIL_ADDRESS>wrote:

So, the python-openzwave build system does not explicitly install
openzwave as its own thing, which is why the config ends up in that
annoying location as part of the egg. However, if you were to add:
cd openzwave
make installcd ..
Then the installation would proceed just fine but the config info would
be installed to
/usr/local/etc/openzwave, which must be where the openzwave people have
decided to put it. In that case, it'd be really easy to add a symlink for
the docker build:
ln -s /usr/local/etc/openzwave /usr/local/share/python-openzwave/config
—
Reply to this email directly or view it on GitHub
https://github.com/balloob/home-assistant/pull/1436#issuecomment-190058710
.

Well in balloob/home-assistant.io/pull/266 I actually took out the build script and just listed the commands to run so already I think the build script is docker-specific. Personally, I like running checkinstall instead of make install so I wanted to keep that option.

Could we make a symlink to the config in the openzwave folder?

/usr/local/etc/openzwave is the config folder on my build that I just ran.

But the data is copied from somewhere when running make install. Could we
link to the install files?
On Sun, Feb 28, 2016, 22:25 Nick Touran<EMAIL_ADDRESS>wrote:

Well in balloob/home-assistant.io#266
https://github.com/balloob/home-assistant.io/pull/266 I actually took
out the build script and just listed the commands to run so already I think
the build script is docker-specific. Personally, I like running
checkinstall instead of make install so I wanted to keep that option.
Could we make a symlink to the config in the openzwave folder?
/usr/local/etc/openzwave is the config folder on my build that I just
ran.
—
Reply to this email directly or view it on GitHub
https://github.com/balloob/home-assistant/pull/1436#issuecomment-190062528
.

Ohhh, I see what you're asking. Yes definitely. On my raspberry pi this is exactly what I did and it works great:
config_path: /home/pi/python-openzwave/openzwave/config
That's a good option for docker.


Add quiet dry run

We need just a list of the files for some Airflow-specific timing improvements.
Ideally we'd split the various puts statements into actual log streams and be able to set log level, but that would be a bigger refactor.

 Look into performance of laminar builds


Silo files wrong in buffer regions for immersed boundaries.

All interior points of immersed boundaries should be set to a constant value to make them clearer in visualizations. This is no longer the case, as shown in the attached photo.

While technically a bug, #496 makes this feature nearly irrelevant, so I'm not sure what direction this should go.

I would merge a PR for this so long as it doesn't make the code more complex.

I mostly meant if it even makes sense to fix, or if this feature could just be removed given the addition of IB markers in the silo files.

It doesn't make much difference to me.

I'll just fix it then. I can't imagine it would add many lines

Or do the reverse and remove the code forcing the flow in the IBM to be stationary... though fixing this seems easier. But being consistent seems to make most sense.

This was an artifact of a Paraview filter

reopening because this appears real (it's also seen in visit).

@Sam-Briney @wilfonba did we decide what to do with this? @Sam-Briney do you plan on fixing it, or leaving it alone?

@sbryngelson I had not planned on making this a high priority since it is possible to overlay the IB markers

Works for me. Closing.


Update Glide 4.7.1

The latest looks to be 4.8.0?
Also, would you mind cleaning up the PR and submitting a single commit?

@tiembo  see #199


Add version information to the specification

Fixed some typos and noted that textDocument/prepareRename is a new 3.12.0 feature.

Thanks


Address possible double switching of RCPs

A scenario may be run for a specific RCP if desired like so:
run_scenario(param_set, domain, RCP)

Underneath, it calls switch_RCPs!() to recreate the domain with the appropriate datasets loaded.
It then calls the generic run_scenario() function.
However, this generic run_scenario() checks the param_set (i.e., the scenario specification) to see if a RCP column exists, and if so, switches to the RCP specified in the scenario spec.
In the usual case, the scenario spec does not specify RCPs so this doesn't impact earlier analyses. But it will cause confusion in future cases, where the user may have a scenario spec with an RCP column, but want to re-run for a different RCP.
A more generic and robust implementation is needed.
https://github.com/open-AIMS/ADRIA.jl/blob/696ce3567fcc18130ef561dd19b739d19263fd5a/src/scenario.jl#L272

I believe addressed as part of #376


Bump to 1.20.2 for a release.

This way we can cut a release with just the changes to the plugin library to allow grpc swift to look at updating things on their end.

@tbkka good to land this and cut a release for the Plugin changes to allow grpc to support both 1.x and 2.x more easily?

Yep, that makes sense.


Joint effort to improve integration between Godot and Blender 2.8

The Blender Foundation announced that the BGE developer Benoit Bolsee will lead work on a new real-time interactive mode for Blender 2.8 (note that BGE itself was removed from Blender for 2.8), and this includes to-be-defined cooperation with us to improve the Blender/Godot workflow.
In Ton Roosendaal's announcement, he mentions:

Related to this work is also to enable good support (export or some kind of integration) for external game engines such as Godot, Armory, Blend4Web, Unreal, Unity, etc.
I especially invite the first three (open source) projects to connect with us to find ways to keep a high level of compatibility.

No specifics are given yet on what this integration would be, and I think Blender expects us to help define it and work on it, so I'm opening this issue to gather our initial thoughts.
Blender devs are more than welcome to chime in too. If/when required, we could also move the discussion to another platform (code.blender.org or anything appropriate).

In parallel, it would be good to outline for Blender devs the current work that we have done already to improve the Blender/Godot workflow.

Godot's Collada Exporter, a Blender plugin that exports scenes to Collada with an implementation that works better for Godot than Blender's default exporter. I won't try to revive the heated debate about whether this implementation is actually better and should replace Blender's default one, the Collada ship has sailed and we're now focusing on the next two points. (This plugin gets maintenance support, but no real development).

glTF 2.0 support. Godot 3.0 implemented support for glTF 2.0, which is in our experience much superior to what Collada offers (and even proprietary exchange formats like FBX) for PBR materials. Having first class support for glTF 2.0 in Blender 2.8, and ensuring that the glTF 2.0 files output by Blender's exporter are well supported by Godot's importer would go a long way to improve the workflow. On our end we keep improving our importer when we hit glTF 2.0 features that we don't properly support.

Finally, the most promising effort so far on our end: a Blender to Godot export plugin, which aims at exporting Blender scenes directly to Godot's scene format, bypassing the need for an asset exchange format like Collada or glTF 2.0, and supporting as much of the common rendering features as possible. It is under heavy development, with @Jason0214 as GSoC student focusing on this project, mentored by @sdfgeoff and @reduz.

@Zireael07 I think that beyond the scope of this issue, or at least low-priority. The goal of Blender's realtime interactive mode is to have output that user can interact with, just like a game. It make more sense if we just focus to Blender -> Godot workflow.

The issue doesn't mention Blender's interactive mode, just 'integration with game engines' though.

I believe we should be able to create meshes as placeholder in Godot and then copy them in Blender and make it into a professional model later.

It would be fantastic if some kind of a workflow can be set up to launch a godot project straight from blender - the way Armory, BDX,blend4web and other addons work!

@Zireael07 that is already mentioned here, last paragraph https://godotengine.org/article/godot-gets-csg-support

I don't mean only CSG, also SurfaceTool, but good catch!

Guys, this issue is for Godot and Blender devs to discuss the technical specifics of what this integration could be, not for end user feature requests...
Exporting CSG scenes will just be outputting a glTF 2.0 file usable in Blender or any other modelling program, it's out of scope of this issue.

Currently importing GLTF files means that they are saved as cycles materials but the exporter can't detect them.
E. g. it's easy to import models from Sketchfab using the plugin but it's not possible to edit them in Blender.
https://github.com/ksons/gltf-blender-importer
https://github.com/KhronosGroup/glTF-Blender-Exporter

Currently importing GLTF files means that they are saved as cycles materials but the exporter can't detect them.
E. g. it's easy to import models from Sketchfab using the plugin but it's not possible to edit them in Blender.
https://github.com/ksons/gltf-blender-importer
https://github.com/KhronosGroup/glTF-Blender-Exporter

If we are sticking with glTF then the exporter needs some serious improvements cause at the moment it's mostly useless for material conversion and stuff.
Probably asking the Blender devs to help with it might be a good idea. Although it might be too much work, configuring the node conversion system.
I think the system would need to automatically bake the material and then export it to Godot using glTF nodes and baked textures.
Have little experience with creating addons in Blender. So I can be wrong but this seems like the simplest solution.

With the Godot -> Blender exporter we will try to make use of as much blender data as possible. Converting cycles or Principled materials should be possible already I think.
What could be interesting, from Blender side, is to provide engines with a bit more information.. most likely what would be useful is stuff like:

Collision information, not just that a mesh is collidable, but also basic collision shapes (sphere, box, etc), etc.
Body information, whether something is rigid body, etc. maybe in a bit more engine friendly way
Navigation information, or something we can more or less use in nav-meshes

This would allow projects being worked on mostly by small teams to use Blender more as a design tool and just export their scenes with most of the work done to Godot.

Navmesh generation in Blender will be a big help. With Blender's features it might be awesome way to create proper Navmesh for complex projects.
@reduz But does Blender even have collision information, and body information.? Has it ever had anything like that.
I would the ability to be able to import rigs since bones will be in Godot soon. But there shouldn't be a problem in that. Softbodies and some basic settings.

Collision information, not just that a mesh is collidable, but also basic collision shapes (sphere, box, etc), etc.
Body information, whether something is rigid body, etc. maybe in a bit more engine friendly way

@reduz @swarnimarun We needed the collision export at Simedis, so exporting physics properties was added really early. Temporarily documented here.
Similarly, exporting rigs was added by @Jason0214 recently, though it has some limitations currently.

Simedis' intention is exactly as Reduz says: use blender as a design tool and export mostly-finished-assets into Godot. At this stage we don't do whole scenes (assets are assembled in Godot), but it would be nice.
At this stage the major thing to figure out is: what is the ideal integration. However, we have to realize that we do not want to rebuild the Godot GUI inside blender. Thus the focus should be on getting things form blender into godot that can't be created inside godot. This includes exporting to godot:

model data
animation data
collision geometry
blender (cycles, eevee) materials into Godot materials
lighting data (including environment settings?)
This is what the GSOC blender-exporter project focus' on.

Also good is anything that allows more complete previewing of this content inside the blender interface, such as:

Preview of godot materials on your blender objects while developing them (ie use godot renderer in blender's viewport - this is intended to be possible, see the 2017 blender conference keynote).
Physics behavior in blender animation simulation should be similar to that in a godot game

Possibly also:

Create tools for assigning godot-specific data such as:

nav-meshes
assigning scripts
I've already tossed some code around, and adding this sort of thing shouldn't be hard.

Complex scenes with linked objects should be handled in a sane way (possibly into multiple files)

Tools to ease the use of this pipeline should also be considered:

Playing a game without needing to manually export (currently at Simedis we automate the build with Make and some semi-intelligent python scripts, but this is hard to set up on Windows).
Ability to start the game engine inside blenders interface and have your assets present.
Performance of the integration (if it takes 30 seconds to start the game, there is a problem)

We are also very excited about the prospect of even better integration between Blender and Unity, since we recently switched to Blender from 3ds max. We have experienced some problems exporting to gltf and getting the correct result in Godot, so this is definitely something that could use an improvement.

As of 2020 January, Godot Engine's glTF2 importer has greatly improved.
For Blender 2.83, there are patches to upgrade Blender's glTF2 import to match Godot Engine's compatibility. https://github.com/KhronosGroup/glTF-Blender-IO/pull/857
Blender 2.81 is able to be used in production too.

For any Blender developers that want some models and a project for stress testing, check out the TPS demo. I recently converted the demo to have the level geometry in multiple files, and I was able to export the level geometry as GLTF just fine (and it works better and takes up less space than Collada DAE by a significant amount).
However, I experienced issues trying to export models with animations to GLTF, so for the moment those are still Collada DAE in the repo. The model is broken when exporting from Blender and importing back into Blender, so it's Blender's fault. Any Blender developer is welcome to take a look at the TPS demo, including by using it to improve Blender's GLTF support, and you are also welcome to submit a pull request to the repo to convert those files to GLTF. It's also possible there are issues with the Blender files, I'm a Blender noob so I wouldn't know, so that's another reason why a PR would be helpful.

Closing the bug since Blender 2.9 is out and both Godot Engine's gltf and Blender's gltf has improved.


After upgrade to v4, storyshots multiSnapshotWithOptions infinitely hangs

Describe the bug
I am currently upgrading my project from Storybook v3 to v4 (coupled with a Webpack 3-->4 and Babel 6-->7 upgrade). Everything is working so far, except for Storyshots. With multiSnapshotWithOptions enabled, the storyshots test will infinitely hang with zero feedback as to why. But, the storyshots work just fine without this option.
To Reproduce
Steps to reproduce the behavior:

Configure storybook and storyshots like demonstrated below.
Run storyshots through Jest.

Expected behavior
Storyshots should be able to run without issue.
Actual behaviour
The test process will hang forever (I have tried waiting up to 5 minutes for feedback multiple times). With the multiSnapshotWithOptions option commented out, the entire storyshots test completes successfully in just 8 seconds.
Code snippets
The test file used to configure the storyshots:
import initStoryshots, { multiSnapshotWithOptions } from "@storybook/addon-storyshots";

initStoryshots({
  configPath: "stories",
  test: multiSnapshotWithOptions(),
});

The stories/config.js file, which is set in the configPath:
import "@babel/polyfill";
import { configure, addDecorator } from "@storybook/react";
import { withKnobs } from "@storybook/addon-knobs";
import decorator from "./StorybookTheme";

const req = require.context(
  "../src",       // path where stories live
  true,           // recursive?
  /.story.jsx$/, // story files match this pattern
);

addDecorator(decorator);
addDecorator(withKnobs);

function loadStories() {
  // iterate on all the stories and require them
  req.keys().forEach(module => req(module));
}

configure(loadStories, module);

System:

OS: Mac OS 10.13.6
Framework: React 16.6.3
Addons: @storybook/addon-storyshots 4.0.11
Version: @storybook/react 4.0.11

Additional context
I have followed steps from the official migration guides on the Internet for the babel upgrade, webpack upgrade and storybook upgrade. I am happy to provide more package versions and sample code as requested. I appreciate any help that I can receive in troubleshooting this issue. Thank you.

@igor-dv thank you for the quick reply. I am glad to provide a repo, but I'll need some time to prepare a public one because I am running into this issue on a private repo and do not have permission to make the codebase public. Please give me a day and I'll have something public ready for you to reproduce the issue with.

Sure, any PR is good to go


Fix Visual Studio on ARM Compilation

This fixes Windows on ARM native Visual Studio compilation. The current #ifdef
logic assumes that Visual Studio always targets x86/x64, which is no longer the case.
Unfortunately based on:
https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
there doesn't seem to be a single macro to test Intel vs ARM compilation, hence the ugly logic.
With this change, OpenEXR compiles native to ARM on Windows and passes its test suite.

Thanks for figuring that out.


type 'Null' is not a subtype of type 'Map<dynamic, dynamic>'

Hi @abbas2501 which sdk version are you using ?

Hi @abbas2501 which sdk version are you using ?

hmssdk_flutter: ^0.7.6

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.3.0, on macOS 12.6 21G115 darwin-arm (Rosetta), locale en-IN)
[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    ✗ cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.
[✓] Xcode - develop for iOS and macOS (Xcode 13.2.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2020.3)
[✓] VS Code (version 1.72.2)
[✓] Connected device (3 available)
[✓] HTTP Host Availability

Can you tell more about when are you getting this error ?

Can you tell more about when are you getting this error ?

Thanks for replying!
Not sure really, because we're getting this in release mode. We tracked it on sentry (the image shows the logs) so it's not real-time logging. We just know it exists.

Okay, which platform is this android or iOS ?

Android it is.

Thanks for the info. Will check and share the update on this.

Hi @abbas2501  this is resolved in the new sdk release. Please update the SDK to 0.7.7 version.


Should I use InstructionSet?

I'm currently not sure if I should use the custom type InstructionSet which wraps the Instructions and indices.
Ideas/Recommendations/Thoughts are appreciated!

I will keep the type if we reach a reasonable amount of supporters for it, it will be dropped if not.


ALT + SHIFT vertically scrolls all open windows simultaneously

Often, I am comparing two GIT versions of a long file and editing a third file. It would be wonderful if we could scroll all open files simultaneously, rather than have to manually scroll each pane independently.

Please add the ability to scroll all open code editor windows simultaneously when the user holds the ALT + SHIFT and then scrolls the page using the mouse, the mouse scroll wheel, arrow keys or page-up/page-down keys.
Thank you!

I`d like to take this one


Add style check in pull requests

A quick search yields some options:

Stickler CI
Hound CI
Codacy
Feel free to discuss the pros / cons / alternatives here! 😄

Added Stickler CI for now. Will see how it works!


Owner key must not be mandatory

When creating an account the owner key must be entered, otherwise an exception is thrown after entering wallet password.
Furthermore, the default question should be to collect active and memo. The field to enter owner key could appear when a small button "Include owner key" or similar is clicked.

Ok...will sort it out

Fixed in https://github.com/clockworkgr/bitshares-companion/commit/2af365518eb3ac8892c16fa48dff79c5863c4ab5


Handle Client connection failure

The SDK client does have wrong behaviour after 10 iterations of retries to connect.
Description
This patch adds a proper error handling in SDK/client for the case where all iteration retries failed.
Motivation and Context
A wrong behaviour and crash were observed while the client runs in a volatile environment.
NSC for example just continues and finished its operation even though the Connect failed.
How Has This Been Tested?

[ ] Covered by existing integration testing
[ ] Added integration testing to cover
[X] Tested locally
[ ] Have not tested

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[X] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

I can confirm, after manually running the NSC without an ICMP responder. It true 10 times, then dies. K8s restarts the Pod and so on until the service is alive and the connection is established.


Problem timing

After months of waiting and doing everything but Python development, it's finally here.
It should be good to go, but feel free to make any comments you have about it. Be sure to try it out to see what you think.
One thing that this branch (sadly) does not do is any sort of timing of different programming language for real multipliers. I think that would certainly be a worthwhile project though.

One thing we might want to add to this is some sort of status readout. Right now, it's silent until it's done timing all of the problems. I could add that as either default or via a command-line argument.

Yeah, we should probably log it somewhere or something. I don't guess we have any logging, do we?

I added logging, so we should be just about good to go.

The real multipliers, I don't think we were ever planning on putting them directly in the project. I was under the impression that we would guess until we got around to empirically testing it out on problems with different complexities. That is to say, the multipliers would be hard-coded and not generated by AUACM

I would like to see some performance stats on multiple machines of Java vs Python vs C++, etc. If it happens that the numbers are about the same, then it would make sense to just hardcode the values in, but if we get varying results, then it would make more sense to actually generate those as well. It would be a larger undertaking for a different PR though.

Why would multiple machines make a difference? They're all going to be judged on the same computer.
I guess I figure that language discrepancy << algorithmic discrepancy. So the multiplier need not be precise, but reasonable. If it becomes an issue, we can handle it then.

As for outputting SQL, that's not necessary, if you check out the problem_timer.py file, you can see that if it finds a correct solution with a time greater than that of the previous solution, it updates the problem in the database and commits it. The logging is purely so that someone can see what's going on as it's happening.
As for the error, that's odd, but it shouldn't be caused by this PR. I opened the JS debugger and noticed that it's actually receiving the "good" message from the backend, it's just not doing anything with it. I'll look more into that tomorrow/this weekend to see if I can find the source of that issue.

This branch does not kick off the problem timing from problem creation. Since we probably want to do more than just kick it off (we probably want to verify that the submitted judge solution works), I think I will leave that out of this update. As it stands, this is just a utility to generate all of the problems' times, though it is not far off from being able to integrate with uploading a problem (another good reason to have the update_status function a callback rather than bound to the judge itself–you could do something like call back with whether or not a judge solution works rather than creating a submission for that user).

This is getting stale. I can make the required changes myself if necessary. The site is 70% live and this is crucial to being feature-complete

I think this PR should be considered done and merged in. After that, it would make sense to make another one with support for kicking off problem timing when a problem is created.

You're right. I didn't realize/forgot that status updates had been corrected.


Serverless reference architectures

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference-architectures/serverless/_images/serverless-event-processing.png
:white_check_mark:Succeeded
View

docs/reference-architectures/serverless/_images/serverless-web-app.png
:white_check_mark:Succeeded
View

docs/reference-architectures/serverless/event-processing.md
:white_check_mark:Succeeded
View

docs/reference-architectures/serverless/web-app.md
:white_check_mark:Succeeded
View

docs/toc.yml
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Nanoserver support

Summary of Problem

What are you trying to do?
Running zigbee2mqtt on nanoserver
What happens?
Zigbee2mqtt crashes when connection to the zigbee stick
What should have happened?
no crashes.

Thing this topic answers all questions about my problem;
https://github.com/Koenkk/zigbee2mqtt/issues/1479
In short: zigbee2mqtt, bases on node.js with serialport does not work on nanoserver, but does work on servercore. Serialport probably uses an api not available on nanoserver. Question is. can serialport be fixed to be used on nanoserver, or what libraries should i sideload on nanoserver to make serialport work?
Versions, Operating System and Hardware

Node.js v node-v10.15.3-win-x64/node-v11.15.0-win-x64. (tried both)
Windows 1809

What is nanoserver? What is servercore?
Servercore:
https://docs.microsoft.com/nl-nl/windows-server/get-started/getting-started-with-nano-server
"This is a base image for Windows Server containers. This image carries the Windows Server Core base OS image."
aka Full windows server without GUI

Nano server:
https://docs.microsoft.com/nl-nl/windows-server/get-started/getting-started-with-nano-server
aka nano size version of full server version.
It has a lite version of WIN32, with legacy API's removed.

We don’t use the uwp apis if that’s what it requires.

Well, for it to work on Nanoserver, it does.

Ok loaded Kernel32.dll and setupapi.dll. Got this error now;
  0: ExitFrame [pc: 0000023EAB7D0481]
Security context: 0x03fb16b1d9f1 <JSObject>
    1: debug [0000033DB26EC771] [C:\app\node_modules\cc-znp\node_modules\debug\src\common.js:~67] [pc=0000023EAB7ED49B](this=0x03a7e9604981 <JSGlobal Object>)
    2: arguments adaptor frame: 1->0
    3: close [000001A812975A69] [C:\app\node_modules\cc-znp\node_modules\@serialport\stream\stream.js:424] [bytecode=000002762F45B589 offset=47](this=0x03ad7aa295...

To bad. Thanks for your help. Reason why i have to use Windows docker container is that com device pass-through is not supported to Linux containers on windows. I will use the full server core version for now.


Support enchanted bolts

Was looking for enchanted bolt support for dps/max hit calcs.

diamond (e) is your max hit * 1.15. Also not a bug, would label it "enhancement" since it's something that's out of current scope.


How about add /dev/tty,random,urandom,zero,full,null pseudo-devices if cmd->mount_new_proc?

How about add /dev/tty,random,urandom,zero,full,null pseudo-devices if cmd->mount_new_proc
Sorry, my english so bad.

Done (two years too late) =)


Add Little Green Men from Mars from Kerbal Stuff

This pull request was automatically generated by Kerbal Stuff on behalf of GregroxMun, to add Little Green Men from Mars to CKAN.
Please direct questions about this pull request to GregroxMun.

Mod Author has made a new entry on KerbalStuff:  See #2950

Closing in favour of #2950


UNRESPONSIVE extension host

Template
Expansion hang trying to format the file
Context (Environment)
My VS code build
Version: 1.58.2 (system setup)
Commit: c3f126316369cd610563c75b1b1725e0679adfb3
Date: 2021-07-14T22:10:15.214Z
Electron: 12.0.13
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22000
Description
When trying to format the blade file both by format function or format on save the extension just going into infinite loading. It seem update 1.58 break it. I try go back to 1.57 and it works for awhile then vscode do the automatic update and it broke again.
But the second time rolling back to 1.57 didn't work anymore.

+1


Loading PDF with cookies

Hey,
We've seen there is a property withCredentials that allows us to configure whether to send Cookies with the request or not.
https://github.com/espresso3389/pdfrx/blob/fdc10211c0799d6d0d49ac831776874d8aafee35/lib/src/web/pdf.js.dart#L41
There seems to be no way to set withCredentials to true from PDFViewer.uri().
Any insights how we could achieve this?

1.0.71 contains the fix.

Thanks @espresso3389 for the quick resolution 😍 I do appreciate it


How to without serializer

So for reasons I have the endpoint and I do some various manipulation aggregating various stuff (without a model) and generating a dict with the data that I want in the exported file.
An example of my code:
class Export(XLSXFileMixin, Viewset):

    queryset = ""
    renderer_classes = (XLSXRenderer,)
    filename = "export.xlsx"

    http_method_names = [
        "get",
    ]

    def list(self, request):
        new_output = {}
        if self.request.query_params.get("export") == "data":
            self.column_header = {
                "titles": [
                    [...]
                ]
            }
    		[my code here]
        return self.response(new_output)

I get
AssertionError at /api/export/

'Export' should either include a `serializer_class` attribute, or override the `get_serializer_class()` method.

So What is the right serializer to use to get just this dict in the generated file?

The rendering code relies on customizing the Serializer. Can you try passing the DRF generic one?
from rest_framework.serializers import Serializer

class Export(XLSXFileMixin, Viewset):

    queryset = ""
    serializer_class = Serializer
    renderer_classes = (XLSXRenderer,)
    filename = "export.xlsx"

    http_method_names = [
        "get",
    ]

    def list(self, request):
        new_output = {}
        if self.request.query_params.get("export") == "data":
            self.column_header = {
                "titles": [
                    [...]
                ]
            }
    		[my code here]
        return self.response(new_output)

I tried with that one but didn't worked.
Seems that required the various fields (with a field that doesn't exist in the serializer itself) define otherwise wasn't generating anything.
Investigating the code seems that for any row and any value check if exist in the fields, so share like a json with the data is not working for this package (also the column headers were defined).
At the end I did it manually generating a csv for the moment.


Metric prefix addition during the output generation

HI,
Seems that Prometheus client prescribes a pattern for declaring the metrics at module level, which has the good benefit of making it available quite straightforward by just importing that specific symbol, also allow the system to have it in memory - not deallocated by the GC - for the whole process time.
There is one downside effect by using that pattern, if we want to use the same code and metrics for many different services where the only thing that changes is the prefix of the metric and that prefix is only available at runtime - not load time - there is no way on adding this prefix to the already created metrics.
What do you recommend in this scenario?
Im wondering if we should create our own Registry - BTW is the class a public interface ? - and use the same instance in all of our metrics and when the data is gathered by generate_latest do something like this:
from myregistry import REGISTRY
if REGISTRY.prefix is None
    REGISTRY.prefix = "fooservice"
generate_latest(REGISTRY)

Behind the scenes REGISTRY would override the collect metric or other and would mutate the metric name by adding the prefix that was configured.
WDYT?
Question? What would happen if we would have the same requirement for labels? so for example, if we would like to add some labels during the generate_latest? As an exmple of the lables that could be introduced for all of the metrics would be the pod name.

See https://www.robustperception.io/target-labels-not-metric-name-prefixes
It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.


Remove unused dependencies

Example: node-gyp is listed in our package.json and is no longer used. We will use this issue to track completion and identify any unused dependencies to also get rid of.
Related to https://github.com/ChainSafe/lodestar/issues/6026
Dependencies to remove:

node-gyp

to fix your trouble check this solution click
maybe this will solve your problem.


Implement wand.version.mimetypes()

Which queries ImageMagick library for supported MIME types.

This is a good request, but have some upstream dependencies. MagickCore library has the GetMagickMimeType method that returns the MimeTypes based on the XML map config/mime.xml.
However there is no API to MagickWand which wand integrates with.
Additional MagickCore methods could be introduce, but I don't believe it would be intended to have both MagickCore & MagickWand loaded for normal runtime of wand.version (maybe I'm wrong here).
Another approach would be to implement your own, but might quite a bit of work to turn the low-level core methods into something usable.
Example to get the list of all MIME types (note: error handling & memory handling omitted)
import ctypes
from wand.api import libmagick, library

# Tell python about MagickCore method
libmagick.GetMimeList.argtypes = [ctypes.c_char_p, # const char * pattern
                                  ctypes.POINTER(ctypes.c_size_t), # size_t *number_aliases
                                  ctypes.c_void_p] # ExceptionInfo *exception
libmagick.GetMimeList.restype = ctypes.POINTER(ctypes.c_char_p)

def mimetypes(pattern):
    exc = libmagick.AcquireExceptionInfo()
    count = ctypes.c_size_t(0)
    response = libmagick.GetMimeList(pattern,
                                     ctypes.byref(count),
                                     exc)
    return_value = []
    for cursor in range(count.value):
        return_value.append(str(response[cursor]))
    return return_value

mimetypes("application/*") #=> [ 'application/x-trash', 'application/x-cpio', 'application/x-core', 'application/x-chess-pgn',  'application/x-bzpdf', 'application/x-bzip', ...

Or perhaps look up MIME info by filename or magic number
import ctypes
from wand.api import libmagick, library

# Review C header files for correct mapping
# struct _MimeInfo
class MimeInfo(ctypes.Structure):
    _fields_ = [("path", ctypes.c_char_p),
                ("type", ctypes.c_char_p),
                ("description", ctypes.c_char_p),
                ("pattern", ctypes.c_char_p),
                ("priority", ctypes.c_long),
                ("offset", ctypes.c_int),
                ("extent", ctypes.c_size_t),
                ("data_type", ctypes.c_int),
                ("mask", ctypes.c_long),
                ("value", ctypes.c_long),
                ("endian", ctypes.c_long),
                ("length", ctypes.c_size_t),
                ("magick", ctypes.c_void_p),
                ("stealth", ctypes.c_int),
                ("signature", ctypes.c_size_t)]
libmagick.GetMimeInfo.argtypes = [ctypes.c_char_p, # filename
                                  ctypes.c_void_p, # magick
                                  ctypes.c_size_t, # length
                                  ctypes.c_void_p] # exception
libmagick.GetMimeInfo.restype = ctypes.POINTER(MimeInfo)

def find_mime(pattern, header):
    exc = libmagick.AcquireExceptionInfo()
    length = len(header)
    info_p = libmagick.GetMimeInfo(pattern, header, length, exc)
    return info_p[0]

info = find_mime("example.png", "\x89PNG")
print "type={0.type} description={0.description}".format(info)
#=> "type=image/png description=PNG image"

TL;DR
To sum it all up: This is a great request, but we need some API endpoints on the MagickWand library to interface with.

Or use python's mimetypes with wand.version.formats
import mimetypes
import wand.version

def supported_mimetypes():
    all_supported = wand.version.formats("*")
    mimes = []
    for supported in all_supported:
        # Fake a url
        url = "./FILE.{0}".format(supported)
        mime, enc = mimetypes.guess_type(url)
        if mime and mime not in mimes:
            mimes.append(mime)
    return mimes
print supported_mimetypes()
#=> [ 'application/octet-stream', 'application/postscript', 'video/x-msvideo', 'image/bmp', ...

Closing this out. If MagickWand C-API ports mime methods, we can integrate with it. But the info is also available from Python, and the info is also shipped with as a mime.xml in ImageMagick's installed directory.


[WIP] ManagedClusterAcion implementation and integration

Core implementation and use of ManagedClusterAction instead of ManifestWork to deliver PVs to managed clusters.
TODOs:

[ ] Add a watcher and filter in MCA events
[ ] Update test cases for DRPC
[ ] Remove PV ManifestWorl unused code

NOTE: This will fail make test as DRPC tests are not
modified yet. The core functiowqnality has been hence tested
on a functioning multicluster minikube setup

As per discussion with @jnpacker we would leverage ManifestWork with a one-shot policy/field rather than use ManagedClusterAction.
Closing this for now, and can remain in github for any potential future needs.


Fixes the "no output.name" error.

Without a name, the bundle exports can't be accessed.
$ vite build -c vite.legacy.config.ts
vite v2.0.2 building for production...
✓ 19 modules transformed.
rendering chunks (1)...creating legacy bundle...
If you do not supply "output.name", you may not be able to access the exports of an IIFE bundle.
dist/lit-element-sample.iife.js          29.59kb / brotli: 6.94kb
dist/lit-element-sample.iife.js.map      155.20kb
dist/lit-element-sample.iife.legacy.js   85.81kb / brotli: 25.34kb
dist/lit-element-sample.iife.legacy.js.map 117.21kb
✨  Done in 6.98s.

Why would you use this plugin on a library?

I was developing a library/third-party script that'd have both ESM and "classic" exports (where the latter would just add itself to window and be compatible with most browsers). What would be the correct approach then?


Popover becomes dismissible after another popover on the page is opened

If I enter the page, open my desired popover, and click outside the popover it stays open.
If I then open another popover, close it, open my desired popover and click outside, the popover closes! It also closes when I choose an option from a select box in my popover.
I've tried every possible setting to no avail, including key ones such as dismissible: false and trigger:manual. Even with both of those set, it still closes upon outside click.
Is there any possible way to prevent my desired popover from closing (due to an outside click or select option click) simply due to the fact that I opened another popover?

After much more experimentation of settings, I found that setting dismissible:false on the other popover made the desired popover not close.
It seems highly error prone in that to make one popover dismissible, we need to set every other popover on the page to be dismissible as well. This is likely something that needs to be investigated deeper into the code.

So, my proposed change here is the "dismissible" be on a per-popover basis, rather needing set all popovers to be non-dismissible for each popover to be non-dismissible.

I've solved the issue. Will submit a PR later today.

@sbrodkey or @gvcayetano did you find a workaround eventually?


PSParser Tokenize with Switch Default fails

Trouble when trying to Tokenize a script containing a Switch-statement with a Default case in Powershell 7.1.0-preview.5. This works as expected in Powershell 7.0.3 (stable). If one does comment-out the default case, it works as expected. This has been reproduced on more than one computer.
Steps to reproduce
Create a file containing a simple function that has a switch-statement with a default case (see below). Save that file. Then try to tokenize that file (also see below) from a console running Powershell 7.1.0-preview.5.
# Save this as a file called 'TEST.ps1'
Function Test {
    Param (
        $String
    )

    Switch ($String) {
        "test" {
            "sfdsf"
        }

        "test2" {
            "sfdsf"
        }

        default {
            "sdfsdf"
        }
    }
}

# From a Powershell 7.1.0-preview.5 prompt execute the following:
$scripts = Get-ChildItem -Path "C:\__TEMP\TEST.ps1"

Foreach ($file in $scripts) {
    $contents = Get-Content -Path $file.fullname -ErrorAction Stop
    $errors = $null
    $null = [System.Management.Automation.PSParser]::Tokenize($contents, [ref]$errors)
    $errors.Count -eq 0
}

Expected behavior
True

Actual behavior
MethodInvocationException:
Line |
   4 |      $null = [System.Management.Automation.PSParser]::Tokenize($conten …
     |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Exception calling "Tokenize" with "2" argument(s): "Index was outside the bounds of the array."
True

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.0-preview.5
PSEdition                      Core
GitCommitId                    7.1.0-preview.5
OS                             Microsoft Windows 10.0.19041
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0ÔÇª}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

PSParser is legacy and I'm not sure it's actually supported in a meaningful way.
Instead, you can use:
$tokens = $parseErrors = $null
$ast = [System.Management.Automation.Language.Parser]::ParseInput($script, [ref]$tokens, [ref]$parseErrors)

My guess is the PSParser code path was probably broken with #10487 cc @SteveL-MSFT @rjmholt not sure PSParser is really supported / what would need to be done to "fix" it following that change, or whether it's worth looking into as there are fully functional and supported alternatives available.

Thank you for your prompt reply!
Perfect, that works for me. Hopefully this will help someone else as well.

This sounds like something we should still fix though -- the PSParser API needs to be maintained for broad module compatibility

Full stack trace:

Exception             :
    Type           : System.Management.Automation.MethodInvocationException
    ErrorRecord    :
        Exception             :
            Type    : System.Management.Automation.ParentContainsErrorRecordException
            Message : Exception calling "Tokenize" with "2" argument(s): "Index was outside the
bounds of the array."
            HResult : -2146233087
        CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordException
        FullyQualifiedErrorId : IndexOutOfRangeException
        InvocationInfo        :
            ScriptLineNumber : 1
            OffsetInLine     : 1
            HistoryId        : -1
            Line             : [System.Management.Automation.PSParser]::Tokenize($s, [ref]$errs)
            PositionMessage  : At line:1 char:1
                               + [System.Management.Automation.PSParser]::Tokenize($s, [ref]$errs)
                               + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            CommandOrigin    : Internal
        ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
    TargetSite     :
        Name          : ConvertToMethodInvocationException
        DeclaringType : System.Management.Automation.ExceptionHandlingOps,
System.Management.Automation, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35
        MemberType    : Method
        Module        : System.Management.Automation.dll
    StackTrace     :
   at System.Management.Automation.ExceptionHandlingOps.ConvertToMethodInvocationException(Exception
exception, Type typeToThrow, String methodName, Int32 numArgs, MemberInfo memberInfo)
   at CallSite.Target(Closure , CallSite , Type , Object , PSReference )
   at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1
arg1, T2 arg2)
   at System.Management.Automation.Interpreter.DynamicInstruction`4.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame
frame)
    Message        : Exception calling "Tokenize" with "2" argument(s): "Index was outside the
bounds of the array."
    Data           : System.Collections.ListDictionaryInternal
    InnerException :
        Type       : System.IndexOutOfRangeException
        TargetSite :
            Name          : GetPSTokenType
            DeclaringType : System.Management.Automation.PSToken
            MemberType    : Method
            Module        : System.Management.Automation.dll
        StackTrace :
   at System.Management.Automation.PSToken.GetPSTokenType(Token token)
   at System.Management.Automation.PSToken..ctor(Token token)
   at System.Management.Automation.PSParser.get_Tokens()
   at System.Management.Automation.PSParser.Tokenize(String script, Collection`1& errors)
   at CallSite.Target(Closure , CallSite , Type , Object , PSReference )
        Message    : Index was outside the bounds of the array.
        Source     : System.Management.Automation
        HResult    : -2146233080
    Source         : System.Management.Automation
    HResult        : -2146233087
CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
FullyQualifiedErrorId : IndexOutOfRangeException
InvocationInfo        :
    ScriptLineNumber : 1
    OffsetInLine     : 1
    HistoryId        : -1
    Line             : [System.Management.Automation.PSParser]::Tokenize($s, [ref]$errs)
    PositionMessage  : At line:1 char:1
                       + [System.Management.Automation.PSParser]::Tokenize($s, [ref]$errs)
                       + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    CommandOrigin    : Internal
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1

The problem is that this mapping hasn't been maintained:
https://github.com/PowerShell/PowerShell/blob/4b9b0788ed28ea6d463ce857d1ed81bd4a977a59/src/System.Management.Automation/engine/lang/interface/PSToken.cs#L105-L307
That's ostensibly easy to fix, but:

We need testing for it
We need to work out what else might be missing
There may be tokens that we could return but we can't for compatibility reasons -- something I'm not sure how to handle (haven't thought about this properly). For example, how should a caller built to handle PS v3 code deal with the class keyword?

/cc @daxian-dbw

@rjmholt Is this specific regression caused by https://github.com/PowerShell/PowerShell/pull/10487?

@rjmholt Is this specific regression caused by #10487?

I believe so

base seems to be working fine:
PS:162> $es = $null; [System.Management.Automation.PSParser]::Tokenize("class foo { foo() : base() }", [ref]$es)
...
Content     : base
Type        : Unknown
Start       : 20
Length      : 4
StartLine   : 1
StartColumn : 21
EndLine     : 1
EndColumn   : 25
...

Type        : Unknown

That looks like this:
https://github.com/PowerShell/PowerShell/blob/4b9b0788ed28ea6d463ce857d1ed81bd4a977a59/src/System.Management.Automation/engine/lang/interface/PSToken.cs#L306

Yeah. Let's first fix this regression by simply updating s_tokenKindMapping. And also open a new issue to discuss how to deal with PSParser in the long term to keep it up-to-date.


Bugfix / JPRO-67 Update JPro Server Stop Command for DEV Mode Following JPro Maven Plugin Profile Configuration Change

Background: Komet utilizes the JPro Server for running JavaFX applications in a web environment, managed through the JPro Maven Plugin. Recently, the JPro Maven Plugin configuration was updated to use profile configurations.
Issue: After changing the JPro Maven Plugin to use profile configurations, the command responsible for stopping the JPro Server in DEV mode is no longer functioning as expected.
Proposed Solution: Update the JPro Server stop command configuration to align with the new profile-based setup of the JPro Maven Plugin.

Thank you, Carl!
We’ll provide your testers with instructions on how to manually test the start and stop commands. JPro supports these commands both in development mode using the JPro Maven Plugin and in production deployments via the release zip, located inside the bin directory.
FYI: While these commands are primarily used in production, during development the jpro:run command is mostly utilized. It runs the server in the foreground, which is very useful for reading logs and monitoring terminal output. This effectively replicates the functionality of the javafx:run command, even though they are not the same.