DXF Text is missplaced after export

I have a simple DXF file with a text object (the yellow one)

If I export the file as DXF the text is at the wrong position (zero) and has a wrong orientation.

Files:
original.zip
after_export.zip

So the reason that happens is because in ExportDxf.cs the line res.TransformBy(Matrix4(toText));  is commented out.
        private netDxf.Entities.Text ExportText(GeoObject.Text text)
        {
            System.Drawing.FontStyle fs = System.Drawing.FontStyle.Regular;
            if (text.Bold) fs |= System.Drawing.FontStyle.Bold;
            if (text.Italic) fs |= System.Drawing.FontStyle.Italic;
            System.Drawing.Font font = new System.Drawing.Font(text.Font, 1000.0f, fs);
            netDxf.Entities.Text res = new netDxf.Entities.Text(text.TextString, Vector2.Zero, text.TextSize * 1000 / font.Height, new TextStyle(text.Font + ".ttf"));
            ModOp toText = ModOp.Fit(GeoPoint.Origin, new GeoVector[] { GeoVector.XAxis, GeoVector.YAxis, GeoVector.ZAxis }, text.Location, new GeoVector[] { text.LineDirection.Normalized, text.GlyphDirection.Normalized, text.LineDirection.Normalized ^ text.GlyphDirection.Normalized });
            // res.TransformBy(Matrix4(toText)); // easier than setting normal and rotation
            return res;
        }

https://github.com/SOFAgh/CADability/blob/82ffb3400f8971b8fb756c8e96a28f9019930eb0/CADability/ExportDxf.cs#L157
If I uncomment it again (and the used Matrix4 method), it works as intended. Is there a reason why this line has been commented out?

We should probably uncomment this line. I tested with a few files, maybe you have some more files to test with.

I wrote a simple unit test plus fix and created a PR #130
Since even that simple example fails without the change I would assume this solution should be merged.


Backend substituting does not work

Release version
v6.0.1-rc1
Describe the bug
I tried substituting the backend using follow setting
backends:

name: my-po-api
properties:
url: "https://my-test-po-app.azurewebsites.net/api"
resourceid: "https://management.azure.com/subscriptions/{MySubscId}/resourceGroups/{MyGroupId}/providers/Microsoft.Web/sites/{MyAppName}"

also tried
resourceid: "https://management.azure.com/subscriptions/{MySubscId}/resourceGroups/{MyGroupId}/providers/Microsoft.Web/sites/{MyAppName}?api-version=2023-01-01"
Expected behavior
Backend for my-po-api changed.
Actual behavior
Backend for my-po-api not changed.
Reproduction Steps
Try to substitute the backend like in the example - https://github.com/Azure/apiops/blob/main/configuration.prod.yaml;
Use regular appserv instead of function.

Please check past issues (both closed and open) as it has been addressed in the past. Also make sure you take a look at the repository will. Finally take a look at the apim restful api as apiops honors that so it should give you an idea on the schema of the request which will guide you on how to override in the configuration file.

This approach helped me
apis:

name: my-api-name
properties:
serviceUrl: https://my-api-backend-url


Input configuration protocol

wlroots has the wlr-output-management protocol, which makes tools like wlr-randr possible, but there seems to be no corresponding protocol for input configuration, which would make a tool like xinput possible.

I don't think it's worth doing. wlr-output-management is primarily useful for output management daemons. There are no input management daemons.
If you still think it's worth it, the repo to send a patch to is wayland-protocols.


Intend Line highlighting

How do I get the intend lines to highlight like in the example?

I use https://github.com/lukas-reineke/indent-blankline.nvim/ for this


Twilio Website Clone

Project title
Clone of Twilio Website
Project Description
This is a very famous website to connect with customers.
Stack:

[x] Html
[x] CSS
[x] JavaScript

/assign


missing features from awslambda mock

In the process of writing tests for some lambda function management code, I've noticed that a number of features are not implemented. Interestingly, there are no exceptions raised by moto. Instead, the calls are pushed through to AWS, and time out due to insufficient permissions (thank goodness!). These calls include:

awslambda.add_permission
awslambda.remove_permission
awslambda.update_function_code
awslambda.update_function_configuration

These were problematic enough for my testing that I didn't go any deeper. A quick look at the code suggests that there are other functions that would be missing as well.
Rounding out the implementation for awslambda is one thing, but the fact that some calls are caught and others are passed through to lambda proper is another. If a user has default credentials set up, they may end up making costly calls to the real service while developing tests. Any chance of a quick solution to that secondary problem?

On a related note, despite the fact that it appears to be implemented in moto, I'm getting the same behavior from awslambda.delete_function.
It occurs to me that it's possible that I misinterpreted the error initially. I'm not totally sure that this is a pass-through to lambda-proper. Here's the error:
ConnectionClosedError: Connection was closed before we received a valid response from endpoint URL: "https://lambda.us-east-1.amazonaws.com/2015-03-31/functions/arn%3Aaws%3Alambda%3A123456789012%3Afunction%3Abar".

Is there something within moto that could be catching that but failing to return?  Here's some potentially helpful log output:
INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): <IP_ADDRESS>
INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTP connection (1): <IP_ADDRESS>
INFO:boto3.resources.action:Calling iam:create_role with {'RoleName': 'baz-foo-role', 'AssumeRolePolicyDocument': '"some": "policy"'}
INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): iam.amazonaws.com
INFO:mylogger:creating lambda function: bar
INFO:boto3.resources.action:Calling iam:get_role with {u'RoleName': 'baz-foo-role'}
INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): iam.amazonaws.com
INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): lambda.us-east-1.amazonaws.com
INFO:mylogger:successfully created lambda function: arn:aws:lambda:123456789012:function:bar
INFO:mylogger:deleting lambda function: arn:aws:lambda:123456789012:function:bar
INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): lambda.us-east-1.amazonaws.com
INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTPS connection (2): lambda.us-east-1.amazonaws.com
INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTPS connection (3): lambda.us-east-1.amazonaws.com
INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTPS connection (4): lambda.us-east-1.amazonaws.com
INFO:botocore.vendored.requests.packages.urllib3.connectionpool:Starting new HTTPS connection (5): lambda.us-east-1.amazonaws.com

Yes, that is not actually going to AWS, but being stopped by Responses.
Keeping this ticket open for the feature requests. Thanks!


can we rewrite passport with modern syntax?

we need modern style passport. it can be lighter, more readable passport source code.

You are free to do what you want, but I'm personally not interested in rewriting Passport and wouldn't merge any such change.  It's functional, mature, and reliable as is, so there's little to no benefit of this.


Run pod repo update in iOS extension test

In a PR I updated an integration test pod to version EFQRCode=6.0 released 2020-11-04, and the test succeeded on my machine but failed in the devicelab.
stdout:     Resolving dependencies of `Podfile`
stdout:       CDN: trunk Relative path: CocoaPods-version.yml exists! Returning local because checking is only perfomed in repo update
stdout:       CDN: trunk Relative path: all_pods_versions_9_f_5.txt exists! Returning local because checking is only perfomed in repo update
2021-01-06T14:45:02.365845: stdout:       CDN: trunk Relative path: Specs/9/f/5/EFQRCode/5.1.7/EFQRCode.podspec.json exists! Returning local because checking is only perfomed in repo update
stdout:     [!] CocoaPods could not find compatible versions for pod "EFQRCode":
stdout:       In Podfile:
stdout:         EFQRCode (= 6.0)
stdout:
stdout:     None of your spec sources contain a spec satisfying the dependency: `EFQRCode (= 6.0)`.
stdout:
stdout:     You have either:
stdout:      * out-of-date source repos which you can update with `pod repo update` or with `pod install --repo-update`.
stdout:      * mistyped the name or version.
stdout:      * not added the source repo that hosts the Podspec to your Podfile.

I'm not sure why the CocoaPods specs repo is so far out of date.  Run pod repo update before the integration test to update the snapshot.
Original PR:
https://github.com/flutter/flutter/pull/72761
Revert due to test failure:
https://github.com/flutter/flutter/pull/73437

I don't know if this takes longer than running git pull in the spec repo. Maybe the infra team can just run this manually once also on all the machines.

It takes <2 seconds on my machine, though it will take longer the first time it runs on every devicelab agent.  I can remove it if it causes us problems.

I don't know if this takes longer than running git pull in the spec repo. Maybe the infra team can just run this manually once also on all the machines.

It takes <2 seconds on my machine, though it will take longer the first time it runs on every devicelab agent.  I can remove it if it causes us problems.


Urobiome package term suggestion urine_leuk

New term details
Term name - urine leukocyte esterase (LE) or White Blood Cell (WBC)
Structured comment name - urine_leuk
Definition - Presence/value of leukocyte esterase or white blood cells from urine dipstick testing or urinalysis
Expected value - value
Value syntax - {float}{unit}
Example - 500 WBC/microliter
Preferred unit - WBC/microliter
Package - Urobiome

Additional context
Suggested as part of the Urobiome package.

Split into leukocyte esterase measurement and method

Discussed 7/21 -
proposed new definition: Specify if sample had an abnormal leukocyte esterase/white blood cell (WBC) value.
To do - define controlled vocabulary


[Mining] Identification of mining rewards

Identify in the frontend code the mining transactions.
Now, there is no distinction between mining rewards and other transactions. Probably, we will be able to use is_coinbase flag in the transaction event.

[ ] Wrap addMinedTx with if statement in useWalletEvents
[ ] Adjust the SQL query

possible duplicate of #188
@tomaszantas


Other possible (grav) themes

Most in line with the philosophy
Vela
https://demo.matthiasdanzinger.eu/vela/
Hyde
http://hyde.getpoole.com/
Katharine Hyatt's blog
http://kshyatt.github.io/
(ask first if she's happy with repurposing, it's based on the Hugo Academic theme so probably fine but still.)
Secondary
GIT (1/2)
https://demo.hibbittsdesign.org/grav-learn2-git-sync/
It's a bit of a slow beast though so might need some slimming. However the search thing is potentially nice. The buttons to navigate to next page may be nice too.
also https://learn.getgrav.org/15
twenty fifteen
https://demo.getgrav.org/twentyfifteen-skeleton/en
(may require some work to get the archival stuff, could remove it to begin with)
striped
https://demo.getgrav.org/striped-skeleton/
essentially the same as 2015
saturn
https://demo.getgrav.org/saturn-skeleton/
HPSTR
the one page design is a bit shit but some people may like it (the hamburger menu is nice)
https://demo.getgrav.org/hpstr-skeleton/
Cacti
https://demo.getgrav.org/multilang-skeleton/en/blog/an-example-post
nice and clean
Tivka
https://tikva-demo.kuerbis.org/
does not seem responsive.

Agree on the first three; with them (and pure-sm) we'll have a nice collection of themes / layouts for different types of sites.

GIT (1/2): a bit "crowded", and obviously intended for linear courses (with the prominent forward/backward arrows). Do we really need that?
twenty fifteen: very nice and clean. If it's not too much work, would be a great addition!
striped: don't see anything special in this one, and personally don't like the looks...
saturn: looks nice, and definitely different than "all the others". +1
HPSTR: I agree, no structure at all probably does not suit our use case
Cacti: like it, but isn't it quite similar to the pure-sm?
Tivka: nothing special IMHO

Cool, thanks! I'll go with the ones you highlighted, no need for very many at the start, I think if we have 4-5 that are good and well integrated, it's already nice! and then we could imagine letting other people contributing. Now that I've ported one I think it will take me little time to port other ones 🙂

Closing here, tracked there


iasl: 20180313 -> 20180508

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/iasl/versions.
These checks were done:

built on NixOS
/nix/store/7npniq2lclj2j9dll49i5d9iv2a7m1a3-iasl-20180508/bin/iasl passed the binary check.
1 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
directory tree listing: https://gist.github.com/4372e0bf3ad631bda12d008e28b82d3d
du listing: https://gist.github.com/dc839b8c91ddbea0d30b1d19c7ace259

meta.description for iasl is: '"Intel ACPI Compiler"'.

Success on aarch64-linux (full log)
Attempted: iasl
Partial log (click to expand)
these paths will be fetched (0.30 MiB download, 1.02 MiB unpacked):
  /nix/store/wmmdfa9jgbdjg1g4nxsrpa4ilbkf5x48-iasl-20180508
copying path '/nix/store/wmmdfa9jgbdjg1g4nxsrpa4ilbkf5x48-iasl-20180508' from 'https://cache.nixos.org'...
/nix/store/wmmdfa9jgbdjg1g4nxsrpa4ilbkf5x48-iasl-20180508

Success on x86_64-linux (full log)
Attempted: iasl
Partial log (click to expand)
/nix/store/7npniq2lclj2j9dll49i5d9iv2a7m1a3-iasl-20180508

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: iasl
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Duplicate of #40613, which was reverted because it broke xen and virtualbox.


Should accept dict representing environment vars inherited from parent

When substituting environment variables, the environment is assumed to be empty at the start. This is not the case for images that inherited from anything other than scratch.
The constructor should accept an optional dict parameter parent_env, and this should be copied and used as the starting environment variable when parsing the Dockerfile.

https://github.com/DBuildService/dockerfile-parse/pull/21
https://github.com/projectatomic/atomic-reactor/pull/586

Fixed via #21.


list displays only 1 row on Windows

The million numbers  List example shows me only 1 row instead of the 5 rows as shown on rye-fyne  website.

My screen.

Could that be a Windows problem?
And how can I set the number of listed rows from 5 to something else?

How big is the window itself in your case and in your code do you call |resize size 220.0 200.0 ?
That call determines the window size, without it the list would reduce to minimum or one row. The number of rows it shows in the consequence of the window size in this example.

the canvas itself is large enough
a. app
|window "Hello Folkert"
|resize size 1200.0 800.0

I will test the same code on my macbook later on. Perhaps it is OS related.

Aha, that is a different example / demo ... that one shows one line for me also and it's expected. The reason is that the parent is v-box and both boxes always reduce the items in them to minimum.
If you want the list to extend you have to use different combinations of layouts. I in fact don't have that much experience with Fyne yet, but the one layout that takes all available space is called border. It has a little unusual api ... first 4 arguments are border widgers for top bottom left right, and the last argument is a block of items that it expands to maximum.
Look at the Shopping list app example on how border is used to expand list to the maximum and input to the bottom. cont: border nil input nil nil [ lst ]


Add workaround to make yamlls work with node v15.x

See https://github.com/neovim/neovim/issues/13448 and https://github.com/redhat-developer/yaml-language-server/issues/370.
I don't see a good way how yamlls could find out that registerCapability is not working for workspaceFolder changes, so this workaround would solve that for the moment.

I'm contemplating making a PR to just make all servers have this callback by default... I'm not sure how widespread it is yet.

See: https://github.com/neovim/nvim-lspconfig/pull/471

@david0 I think since #471 it took care of this

471 works for me. I'll close this PR.


Issue 273 add roundtrip efficiency to scheduler

This PR rewrites our generic device scheduler to:

Deal with asymmetric efficiency losses of individual devices.
Deal with asymmetric up and down prices for deviating from previous commitments.

Furthermore, it allows round-trip efficiency to be communicated as a new optional field when POSTing UDI Events, with efficiency losses being assigned equally to charging and discharging.
Closes #273.
NB In a premature state, this PR applied round-trip efficiency by scaling charging and discharging prices accordingly. However, this approach is limited to use cases with a single device per EMS. With tariffs modeled as a commitment to zero prosumption, for a single-device EMS, the up price is equal to the consumption price (charging) and the down price is equal to the feed-in price (discharging).

And one fundamental question: It seems we are going from one power variable to ems_power, device_power_down and device_power_up. Does this mean that in principle (although it is usually isn't optimal) we could charge and discharge at the same time?

Correct. At first I added the constraint device_power_up * device_power_down = 0, but that results in a non-linear (quadratic) program. The same goes for the constraint commitment_downwards_deviation * commitment_upwards_deviation = 0. Given efficiencies between 0 than 1 and given convex commitment prices, I believe we can go without these constraints.

For full understanding, I wanted to see how the battery and charging stations differ. I had a tough time really seeing how that is, as battery.py and charging_station.py seem to share a large amount of code.
My assumption: They both schedule only one sensor (one for a battery, one for a charging station) against SOC targets for lowest costs. The "EMS" is not being optimized, but it actually is the environment of the 1 device (e.g. the grid).
Is that correct? The comments are sometimes talking about "devices" (plural) so I'm unsure.

Our generic device scheduler (def device_scheduler) is able to handle an EMS with multiple devices, with constraints on the EMS level and on the device level, and market commitment on the EMS level. A typical example is a house with many devices. The two specific schedulers we coupled to the FlexMeasures API are for an EMS with a single device, i.e. a standalone Charge Point and a standalone battery system.

A few smaller questions, maybe addressable in this PR (with a comment or so) but maybe rather as tickets:
* What is the difference in treatment between battery and charging station? I compared the code for a few minutes, but I couldn't tell the major difference. Their docstring are also almost identical.

The differences are few, actually. Perhaps they have been dissipating as development progressed. I think at this point it's only in the min/max state of charge (which is assumed to be a known sensor property for a battery, but not so for a Charge Point, because it depends on the connected EV).

* Can we formally distinguish (check) that we treat a sensor/asset of correct type before we schedule?

Good idea. I made a card for project 6.

* If the code is 75% (or so) identical, there might be an idea for future refactoring to note here.

Refactoring is a good idea. I added a card to project 6.


Set up test for Istio 1.8.2 to verify Envoy V3 protocol

[x] If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
[x] Update the CHANGES log.

Verified via https://github.com/kezhenxu94/skywalking/actions/runs/489408211

Verified via https://github.com/kezhenxu94/skywalking/actions/runs/489408211


Jac/schedules

Fix library to handle breaking change made in schedules feature.

This branch was simply combining some pull requests made against master for merge convenience


Update Italian translation

Added missing translations and changed some others that were badly written.

Thank you @dellamina for offering these updates.
Will merge in now for the next feature release.


Fix eslint and setup GitHub action for lint

Current
No CI run and linting is failing
Expected
Lint should be green and validated each time by CI

split in 2 PRs


"Action needed" tag

In #833 we introduced Horizon deprecation tags that act like a reminder to remove deprecated fields in a given version. It seems that deprecations are not the only thing you want to be reminded about. I propose to change this tag to:
Action needed before: $CIRCLE_TAG

and the following line explains what need to be done before releasing a given version.

@tomquisel implemented changes you requested.


The target id parser is a URL parser, not a URI parser

This causes issues with the following
<state id="example">
	<onentry>
	<script>
<![CDATA[
		var interpreter = this;
		window.onbeforeunload = function(e){
			interpreter.send({"target" : "sfm.sales.popup", "name" : "sfm.event.sales.popup","type" : "","data" : "","origin" : ""},{"delay" : 0, "sendId" : ""});
  			e.returnValue = "Really?";
			return e.returnValue;
		}
		$("#salesPage").show();
]]>
	</script>
	</onentry>

the associated state is defined as follows
<state id="sfm.sales.popup">

The issue is that the target URI sfm.sales.popup doesn't pass the Daring Fireball URL parser.
The intersection of valid DF URL and valid URI is www.*
No valid URI (id attribute) can contain a colon or a forward slash. A URL that passes the DF match either contains a colon, ends in a forward slash, or starts with www.

<send> is used for sending events. Why specify an associated state id as a target of send?

It's also not clear to me that the value of a state id attribute must be a URI.

Thanks for your time.
I'll close the ticket.


Config option dataframe.dtype_backend: pyarrow doesn't seem to work

From https://docs.dask.org/en/stable/generated/dask.dataframe.read_parquet.html:

Use the dataframe.dtype_backend config option to select which dtype implementation to use.
dataframe.dtype_backend="pandas" (the default) will use pandas’ numpy-backed nullable dtypes (e.g. Int64, string[python], etc.) while dataframe.dtype_backend="pyarrow" will use pyarrow-backed extension dtypes (e.g. int64[pyarrow], string[pyarrow], etc.). dataframe.dtype_backend="pyarrow" requires pandas 1.5+.

coiled-runtime 0.2.1 + dask 2023.1.0:
>>> import dask.config
>>> import dask.dataframe as dd
>>> dask.config.set({"dataframe.dtype_backend": "pyarrow"})
>>> ddf = dd.read_parquet(
...     "s3://coiled-datasets/prefect-dask/nyc-uber-lyft/processed_data.parquet",
...     engine="pyarrow",
...     filesystem="arrow",
... )
>>> ddf.dtypes['hvfhs_license_num']
string[python]

Workaround
from distributed import WorkerPlugin

class SetPandasOptions(WorkerPlugin):
    def setup(self, worker):
        pd.set_option("string_storage", "pyarrow")

pd.set_option("string_storage", "pyarrow")  # Set on the client
client.register_worker_plugin(SetPandasOptions())  # Set on the workers

CC @jrbourbeau @ncclementi

Thanks for the report @crusaderky. You also need to set use_nullable_dtypes=True. use_nullable_dtypes tells Dask whether or not to use extension dtypes and the dataframe.dtype_backend config option specifies which type of dtypes to use

@jrbourbeau doesn't work:
>>> dask.config.set({"dataframe.dtype_backend": "pyarrow"})
>>> ddf = dd.read_parquet(
...     "s3://coiled-datasets/prefect-dask/nyc-uber-lyft/processed_data.parquet",
...     engine="pyarrow",
...     filesystem="arrow",
...     use_nullable_dtypes=True,
... )

ValueError: An error occurred while calling the read_parquet method registered to the pandas backend.
Original Message: Not all columns are categoricals

I find the documentation confusing. From it, I can't understand what happens (or what's the benefit) from having dataframe.dtype_backend="pyarrow" and use_nullable_dtypes=False, or vice versa.
In pandas all you need is a single global config option, pd.set_option("string_storage", "pyarrow"), to switch to arrow strings; I don't see why it should be any different in dask?

doesn't work

I agree this is still erroring, but the dispatching to pyarrow dtypes appears to be working. The Not all columns are categoricals seems like a separate issue.

From it, I can't understand what happens (or what's the benefit) from having dataframe.dtype_backend="pyarrow" and use_nullable_dtypes=False, or vice versa.

We could add a note about dataframe.dtype_backend only having an effect when use_nullable_dtypes=True

In pandas all you need is a single global config option, pd.set_option("string_storage", "pyarrow"), to switch to arrow strings; I don't see why it should be any different in dask?

https://github.com/dask/dask/pull/9711 implements the string_storage approach in dask. The dataframe.dtype_backend config option matches the upcoming behavior in pandas 2.0.

I believe this is fixed now.
Retested on dask 2023.9.2, pandas 2.1, pyarrow 13


StarRocks airbyte.  Support ssl

For tracking

@brmei

https://github.com/liuzhongjun89/starrocks-airbyte-connector/pull/14

https://reflectoring.io/comparison-of-java-http-clients/


ModuleNotFoundError: No module named 'auth'

Traceback (most recent call last):
File "/Users/miluyu/Documents/develop/coze.py", line 1, in
from cozepy import Coze, TokenAuth
File "/usr/local/lib/python3.9/site-packages/cozepy/init.py", line 1, in
from auth import Auth, PersonalAccessToken
ModuleNotFoundError: No module named 'auth'

please upgrade to v0.2.0: pip install -U cozepy


[BUG] Grouped Variable Logic does not work as expected

Version: v<IP_ADDRESS> V.A11-2
Trying this statement:
#(if [@[critmod];@[reachmod];@[damage];@[lifepoints]] != #empty then true else false)#
It should resolve into true if any of the @ references has a value - false if none has any.
For @[damage] having a value of 1 the expression resolves to false. I expected it to resolve to true. Am I too tired to use booleans properly?

That's not quite how the grouped logic check works.
From the manual:

You can use the if statement with groups. The x and y values listed
above can be formatted as:
[val1;val2;val3]
Allowing multiple items to be compared to multiple other items. The x set
of strings is sought in the y set. The comparison is successful if all of the
items in x exist in y. (the y set is not checked for existing in x)

I wouldn't bother with groups for that. I think this would accomplish what you want:
#(if @[critmod]@[reachmod]@[damage]@[lifepoints] != #empty then true else false)#
Basically it would be an empty string if they are all blank. Otherwise it will be non-empty.


Add gathering logs from provisioning.

Fixed: #1156.

Automated message from Dropbox CLA bot
@TomaszKolek, it looks like you've already signed the Dropbox CLA. Thanks!

Merged, after fixing the commit message to present tense ("Fixes", not "Fixed") since that's the style for our commit messages in general.  Thanks @TomaszKolek!


<IP_ADDRESS> ip specified in script when localhost would be preferable.

Would be nice to have maybe additional messaging here: https://github.com/chaostoolkit-incubator/community-playground/blob/314a3a75e2651172db455e6abd289313e9f4e49e/yummynoodle/flask-menu-service/app.py#L58


Add Support for 12hr and 24hr clocks in [Adhan Time] ...

Extension
https://www.raycast.com/mzaien/adhan-time
Description
It will be nice to have 12hr clock format in the menu bar widget.
Who will benefit from this feature?
No response
Anything else?
No response

Hello @harisvsulaiman sorry for being late, an update having this feature was released just now
https://github.com/raycast/extensions/pull/4320


Add missing :modify_algorithms documentation

Related to https://github.com/tlux/sftp_client/pull/22, add documentation omitted in that Pull Request

Thank you, @morinap ! :)


More modular dependencies

Our environments expand 5x in size because all these dependencies that we don't use are installed. It makes our CI builds take longer.
Offering something like extras_requires{'tensorflow': ['tensorflow>=1.14'], ...} should greatly help.
The docutils package isn't even necessary.

@illeatmyhat Most likely tensorflow 1.15 might work, although I probably need to test a bit more. However tensforflow 2.x would need some significant changes.
There are two issues with tensorflow upgrade:
(a) Some code used in aix360 algorithms will need to be modified
(b) dependencies on other libraries such as Lime, Shap, etc. as we would like these to work too.
You could probably upgrade tensorflow, but not everything will work. So its a balance between offering all explainability functions using a selected set of library versions versus offering only some explainability functions using a larger collection of compatible library versions.
Hope we can make the code compatible with higher versions of tensorflow soon. If you are able to get the algorithms to work on other versions of the library, please do suggest those changes through a pull request.

That's not what I was asking.
I was asking to make tensorflow an optional dependency.
As in, dont install it at all.

@illeatmyhat Thanks for pointing out this problem. We had planned to include the dependencies related to the main 8 explainability algorithms under install_requires (CEM requires tensorfow).
I'm not sure if we can immediately decouple the libraries under install_requires and extras_requires. However, we'll definitely keep your idea in mind for a future update.


Update README.md

99% done. Just need to put the report PDF and paste the demo video link in.

Can we add Tech Stack puppy eyes? Like that one section in your script

Fine, after my dinner please =)) @LaansDole

Can we add Tech Stack puppy eyes? Like that one section in your script

Fine, after my dinner please =)) @LaansDole

I won't include Postman though, just gonna keep it simple like in the slides:

Happy now @LaansDole? =))


pip install misaka setup error in ubuntu 15.10 64-bit

Collecting misaka
  Using cached misaka-2.0.0.tar.gz
    Complete output from command python setup.py egg_info:
    gcc: error: i386: No such file or directory
    gcc: error: x86_64: No such file or directory
    gcc: error: unrecognized command line option ‘-arch’
    gcc: error: unrecognized command line option ‘-arch’
    gcc: error: unrecognized command line option ‘-Qunused-arguments’
    gcc: error: i386: No such file or directory
    gcc: error: x86_64: No such file or directory
    gcc: error: unrecognized command line option ‘-arch’
    gcc: error: unrecognized command line option ‘-arch’
    gcc: error: unrecognized command line option ‘-Qunused-arguments’

        No working compiler found, or bogus compiler options
        passed to the compiler from Python's distutils module.
        See the error messages above.
        (If they are about -mno-fused-madd and you are on OS/X 10.8,
        see http://stackoverflow.com/questions/22313407/ .)
    Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "/tmp/pip-build-Ttx3lI/misaka/setup.py", line 68, in <module>
        cffi_modules=['build_ffi.py:ffi'],
      File "/usr/lib/python2.7/distutils/core.py", line 111, in setup
        _setup_distribution = dist = klass(attrs)
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/setuptools/dist.py", line 268, in __init__
        self.fetch_build_eggs(attrs['setup_requires'])
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/setuptools/dist.py", line 313, in fetch_build_eggs
        replace_conflicting=True,
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 836, in resolve
        dist = best[req.key] = env.best_match(req, ws, installer)
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 1081, in best_match
        return self.obtain(req, installer)
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 1093, in obtain
        return installer(requirement)
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/setuptools/dist.py", line 380, in fetch_build_egg
        return cmd.easy_install(req)
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 638, in easy_install
        return self.install_item(spec, dist.location, tmpdir, deps)
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 668, in install_item
        dists = self.install_eggs(spec, download, tmpdir)
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 851, in install_eggs
        return self.build_and_install(setup_script, setup_base)
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 1079, in build_and_install
        self.run_setup(setup_script, setup_base, args)
      File "/home/zeno/mostfun/june/venv/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 1067, in run_setup
        raise DistutilsError("Setup script exited with %s" % (v.args[0],))
    distutils.errors.DistutilsError: Setup script exited with 1

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-Ttx3lI/misaka

i tried to use pip install misaka on debian, it's no problem. git clone source and build it on ubuntu 15.04, also done.

I see No working compiler found, or bogus compiler options. Did you install gcc on Ubuntu?

certainly... i'm confident that.

i have built it from source.

Is the path to the gcc executables also in the $PATH environment variable?
I'll setup an Ubuntu vm later today (I just woke up) and see if I can reproduce this issue.

path has no problem, i can use pip to install uwsgi by gcc.

Any update on this in order to solve it, @ethe ?

@ReneFroger Nope, you can try install misaka by building from source.

I just tested on Ubuntu and Xubuntu and everything works.
I had to install python-dev and libffi-dev.

I'm confident that I have installed python-dev and libffi-dev before, did you installed the latest version(15.10) of ubuntu in test?
A strange thing, I tried to use pip install miska just now in a clean virtualenv, it works no problem. But when I attempted install misaka in global, I got an error like this:
zeno@go:~$ sudo pip install misaka
The directory '/home/zeno/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
The directory '/home/zeno/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Collecting misaka
  Downloading misaka-2.0.0.tar.gz (121kB)
    100% |████████████████████████████████| 122kB 211kB/s
Requirement already satisfied (use --upgrade to upgrade): cffi>=1.0.0 in /usr/lib/pypy/lib_pypy (from misaka)
Installing collected packages: misaka
  Running setup.py install for misaka
    Complete output from command /usr/bin/pypy -c "import setuptools, tokenize;__file__='/tmp/pip-build-WOEXNs/misaka/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-VqVy4s-record/install-record.txt --single-version-externally-managed --compile:
    running install
    running build
    running build_py
    creating build
    creating build/lib.linux-x86_64-2.7
    creating build/lib.linux-x86_64-2.7/misaka
    copying misaka/callbacks.py -> build/lib.linux-x86_64-2.7/misaka
    copying misaka/constants.py -> build/lib.linux-x86_64-2.7/misaka
    copying misaka/utils.py -> build/lib.linux-x86_64-2.7/misaka
    copying misaka/__init__.py -> build/lib.linux-x86_64-2.7/misaka
    copying misaka/api.py -> build/lib.linux-x86_64-2.7/misaka
    running build_ext
    generating cffi module 'build/temp.linux-x86_64-2.7/misaka._hoedown.c'
    creating build/temp.linux-x86_64-2.7
    building 'misaka._hoedown' extension
    creating build/temp.linux-x86_64-2.7/build
    creating build/temp.linux-x86_64-2.7/build/temp.linux-x86_64-2.7
    creating build/temp.linux-x86_64-2.7/misaka
    creating build/temp.linux-x86_64-2.7/misaka/hoedown
    cc -O2 -fPIC -Wimplicit -Imisaka -I/usr/lib/pypy/include -c build/temp.linux-x86_64-2.7/misaka._hoedown.c -o build/temp.linux-x86_64-2.7/build/temp.linux-x86_64-2.7/misaka._hoedown.o
    build/temp.linux-x86_64-2.7/misaka._hoedown.c:2:20: fatal error: Python.h: No such file or directory
    compilation terminated.
    error: command 'cc' failed with exit status 1

    ----------------------------------------
Command "/usr/bin/pypy -c "import setuptools, tokenize;__file__='/tmp/pip-build-WOEXNs/misaka/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-VqVy4s-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-WOEXNs/misaka
zeno@go:~$ cc
cc: fatal error: no input files
compilation terminated.

I tested it on the latest Ubuntu in Virtualbox. I can install everything without problems. Same for Xubuntu.
build/temp.linux-x86_64-2.7/misaka._hoedown.c:2:20: fatal error: Python.h: No such file or directory
That's the error you usually get when python-dev is not installed.

I'm sure I have already installed python-dev... If not, why could I bulit it from source?

I found what happend,  sudo -H python /usr/local/bin/pip install misaka can install correctly. Because I installed pypy before and pypy's pip replace the alias pip from cpython.

I watched this issue, but and my issue seems solved now.

Do you know what solved it for you?

Yes, I believe. Thanks to your comment, had to install python-dev and libffi-dev.

Hey Guys,
I'm really struggling to get misaka up and running, it keeps on telling me that module 'misaka' has no attribute 'html'.Please help out if you can
Thank You


Implement support for rust-version field in project metadata

Needs a bunch more work, but I'd like some early feedback! Remaining work:

[ ] Bikeshedding name (picked rust-version here over msrv or min-rust-version)
[ ] Failing test for local dependency with unsatisfied MSRV
[ ] Requirement cannot be smaller than 1.27
[x] Requirement cannot be smaller than initial release of edition used
[ ] Check for run, verify and publish subcommands
[ ] More tests (would love feedback on this)
[x] Handle pre-release identifiers
[x] Disallow semver range operators
[x] Feature gate it
[x] Add documentation for unstable feature

Minimal version of @moxian's earlier take in #7801.
cc rust-lang/rust#65262

r? @ehuss
(rust_highfive has picked a reviewer for you, use r? to override)

I don't have strong opinions about the name.  rust-version sounds reasonable to me.
As for dependency support, I think this check will need to be done elsewhere. I'm not sure if there is a perfect spot. Maybe immediately after the call to build_unit_dependencies it can walk the unit graph and check each package. Or it could walk the unit graph in Context::compile (similar to the check_collisions check).  I think earlier might be better?
Other things to add to the todo list is:

Feature-gate it.
Add documentation (unstable.md).

I'm a bit confused why this is changing the Summary. Shouldn't it just be stored in the Package?
The RFC mentioned "semver format without range operators". Do you happen to remember why?
Unfortunately just checking a versionreq doesn't work well with pre-release identifiers like -nightly. rust-version="1.40" doesn't match those (the nightly/beta tests are failing).
I can't think of a lot more tests to add. The only thing I can think of is to add some registry packages to exercise that. It looks like you added the field to the cargo_test_support::registry::Package test structure, so I assume you intend to follow-through with that? In Package::publish it will need to add the field to Cargo.toml. Let me know if you have any questions about that.

Requirement cannot be smaller than 1.27

Why is this the case?

From the RFC:

Version can not be smaller than 1.27 (version in which package.rust field became a warning instead of an error).

@ehuss reverted the changes to Summary and RegistryPackage in favor of exposing this value through the Package, as you suggested. The current version handles the local dependency case, at least. Updated the task list.
I added the feature-gating, too, but I'm currently unsure how to then enable this feature for the tests. Any help there appreciated.

In the tests, you need to call .masquerade_as_nightly_cargo() on each p.cargo(…) invocation.  This makes cargo believe it is on the nightly channel.
For the manifest, you need to add cargo-features = ["rust-version"] at the top of every Cargo.toml.  This is the nightly-only opt-in mechanism for new fields.

:umbrella: The latest upstream changes (presumably #8073) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably #8068) made this pull request unmergeable. Please resolve the merge conflicts.

@ehuss this seems like a decent MVP to merge. Please have another look.

:umbrella: The latest upstream changes (presumably #8167) made this pull request unmergeable. Please resolve the merge conflicts.

Don't we need check for update sub-command?
I think we should avoid bumping dependencies to versions that break current rust-verion.

That was explicitly scoped out of RFC 2495.

Ping @djc:  do you think you'll be able to address the comments and rebase on master?

Ping @djc:  do you think you'll be able to address the comments and rebase on master?

I think for this, we don't need a specific -Z flag, so I think rust_version can be removed from CliUnstable. Just when the user passes the --ignore-rust-version flag, it should call fail_if_stable_opt in command_prelude.rs to ensure the user also passed in -Z unstable-options. Search around for some examples of using that method.
For nightly/unstable features, there are two independent opt-in mechanisms. The cargo-features = […] in Cargo.toml is for allowing unstable syntax in Cargo.toml. This is checked by the features.required(Feature::rust_version()) which you have correctly added. The command-line -Z flags are only needed for CLI extensions (things that don't appear in Cargo.toml). How those are used depend on the situation:

If there is just a new flag, like --config, then you call config.unstable_flags.fail_if_stable_opt(...) to ensure the user also passed in -Z unstable-options to enable it.
If there is new behavior that otherwise doesn't have any new CLI options, then we add a new -Z flag to the CliUnstable struct, and then check config.cli_unstable().my_feature_name. Unstable -Z flags are already rejected on non-nightly channels.

There is a bit of documentation on this at https://doc.crates.io/contrib/process/unstable.html and in the features module.

As for centralizing the argument, there are a set of arguments that are essentially the same for every "build-like" command. That is:

bench
build
check
doc
fix
run
rustc
rustdoc
test

So we don't have to fuss with ensuring that these commands always include the right options, I was thinking it would be nice just to have an arg_build_common() method in command_prelude.rs that adds those options. It should call:

arg_features
arg_jobs
arg_target_triple
arg_target_dir
arg_manifest_path
arg_message_format
arg_ignore_rust_version

It's up to you if you want to do that. Otherwise, just make sure the list above is covered by arg_ignore_rust_version. I think adding a common method would help when we add more flags in the future that need to be included in all of these commands.

I think for this, we don't need a specific -Z flag, so I think rust_version can be removed from CliUnstable. Just when the user passes the --ignore-rust-version flag, it should call fail_if_stable_opt in command_prelude.rs to ensure the user also passed in -Z unstable-options. Search around for some examples of using that method.
For nightly/unstable features, there are two independent opt-in mechanisms. The cargo-features = […] in Cargo.toml is for allowing unstable syntax in Cargo.toml. This is checked by the features.required(Feature::rust_version()) which you have correctly added. The command-line -Z flags are only needed for CLI extensions (things that don't appear in Cargo.toml). How those are used depend on the situation:

If there is just a new flag, like --config, then you call config.unstable_flags.fail_if_stable_opt(...) to ensure the user also passed in -Z unstable-options to enable it.
If there is new behavior that otherwise doesn't have any new CLI options, then we add a new -Z flag to the CliUnstable struct, and then check config.cli_unstable().my_feature_name. Unstable -Z flags are already rejected on non-nightly channels.

There is a bit of documentation on this at https://doc.crates.io/contrib/process/unstable.html and in the features module.

As for centralizing the argument, there are a set of arguments that are essentially the same for every "build-like" command. That is:

bench
build
check
doc
fix
run
rustc
rustdoc
test

So we don't have to fuss with ensuring that these commands always include the right options, I was thinking it would be nice just to have an arg_build_common() method in command_prelude.rs that adds those options. It should call:

arg_features
arg_jobs
arg_target_triple
arg_target_dir
arg_manifest_path
arg_message_format
arg_ignore_rust_version

It's up to you if you want to do that. Otherwise, just make sure the list above is covered by arg_ignore_rust_version. I think adding a common method would help when we add more flags in the future that need to be included in all of these commands.

I have not grouped the build common options in this PR, I might do a follow-up to improve the situation there.

I have not grouped the build common options in this PR, I might do a follow-up to improve the situation there.

From the RFC:

Version can not be smaller than 1.27 (version in which package.rust field became a warning instead of an error).

I don't know if/how to implement this. I think Cargo will now still error if the unstable field gets used. I could restrict it for now to not allow it to be smaller than 1.51, if that makes sense, but that version should eventually probably be adjusted to the version that stabilizes this field.

From the RFC:

Version can not be smaller than 1.27 (version in which package.rust field became a warning instead of an error).

I don't know if/how to implement this. I think Cargo will now still error if the unstable field gets used. I could restrict it for now to not allow it to be smaller than 1.51, if that makes sense, but that version should eventually probably be adjusted to the version that stabilizes this field.

Thanks!
As for the 1.27 floor, I think the intent is: let's say it gets stabilized in version 1.60.  A project whose MSRV is 1.35 can specify 1.35 in the manifest to make it clear what their MSRV is.  Even though older versions will ignore it, I think it makes sense to specify the actual version instead of the version when it first starts getting honored.
However, thinking about that more, I think if this gets merged now, that means that versions starting with 1.51 will never be able to use this setting, because Cargo will complain about an unstable feature.  I'm concerned that this will make it very difficult to use for a long time (until a project's MSRV reaches whenever it is stabilized, which could be a year or more).
Since this feature is fundamentally about improving MSRV support, I think that may be a bad way to start it off.  This key is not critical (it doesn't actually change anything).  I'm thinking instead of calling unstable_features.require(...) in toml/mod.rs it could instead do something like this:
if features.require(Feature::rust_version()).is_err() {
    warnings.push(
        "`rustc-version` is not supposed on this version of Cargo and will be ignored"
            .to_string(),
    );
}

Maybe include a check to nightly_features_allowed() and add a hint about how to enable it on nightly (similar to how require() works).
I think that should be safe to do, it will just print a warning just like any other unknown key.

Thanks!
As for the 1.27 floor, I think the intent is: let's say it gets stabilized in version 1.60.  A project whose MSRV is 1.35 can specify 1.35 in the manifest to make it clear what their MSRV is.  Even though older versions will ignore it, I think it makes sense to specify the actual version instead of the version when it first starts getting honored.
However, thinking about that more, I think if this gets merged now, that means that versions starting with 1.51 will never be able to use this setting, because Cargo will complain about an unstable feature.  I'm concerned that this will make it very difficult to use for a long time (until a project's MSRV reaches whenever it is stabilized, which could be a year or more).
Since this feature is fundamentally about improving MSRV support, I think that may be a bad way to start it off.  This key is not critical (it doesn't actually change anything).  I'm thinking instead of calling unstable_features.require(...) in toml/mod.rs it could instead do something like this:
if features.require(Feature::rust_version()).is_err() {
    warnings.push(
        "`rustc-version` is not supposed on this version of Cargo and will be ignored"
            .to_string(),
    );
}

Maybe include a check to nightly_features_allowed() and add a hint about how to enable it on nightly (similar to how require() works).
I think that should be safe to do, it will just print a warning just like any other unknown key.

Resolved your final comments and changed the error to warn (including tests for both nightly and stable).

Resolved your final comments and changed the error to warn (including tests for both nightly and stable).

Looks good, thanks! 🎉
@bors r+

Looks good, thanks! 🎉
@bors r+

:pushpin: Commit c221fec91119cd94a3043cc19566ed61d4f5c13d has been approved by ehuss

:pushpin: Commit c221fec91119cd94a3043cc19566ed61d4f5c13d has been approved by ehuss

:hourglass: Testing commit c221fec91119cd94a3043cc19566ed61d4f5c13d with merge 8e075c9cab41eb1ed6222f819924999476477f2e...

:hourglass: Testing commit c221fec91119cd94a3043cc19566ed61d4f5c13d with merge 8e075c9cab41eb1ed6222f819924999476477f2e...

Thanks for the reviews!

Thanks for the reviews!

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 8e075c9cab41eb1ed6222f819924999476477f2e to master...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 8e075c9cab41eb1ed6222f819924999476477f2e to master...


Fixed PILLOW_VERSION import error with pillow v7.0

torchvision import breaks with pillow's recent update to v7.0.0.
Release notes for pillow v7.0.0 say: PILLOW_VERSION has been removed. Use __version__ instead.
Issue: torchvision tries to import PILLOW_VERSION which causes problems.
Fixed this by constraining pillow version to 6.2.1 in the environment.yml file. (conda does not yet have 6.2.2)
This is a workaround until a new version of torchvision is officially released.
More info here:
https://github.com/pytorch/vision/issues/1712
https://github.com/pytorch/vision/issues/1712#issuecomment-570535277

No, we do not want to constrain pillow. There is a proper version of torchvision that deals with the import problem, if we did a constrain, it would be on this.

I see. Just saw torchvision 0.5.0 deals with this already. (https://github.com/pytorch/vision/releases)
My bad. Should’ve checked properly.


USB Camera Support

It is worth noting that on Android 8.0 and above, USB camera support should just work correctly. This applies to older android versions.
Also worth noting that not all Android devices operate the same, and you may still run into an issue above android 8.0 where the USB webcam does not work.
USB Webcam support and microphone support works on the REV Robotics Control Hub


fix: 🐛 ENAMETOOLONG when using long filenames

✅Closes: #309
Description
Uses sha1 hash for filename when using external images.
Fixes #309
Type of change
Please delete options that are not relevant.

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

How Has This Been Tested?
E2E test updated. But need a file with long name to test. Something from AWS S3 is perfect has it has a long parameters chain.
Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[X] My changes generate no new warnings

Yeah, using the SHA-1 hash seems like a good choice for this since it'll behave consistently.
I went ahead and tested it with the repo I was having issues with earlier, and it worked without issue.


Gradle is not able to run docker command from cli on macOS

Current Behavior
Having the following task:
tasks.create("test-docker") {
    doLast {
        exec {
            workingDir = File(".")
            commandLine = listOf("docker", "compose", "up", "-d", "-f", "local/docker-compose.yml")
        }
    }
}

it's run fails with the following error:
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':some-project:test-docker'.
> A problem occurred starting process 'command 'docker''

But if to try to test another cli command for instance git like:
tasks.create("test-docker") {
    doLast {
        exec {
            workingDir = File(".")
            commandLine = listOf("git", "logs")
        }
    }
}

It runs well.
If to run docker from cli from the same directory as gradle it runs well.
Expected Behavior
Command runs successfully.
It stopped working when we migrated to 21st java and Gradle 8.6. Tried different distributions of java - same result.
Context (optional)
Trying to run docker cli from gradle
Steps to Reproduce
Running the following task causes an error:
tasks.create("test-docker") {
    doLast {
        exec {
            workingDir = File(".")
            commandLine = listOf("docker", "compose", "up", "-d", "-f", "docker-compose.yml")
        }
    }
}

If to run this task with --full-stacktrace the following stacktrace prints:
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':some-project:test-docker'.
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:148)
	at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:282)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:146)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:134)
	at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
	at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
	at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
	at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:74)
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
	at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
	at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
	at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:42)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:331)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:318)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.lambda$execute$0(DefaultTaskExecutionGraph.java:314)
	at org.gradle.internal.operations.CurrentBuildOperationRef.with(CurrentBuildOperationRef.java:80)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:314)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:303)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:463)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:380)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'docker''
	at org.gradle.process.internal.DefaultExecHandle.execExceptionFor(DefaultExecHandle.java:241)
	at org.gradle.process.internal.DefaultExecHandle.setEndStateInfo(DefaultExecHandle.java:218)
	at org.gradle.process.internal.DefaultExecHandle.failed(DefaultExecHandle.java:386)
	at org.gradle.process.internal.ExecHandleRunner.lambda$run$3(ExecHandleRunner.java:102)
	at org.gradle.internal.operations.CurrentBuildOperationRef.with(CurrentBuildOperationRef.java:80)
	at org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:101)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: net.rubygrapefruit.platform.NativeException: Could not start 'docker'
	at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:27)
	at net.rubygrapefruit.platform.internal.WrapperProcessLauncher.start(WrapperProcessLauncher.java:36)
	at org.gradle.process.internal.ExecHandleRunner.startProcess(ExecHandleRunner.java:122)
	at org.gradle.process.internal.ExecHandleRunner.lambda$run$0(ExecHandleRunner.java:80)
	at org.gradle.internal.operations.CurrentBuildOperationRef.with(CurrentBuildOperationRef.java:80)
	at org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:79)
	... 5 more
Caused by: java.io.IOException: Cannot run program "docker" (in directory "/Users/user1/some-project"): error=2, No such file or directory
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1170)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1089)
	at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:25)
	... 10 more
Caused by: java.io.IOException: error=2, No such file or directory
	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
	at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:295)
	at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:225)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1126)
	... 12 more

Gradle version
8.6
Build scan URL (optional)
No response
Your Environment (optional)
Mac on Intel chip with OS version 14.3.1 but it doesn't matter as the same issue reproduces for my colleagues as well.

Now I'm sure that this happens because of java. The problematic code is in java.lang.ProcessImpl in the following constructor:
private ProcessImpl(final byte[] prog,
                final byte[] argBlock, final int argc,
                final byte[] envBlock, final int envc,
                final byte[] dir,
                final int[] fds,
                final boolean forceNullOutputStream,
                final boolean redirectErrorStream)
            throws IOException {

        pid = forkAndExec(launchMechanism.ordinal() + 1,
                          helperpath,
                          prog,
                          argBlock, argc,
                          envBlock, envc,
                          dir,
                          fds,
                          redirectErrorStream);
        processHandle = ProcessHandleImpl.getInternal(pid);

        try {
            AccessController.doPrivileged((PrivilegedExceptionAction<Void>) () -> {
                initStreams(fds, forceNullOutputStream);
                return null;
            });
        } catch (PrivilegedActionException ex) {
            throw (IOException) ex.getCause();
        }
    }

That call of forkAndExec fails if as prog argument to pass "docker".getBytes() then it fails with an exception I've described above. If to pass there "/usr/local/bin/docker".getBytes() it works. But the thing is that /usr/local/bin is in PATH. So that's why I suppose that problem is in java.
Moreover they "improved" something in 21 java.
Java 21 has enhanced its tools such as ‘Runtime.exec’ and ‘ProcessBuilder’ which are used to start new processes like running a new program.

I understand that it sounds strange, but maybe you able to open a bug in java for this case?

This issue will be closed as a duplicate of

https://github.com/gradle/gradle/issues/28300
https://github.com/gradle/gradle/issues/10483

Please add your use case and 👍 to that issue.
If you think our analysis is wrong, please provide us with more detailed information explaining why.

I had the same issue while using this plugin: https://github.com/avast/gradle-docker-compose-plugin.
I tested something similar to your task:
tasks.create("test-docker") {
    doLast {
        exec {
            workingDir = File(".")
            commandLine = listOf("docker", "ps")
        }
    }
}

and was having the same issue.
In my case, it was due to the Gradle daemon. In those cases you can do: ./gradlew --stop and retry your task. This fixed it for me at least and I think it could also be the fix for others.

Same here, however there is one thing that helps me: stopping the daemon (./gradlew --stop)
Still, not normal.


add support for configurations with separate pools for different databases

This enhancement would provide flexibility in managing database connections and optimize resource utilization for different aspects of any system.

added with #598


git-nomad: 0.7.1 -> 0.8.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/rraval/git-nomad/releases.
meta.description for git-nomad is: Synchronize work-in-progress git branches in a light weight fashion
meta.homepage for git-nomad is: https://github.com/rraval/git-nomad
meta.changelog for git-nomad is: https://github.com/rraval/git-nomad/blob/v0.8.0/CHANGELOG.md
Updates performed

Rust version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.8.0 with grep in /nix/store/8f09hdicssnrn1q19f6hbs9cyk871s8n-git-nomad-0.8.0
found 0.8.0 in filename of file in /nix/store/8f09hdicssnrn1q19f6hbs9cyk871s8n-git-nomad-0.8.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

git-nomad

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/8f09hdicssnrn1q19f6hbs9cyk871s8n-git-nomad-0.8.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A git-nomad https://github.com/r-ryantm/nixpkgs/archive/b9293993521890e46126a6814f90041c1f8dfe33.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/b9293993521890e46126a6814f90041c1f8dfe33#git-nomad

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/8f09hdicssnrn1q19f6hbs9cyk871s8n-git-nomad-0.8.0
ls -la /nix/store/8f09hdicssnrn1q19f6hbs9cyk871s8n-git-nomad-0.8.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 1 package built:

git-nomad

Maintainer pings
cc @rraval for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge


Update aws-core, http-client-spi, ... to 2.17.279

Updates

software.amazon.awssdk:aws-core
software.amazon.awssdk:http-client-spi
software.amazon.awssdk:netty-nio-client

from 2.17.276 to 2.17.279.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "software.amazon.awssdk" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #972.


Ability to add generic per-band attributes

The product definition document used by the Open Data Cube (e.g. Sentinel-2 in Digital Earth Africa) may contain additional per-band attributes. In the case of Sentinel-2, the key attribute is the flags_definition for the SCL band, which contains pixel-quality information such as the mapping between SCL values and classes (e.g. '3': cloud shadows). This is critical to add to the returned xarray to enable cloud masking at later stages.
I am not currently able to add the band-level attribute through the configuration dictionary. My workaround is to manually add the desired attribute to the specific band after loading:
ds_stac = odc.stac.load(
    ...,
    bands=(... 'SCL'),
    ...
)

ds_stac["SCL"] = ds_stac.SCL.assign_attrs(flags_definition = {'qa': {'bits': [...], 'values': {...}, 'description': ...}})

I am curious whether:

the configuration dictionary handling could be updated to also add any generic attribute for individual bands
alternatively, whether there's a way to provide the load with an ODC product definition and have the metadata come from that rather than a user-defined config.

The second idea would be my preference, but I don't have a good feel as to whether that's in scope for this package. My ultimate goal is to make the xarray returned from odc.stac.load for an ODC STAC as similar as possible to the xarray returned from datacube.load for the same ODC data.

Thanks @caitlinadams, tangentially related issue https://github.com/opendatacube/odc-geo/issues/117
This won't be a huge addition if we stick with "user-supplied only" interface. I guess config dictionary is the right spot for this, although we have been moving away from relying on this parameter, for example per band dtype and nodata can be configured via a more direct dtype= and nodata= arguments. Maybe attrs: dict[band_name, dict[str, Any]] would fit better to match dtype= behaviour.

Thanks @Kirill888 -- I agree that this is related to the odc-geo issue on opinionated masking.
I hadn't realised that odc-stack can handle both dtype and nodata as keyword args, although in my current reading of the code, dtype is an explicitly listed kwarg, whereas nodata can be supplied through **kw  and accessed later in the resolve_load_cfg function.
I think it's a reasonable suggestion to have a keyword argument for additional attributes, matching the dtype= behaviour. Is this something that you think is worth implementing in the short term? Does it have flow-on effects for the odc-geo opinionated masking conversation? I'm wondering if you would ever make it a requirement for a band to have the flag information as a band attribute to be able to use a generic or opinionated masking function.

Looking at the source code, my current understanding is that dtype is an explicitly listed kwarg, whereas nodata can be supplied through **kw and accessed later in the resolve_load_cfg function. Is that correct?

looks like it, inconsistent for sure, also nodata= only supports "apply to all bands", whereas dtype can be applied per band. This needs to be harmonized. Not sure about reasons for it, probably just "happened" that way.
https://github.com/opendatacube/odc-stac/blob/e8692baef853833e1b4766d6d652ea3d25afdb08/odc/stac/loader/_reader.py#L20-L27
We should probably apply this to most user supplied settings:

✅ dtype
✅ resampling
❌ nodata should be expanded to allow override per band
❌ use_overviews probably global setting is ok for this one
❌ attrs to be added

That sounds good to me, thanks. Once you've implemented this, I would be happy to take a look at updating the docs/examples to make this functionality clearer, and perhaps move away from the config approach.


Provide an Isolate.packageSpecUri getter

Currently, it's very awkward to spawn a Dart process and reliably pass it the same package context that the parent context was using. You can pass the --package-root flag if Isolate.packageRoot is set, but Isolate.packageSpec is a map rather than a URI and as such can't be passed to a process. If we had Isolate.packageSpecUri, it could be passed as the --packages flag.
Having to create a packages data URI out of the map is clunky.

It is the plan to have packageRoot and packageFile on Platform which returns the actual command line parameters. There is no guarantee that those parameters correspond to the current isolate's package resolution, but it will tell you how the Dart process was spawned.
Also, I think it's very bad style to start a new Dart process based on the current Dart process' settings. It's mixing tings that really belong in different settings (configuration of the current VM and data being processed by the running program).
Preferably, you should not need to execute a new Dart process - an Isolate.spawnUri will often be enough. If it isn't, you may be using special VM parameters that we can't guarantee the stability of.

Also, I think it's very bad style to start a new Dart process based on the current Dart process' settings

That may be true, but it would be useful to hear more about the use cases for this pattern.

you may be using special VM parameters that we can't guarantee the stability of.

For example? If I understand, --package-root and --packages are stable and can be relied on.

It is the plan to have packageRoot and packageFile on Platform which returns the actual command line parameters. There is no guarantee that those parameters correspond to the current isolate's package resolution, but it will tell you how the Dart process was spawned.

This isn't sufficient. We need a reliable way to get a URI that communicates the current Isolate's package resolution. Otherwise, the logic will fail in tools like pub that start isolates for sub-applications.

Also, I think it's very bad style to start a new Dart process based on the current Dart process' settings. It's mixing tings that really belong in different settings (configuration of the current VM and data being processed by the running program).

I don't understand why it would be bad style. How else would you start a Dart subprocess in a test that can import libraries from the current package?
In practice, Dart code is run in many different entrypoint contexts—directly from the command line, via an isolate with various sorts of configuration, via a programmatically-executed process, etc. Our code should be written to work regardless of this context, and I don't see any way of doing that without copying over the package resolution configuration.

@sethladd

For example? If I understand, --package-root and --packages are stable and can be relied on.

Yes, --package-root, --packages, --checked and -Dfoo=bar are all stable and can be relied on. There are parameters corresponding to those on spawnUri (not all implemented yet, but that's the goal, please help pushing for them to be implemented).
The parameters I'm talking about are VM specific things like --old_gen_heap_size, which you may want to change in extreme cases, but it's not something I'd want you to rely on in general.
@nex3

This isn't sufficient. We need a reliable way to get a URI that communicates the current Isolate's package resolution. Otherwise, the logic will fail in tools like pub that start isolates for sub-applications.

That assumes that there is a URI. If the current isolate was started using Isolate.spawnUri with a packages map, there won't be any URI at all. The mapping is available as Isolate.packageMap.
We bootstrap this by having the initial mapping stored in a file, but after that, mappings are represented by Map objects, not URIs to files. The file is just an external representation of the actual mapping.
If you really need to start a new Dart process with a custom mapping, you need to write that mapping to a file, or reuse an existing file when you know that one exists. Or use a data: URI if line length permits (and it's implemented, I don't know if it is).

I don't understand why it would be bad style. How else would you start a Dart subprocess in a test that can import libraries from the current package?

It should be sufficient to use Isolate.spawnUri unless you want to start the process with extra VM-specific parameters. We haven't implemented all the spawnUri parameters yet, but that is the goal we aim towards. We shouldn't add features to work around other missing features, we should just implement the missing features.

The internal representation of a package-resolution map is a Map. There is not guaranteed to be any URI corresponding to it, and even if there is, that's only pointing to an external representation of the actual map.
We do not plan to expose the URI used to load that map other than as the actual command line parameter specified (in dart:io Platform).

The VM's internal representation isn't relevant—the Dart team writes the VM and can change it as necessary. We need to focus on user needs. If the VM doesn't currently keep around the original URI, then it should start doing so in order to support this feature. If we insist on supporting a Dart map parameter to Isolate.spawnUri, the VM/core libraries should convert that to a data: URI because that's what's useful to the user.

It should be sufficient to use Isolate.spawnUri unless you want to start the process with extra VM-specific parameters. We haven't implemented all the spawnUri parameters yet, but that is the goal we aim towards. We shouldn't add features to work around other missing features, we should just implement the missing features.

Regardless of what "should be", right now it's very clearly not sufficient. There are tons of things that can be done with a process that can't with an Isolate: a process can have different environment variables, can be detached, can have its stdio interacted with, can be signaled, can safely call exit(), can have its exit code read. When you're doing something like testing a command-line API, Isolates are nowhere near sufficient.
Maybe all of these features could somehow be added to the Isolate API, but the fact is they're not there now. If we want to move towards a world without package symlinks in the next few releases, we need to have a package-spec-based alternative for everything people were using them for, this included.

This is not about the VM's internal representation, it's about the Dart libraries choice of representation.
I have no idea what the VM does internally, but it provides the data as a Map because that's what we want it to do. A package resolution is specified by a mapping from package name to URI. In Dart code, the representation of that is a Map from String to Uri. The .packages file is just a serialization of that logical mapping, it is not the mapping itself. In Dart code, maps are the objects you should use.

Regardless of what "should be", right now it's very clearly not sufficient.

I know that. The solution to that is to implement the missing features, not to implement other features to work around the missing features. I'm all for prioritizing this implementation! If you can use existing features to work around the ones that are missing, great, but adding features that won't be necessary in the long run is a waste of time.
If you really need to test a command line application, and need to start a new Dart process, you should control its parameters explicitly, not rely on reflecting what the current running Dart process happens to be using. That sound like it would be very fragile.
If you want to do it anyway, you should be able to deduce how the current process was started from the Platform properties: script, packageRoot and packagesFile (or whatever the last one is named, it's the command line --packages parameter). You can start a new process with the same parameters with very little effort. There is no need for the VM to produce a resolved version of the command line parameter.
If anything, we can make a helper package for spawning DartVM processes which can do the stuff for you. That would be the right place for such logic - take one DartVM process (the current) and create another one from that with some changes applied.

packagesFile

I don't see that in Platform: https://api.dartlang.org/134093/dart-io/Platform-class.html  Are we intending to add that? If so, that might be what @nex3 would like.

Yes, that is the intention, to match packageRoot.
(Still not sure whether it should be called packages, packagesFile or packageFile ... or something else, it will contain the content of the packages command line parameter).

I can't imagine we'll ever have isolates that match the full functionality of subprocesses. If we somehow do, it will be years from now. And even then, it's not clear to me that it will be concretely better in any way to test subprocesses via isolates than it will via Process. Process is always going to be closer to real world invocations, and that's important for tests.
We need this feature, and we need it soon, or our users—including us—won't be able to make their code work without symlinks. There's no real cost to exposing this other than a small amount of implementation time, and we have a clear concrete use-case for it.
Platform.packagesFile won't be sufficient, assuming it works similarly to Platform.packageRoot. It will be executable-global, which means it can't be reliably used to pass the current isolate's package resolution information to a subprocess. Also, it only matches the exact command-line argument, it won't be available if it was discovered implicitly and it may be invalid if the process's working directory has ever changed.

If you need to use process, by all means use process. But it's a completely different process then, and I don't think it should rely implicitly on however the current process was launched, and much less on how a specific isolate was spawned. If you really want to reify the current isolate's package resolution, we have a helper package for that (use Isolate.packageMap to get the map, and package:pacakge_config to write it to a file, then use that file, or use a data: URI if we support that and it fits on the command line).
If your isolate's package resolution doesn't match the original command line parameter, then there is no package-spec file. If there is a package root, you can get that from Isolate.packageRoot, otherwise Isolate.packageMap is the all you have - that map came from a map originally provided to spawnUri, there is no file we can point to. So, either Platform.packageFile is useful, or there is no useful file URI to provide.

If you really want to reify the current isolate's package resolution

This isn't something we can just write off as "I guess you can use this hacky workaround". It's an important use-case that your customers—including me—rely on. Having to depend on a new package and write a file to disk just to spawn a process is onerous and unperformant, especially since in the vast majority of cases the package spec we want to use is already there.

If your isolate's package resolution doesn't match the original command line parameter, then there is no package-spec file.

If the package spec was located based on the entrypoint's location rather than being passed in explicitly, there won't be a command-line parameter but there will be a file (or an HTTP URL).

If there is a package root, you can get that from Isolate.packageRoot, otherwise Isolate.packageMap is the all you have - that map came from a map originally provided to spawnUri, there is no file we can point to. So, either Platform.packageFile is useful, or there is no useful file URI to provide.

As I've pointed out repeatedly, this is a serious flaw in the API we're adding to spawnUri. If spawnUri took a URI rather than a map, that URI could be exposed as Isolate.packageSpecUri. As it is, in the common case where the package map comes from a file, that information is discarded.

Re-opening per discussion in https://github.com/dart-lang/sdk/issues/23951

This was landed


Documentation Roadmap

Tracking issue for documentation improvements.
Goals:

Provide a better onboarding experience for new users for all stages of REST API development using fern (design, build, document)
Document generator infrastructure and architecture
Document the generation of documentation by Fern
Move Fern's own docs to its own repository
Move Fern's own docs to the Fern documentation generation ecosystem

[x] fern-api/fern README overhaul - (#1832)
[ ] Generator READMEs (#1870)
[ ] Move Fern documentation to Fern's own documentation solution (#1871)
[ ] Move Fern documentation out of the core repository (#1871)

@aevitas up to continue working through the generator READMEs next?

Of course
On Thu, 20 Jul 2023, 03:55 Danny Sheridan, @.***> wrote:

@aevitas https://github.com/aevitas up to continue working through the
generator READMEs next?
—
Reply to this email directly, view it on GitHub
https://github.com/fern-api/fern/issues/1872#issuecomment-1642990380,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABE7AQA5APEJCEXHIIJCEDXRCFZPANCNFSM6AAAAAA2BU6QKI
.
You are receiving this because you were mentioned.Message ID:
@.***>

Boom 💥


[Question] Is it possible to get suggestion list dynamically?

For example, when i type:
git checkout <Tab>

It list all they branches on my current git repo.
Is this usecase possible with picocli?

Hi @nqminhuit , have you had a chance to read this?
https://picocli.info/autocomplete.html

thank you for your quick reply, so it's possible then, I will try to learn more about it.

There's JLine and bash completion.
Dynamic completion is easier with JLine.
It's possible with bash but you would have to customize the bash completion script generated by picocli. So picocli would only do the first half...

So if I use bash completion, I have to write additional bash functions for the dynamic parts?

Yes probably.


tests/test: Ensure the test fixture files have the expected gid

On some platforms (mostly the BSDs) the test fixture files copied to the /tmp directory will have a different gid than the current egid (due to the sticky bit set on the /tmp directory). Fix this before running the "test" command.

Checking the cspell failure.

Fixed the cspell failure.

Reviewed the failures for FreeBSD -- it looks like the test runner's primary group is "wheel", that explains why I see a different result on my local FreeBSD system and the pre commit tests.
I am thinking for this specific test_file_not_owned_by_egid test for FreeBSD specifically I could modify the testcase to check the gid of the /sbin/shutdown command, since the group config on that file is "operator", not "wheel". Will try it locally first.

I think the remaining failures might be an test infra issue (unless I missed one).

@sylvestre I don't know much about these things. Does this look good to you?


Error when downloading Bicep

Make sure Bicep CLI is not installed and remove old version of azd. I was able to azd up after I manually installed Bicep CLI using winget install -e --id Microsoft.Bicep
Repo steps:

install azd

D:\>azd version
azd version 0.5.0-beta.3 (commit 1c23678aade587d5b9685a256a3c1d2d7f4b42e0)

azd init -t todo-python-mongo
azd up

Initializing a new project (azd init)

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time

  (x) Failed: Downloading Bicep

ERROR: creating provisioning manager: error creating infra provider: error creating provider for type 'bicep' : downloading bicep: Get "https://downloads.bicep.azure.com/v0.12.40/bicep-win-x64.exe": dial tcp: lookup downloads.bicep.azure.com: no such host

Looks to be a transient DNS blip from the error message.

Just tried using a diff machine. No repo. Closing.


Restore clone-branch feature

Fixes #4083
Was renamed see https://github.com/primer/octicons/releases/tag/v12.0.0
Test URLs
https://github.com/fregante/webextension-polyfill/branches
https://github.com/yakov116/refined-github/branches
https://github.com/sindresorhus/refined-github/branches
Screenshot

This is one of the downsides of using select-observer, we do not get to see the errors.

Thanks!


pip install grpcio failed

some error message:

creating python_build/lib.linux-x86_64-3.7/grpc/_cython/_credentials
copying src/python/grpcio/grpc/_cython/_credentials/roots.pem -> python_build/lib.linux-x86_64-3.7/grpc/_cython/_credentials
running build_ext
error: [Errno 2] No such file or directory: 'cc': 'cc'

It seems that it needs C compiler to build this package. You will need to install gcc (apk add --no-cache gcc). It may also require some other dependencies like musl-dev, python3-dev.


[webapi] Remove test suites specific for Tizen support

https://crosswalk-project.org/jira/browse/XWALK-5273

@jennycao @chunywang

Since this pull request changes huge number of files, one can put .patch to this PR to check changed files. For example, https://github.com/crosswalk-project/crosswalk-test-suite/pull/2971.patch


[Fedora 25] Release notes window doesn't cover entire page

VSCode Version: 1.7, 1.8
OS Version: Fedora 25

Steps to Reproduce:

Check for new version
See the release notes page

The release notes doesn't cover entire window, but only a quarter. See the picture.

Note: this bug happened in 1.7, too.

Since the release notes are shown using a webview, I believe this issue is a duplicate of #5745


Strips flavor text from Recovery Checks

Use of this module removes the text accompanying Recovery Check rolls made from the PF2e Character sheet. The test is what explains/interprets the results of the Recovery Check. Without the text, it just shows up as a 1d20 roll with no explanation.

@Mr-Monocyte I cannot reproduce this with PF2e <IP_ADDRESS>26 or <IP_ADDRESS>07...

Either this is something the PF2e system recently changed and you just need to update your system, you're using some other module or changed some setting that is changing things, or I'm not understanding what you mean by Recovery Check rolls (I don't play Pathfinder, so that is entirely possible).
If updating PF2e fixes this for you, let me know so I can close this issue.
If not, please let me know in more detail exactly what you're doing, what other modules you have enabled (including their versions), and what settings you have for those modules so I can reproduce this.

Note: If PF2e did change how they handle Recovery Check chat messages, updating the system will only impact new chat messages, not old ones, so you'll need to roll a new Recovery Check to test that.

I'm closing this under the assumption that this is not an issue with the latest PF2e. If this is not the case, I'll need details on how to reproduce the issue before I can do anything.


Showcase Submission for 93-double-pendulum

Thank you Gwonchan Jason Yon for your contribution! A member of the Coding Train team will review it shortly.

Triple pendulum
Gwonchan Jason Yon

Great work! Did you mean to have the Samsung logo as your image?

@shiffman I replaced the Samsung logo with a screenshot of the sketch. We should be able to merge this.

Thank you @fturmel!


[Feature Request] Add ION - Scalable Decentralised Identifiers on Bitcoin

This would be great addition and it appears they have a point that it is most likely the missing link for Dapps
https://youtube.com/watch?v=kUb7ENx6Nyk   # a short overview
https://aka.ms/ion-beta-post    # Github etc. linked off this

The idea to add it to the RaspiBlitz you can find it already as an issue here: #1038 - it would be great is someone treis this out. On how to contribute to RaspiBlitz see here: https://www.youtube.com/watch?v=ZVtZepV3OfM

ION is now live: https://twitter.com/csuwildcat/status/1375125876736548870?s=20

https://twitter.com/csuwildcat/status/1375467632602705923  # guide for running on Pi4

Since this project is archived since Jul 21, 2022 I'm closing this for now.


Rip out WebSocketWriter's message splitting

An old version of OkHttp web sockets supported streaming messages,
so a writer could transmit partial bytes of a message without
completing it.
When we promoted Web Sockets as a core feature we dropped support
for streaming a single message. But we still had the mechanism
that implemented it.
This PR removes that mechanism, which should make it easier to
implement compression.

FYI @AntonRutkevich !


Fix Matrix.v for coq-8.11.0

ref: #5
To build SQIR in coq-8.11.0, I modified lemma id_kron in Matrix.v.
I removed L1361, and now I can compile Matrix.v with coq-8.11.0.
By the way, I got an error in compiling of Composition.v, but SQIR does not depends on this file. So I leave it.

I don't want to take this approach and break compatibility with Coq 8.10.
I've pushed a new fix, which I'll confirm works on 8.11 shortly.

I understand, Thank you so much !


Reason behind working on this project

I really liked the way you are working on this project, by not just using the Deep Learning models but also adding traditional technical analysis to it.
Can I know why you are working on this? An open-Source Consultation, or a Research Project, an assignment, or just out of interest?

The main reason is to learn all there is about time series projections, anomaly detection etc. Stocks just happen to be an interesting time series.


npm install fails

npm i react-native-router-flux --save
npm ERR! Darwin 15.0.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "i" "react-native-router-flux" "--save"
npm ERR! node v5.0.0
npm ERR! npm  v3.3.6

npm ERR! Invalid name: "@exponent/react-native-navigator"
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /foo/project/npm-debug.log

Just update npm if you get this
sudo npm install npm -g