Add more context details for exception printed for parameterOverloads validation

Description:
parameterOverloads annotation help to perform compile time validation for input parameters (for siddhi execution extension). It checks for possible  parameterOverloads and print an exception if there is no any matches.
See below exception trace, this could be improved by adding bit more contextual information of the exception. (such as possible supported parameterOverloads).
BayesianClassificationUpdaterStreamProcessorExtension TestCase - number of classes is not int
There is no parameterOverload for 'streamingml:updateBayesianClassification' that matches attribute types '[STRING, DOUBLE, STRING, STRING, DOUBLE, DOUBLE, DOUBLE, INT]'.

Affected Siddhi Version:
v5.0.2

Fixed in https://github.com/siddhi-io/siddhi/pull/1375 ...


Convert() function modifies input json variable

I think convert() function should do a deepcopy of the input json file. This behind the scenes side effect may cause some trouble when user want to use the same json input to do something else

Close this issue since this repo has zero activity right now


support file URLs

Thought we decided not to implement file scheme #75

Thx for the PR, Joshua. But we have no plan to add file protocol support. Fetch Spec offers no definition for such interaction, and we would rather not argue with them on that.
For filesystem related operations, I would suggest you use a separate module (and there are many on npm).

For those that would like to access file URLs with fetch, please see https://gist.github.com/joshua-gould/58e1b114a67127273eef239ec0af8989


Preserve inline dict inside an array

I have a TOML whose section contains an array of inline dicts:
[section]
list-key = [
    { path = "foo.jsonl", id_key = "id" },
    { path = "bar.jsonl", id_key = "id" },
    # ...
]

After running it through toml using something like:
t = toml.load(open('test.toml'))
toml.dump(t, sys.stdout, encoder=toml.TomlEncoder(preserve=True))

the file gets transformed into:
[section]
[[section.list-key]]
path = "foo.jsonl"
id_key = "id"

[[section.list-key]]
path = "bar.jsonl"
id_key = "id"

Given the above snippet the output doesn't look that bad, but in my actual example the inner dicts have 7 keys each, and there are many dicts in the list, so the updating the file causes an explosion of line count, making the output wordier and less readable than the original.
Curiously, the decoder seems to be doing the right thing, since the type of t['section']['list-key'][0] is reported as <class 'toml.decoder.TomlDecoder.get_empty_inline_table.<locals>.DynamicInlineTableDict'>. I'd therefore expect the encoder to preserve the inline dicts, but I can't get it to do so.
Is there any way to preserve inline dicts inside an array? Note that this is similar to #383, but the difference is that there the dict is inside a dict, and here it's inside an array, and the workarounds presented there don't make a difference for me.

Given the above snippet the output doesn't look that bad, but in my actual example the inner dicts have 7 keys each, and there are many dicts in the list, so the updating the file causes an explosion of line count, making the output wordier and less readable than the original.

This is also the exact problem I am having; would prefer also to have the ability to write inline tables from the encoder without having to read in / detect them in the first place. I think this makes sense for content that you want to compact in certain ways and not have tons of LOC.
Going to try the #383 solution and report back 🏄🏼

fwiw this encoder override method seems to mostly work, but may require an additional override of .dump_sections():
    def dump_list(self, v):
        '''
        Dump an inline list with a newline after every element and
        with consideration for denoted inline table types.

        '''
        retval = "[\n"
        for u in v:
            if isinstance(u, toml.decoder.InlineTableDict):
                out = self.dump_inline_table(u)
            else:
                out = str(self.dump_value(u))

            retval += " " + out + "," + "\n"
        retval += "]"
        return retval


Misc doc changes

Use common source url
Add changelog to html doc
Update license year
Badges and more badges!
Disable api reference for single module
Remove unused travis config
Embed readme to module doc and reduce content duplication
Bump ex_doc version
Update code examples
Add missing doc
Add changelog link to hex module info page
Add date to changelog release
Fix typo

This is awesome @kianmeng, sorry for not looking at it earlier. Do you have the time to solve the conflict?

@Betree Noted and done. Attach a screenshot so you can have a quick visual view of the changes.


what's the detail about diffuse light

this is the code in vertex.glsl
`precision mediump float;
attribute vec3 position;
attribute vec3 normal;
uniform mat4 model;
uniform mat4 view;
uniform mat4 projection;
uniform mat4 inverseModel;
uniform mat4 inverseView;
uniform mat4 inverseProjection;
uniform vec3 ambient;
uniform vec3 diffuse;
uniform vec3 lightDirection;
varying vec3 fragNormal;
void main() {
gl_Position = projectionviewmodel*vec4(position, 1);
fragNormal = normal;
}
this is the code in fragment.glslprecision mediump float;
uniform mat4 model;
uniform mat4 view;
uniform mat4 projection;
uniform mat4 inverseModel;
uniform mat4 inverseView;
uniform mat4 inverseProjection;
uniform vec3 ambient;
uniform vec3 diffuse;
uniform vec3 lightDirection;
varying vec3 fragNormal;
void main() {
float brightness = dot(fragNormal,lightDirection);
gl_FragColor = vec4(ambient + diffuse * max(brightness, 0.0),1);
//  gl_FragColor = vec4(1,1,1,1);
}`
and i can't pass the test
anyone can give me some tips?

Okay, so after mucking about with the diffuse problem for a full day, I've figured it out:
The problem is actually that the normals they give you are data normals. You need to convert those to view normals. The tutorial doesn't cover this well, but you need to perform a transform of the normals by the transpose of the inverse of the model transform and the transpose of the inverse of the view transform (in that order), then normalize that vector (in 3D).
I'll leave you to figure out how to actually do that.


Update korean language translation.

:( ?

@kurozael
i sent to you hl2rp schema strings, please check it.


Electron Transport Flavoprotein

Background:
There are currently three reactions that represent the role of ETF and ETFDH in transporting reducing equivalents from several mitochondrial flavoproteins in the mitochondrial matrix to the pool of ubiquinone in the inner mitochondrial membrane (source, source).

ID
reaction
GPR

MAR00562
Electron Transfer Flavoprotein Oxidized [m] + FADH2 [m] ⇒ Electron Transfer Flavoprotein Reduced [m] + FAD [m]
ETFA or ETFB

MAR00563
Electron Transfer Flavoprotein Reduced [m] + ubiquinone [m] ⇒ Electron Transfer Flavoprotein Oxidized [m] + ubiquinol [m]
ETFDH

MAR06911
FADH2 [m] + ubiquinone [m] ⇔ FAD [m] + ubiquinol [m]
ETFB or ETFA or SDHC or ETFDH

The enzymes encoded by these genes:

ACADVL
ACADL
ACADM
ACADS
ACADSB
ACAD9
ACAD10
ACAD11
GCDH
IBDH
IVD
SARDH
DMGDH
D2HGDH

oxidize their substrates while reducing an FAD cofactor, then bind to ETF and transfer those electrons from their FAD cofactor to the FAD cofactor of ETF, and ETF passes those electrons to ETFDH, which then reduces ubiquinone to ubiquinol (source). In case it's helpful, I found this diagram in this paper that illustrates the situation (specifically the bottom center; Q/QH2 is ubiquinone/ubiquinol):

Problems:
These enzymes (that pass their electrons to ETF) collectively catalyze over 100 reactions (mostly due to the ACADs), and nearly all of them involve FAD (i.e. MAM01802m and MAM01803m), while none involve Electron Transfer Flavoprotein (i.e. MAM03573m and MAM03574m) -- MAR00562 and MAR00563 are the only two reactions that the ETF "metabolites" participate in. I think that MAR00562 and MAR00563 are unnecessary, since having ETFA and ETFB (the two subunits of the ETF heterodimer) in the GPR of MAR06911 already does a decent job of capturing the role of ETF in conveying electrons from these enzymes' FAD cofactors to ubiquinone. Fully representing the real-life roles of the ETF "metabolites" would entail editing >100 reactions to replace MAM01802m and MAM01803m with MAM03573m and MAM03574m, which seems like a considerable amount of effort for a marginal improvement in the accuracy of the model.
The GPR of MAR06911 also includes SDHC in addition to ETFA/B and ETFDH, because the succinate dehydrogenase complex is capable of directly transfering electrons from its FAD cofactor to ubiquinone, which is also reflected in the diagram above. However, as the diagram clearly shows, it is far from the only human enzyme with an FAD cofactor that can reduce ubiquinol without the involvement of ETF, and I think all of them should be added to the GPR of MAR06911 for the same reason that SDHC is already there.
The only enzyme that appears on that diagram that isn't already in Human-GEM is SQOR, which, according to Uniprot, catalyzes reactions that are also not currently in Human-GEM (as far as I can tell), but I figure that discussing whether or not SQOR and any of its associated reactions should be added to Human-GEM can be a separate issue.
Proposed Changes:

[ ] Remove MAR00562 and MAR00563 for being redundant with MAR06911
[ ] Add PRODH, PRODH2, GPD2, DHODH and CHDH (i.e. ENSG00000100033 or ENSG00000250799 or ENSG00000115159 or ENSG00000102967 or ENSG00000016391) to the GPR of MAR06911

I agree completely - including a separate reaction for ETF redox is overkill, and can instead be captured by adding it to the GPR of the relevant reactions.
And I suppose it does make sense to add the relevant FADH-ubiquinone redox enzymes to the GPR of MAR06911.

fixed in #612


[ja] Translate docs/concepts/storage/volume-health-monitoring/ into Japanese

close #38062

/assign @nasa9084


Fix full name input field reset after form invalidation.

https://github.com/zulip/zulip/issues/10867
This code prevents the Full name input field from being incorrectly clear after the sign up form is rendered again after invalid data is submitted.
Fixes #10867

@prateekj117 it seems unlikely to me that removing at least the code in that top block involving data-full-name is correct.

@timabbott So I realize it might break some other part of the app in that case. I will try to find some other solution and make a new pull request.


Add a modal with the qr code of the current URL

You can use this nom package to generate a qr code https://www.npmjs.com/package/qrcode-generator


Concept to search for stores by geocoding

Use geocoding function from any geocoding service to translate user inputs to actual geo_json results like shapes or points.
Nominatimgeocoding service:

https://nominatim.org/release-docs/latest/api/Search/ ( uses open streept map data )
https://github.com/osm-search/Nominatim

Try nominatim out: https://nominatim.openstreetmap.org/search.php?q=&polygon_geojson=1&viewbox=
PRO:

open source
can be self hosted
free, no costs apart from hosting
postalcode search
city, discritct, street, based search

CON:

self hosting might be required

Google Maps Places API:
https://developers.google.com/maps/documentation/geocoding/start?hl=de
PRO:

no hosting required
easy to use
very good results
200 $ worth of request free per month ( corresponds to 40 000 geocoding requests )

CONS:

5 $ per 1000 requests when the free budget is exceeded.

The result from places api can then be matched with an internal search engine on our end, which provides geo queries. Like elasticsearch https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-queries.html.
Therefore all stores will have to be indexed in elasticsearch.
TODOs.

Setup Elasticsearch
Connect the Spring Boot App with Elasticsearch
Index stores from commercetools in the elasticsearch DB
Connect the Spring Boot App with any geocoding service
Define a new Search API in the Spring Boot App which uses Google Maps and the Elasticsearchengine

On Slack @PapaBravo posted this constructive Solution
I want to add that commercetools already allows for geo search (points only) on channels. So the feature "shops in my area" would be simple to implement
Channel has the attribute geoLocation: https://docs.commercetools.com/http-api-projects-channels#channeldraft
The Query Predicates Doc has an example https://docs.commercetools.com/http-api-query-predicates.html
API and other technical documentation of the commercetools platform - the leading PaaS solution for eCommerce.API and other technical documentation of the commercetools platform - the leading PaaS solution for eCommerce.
Channels HTTP API
Model the business with channels for supply and distribution(47 kB)
https://docs.commercetools.com/assets/img/opengraph-visual.png
API and other technical documentation of the commercetools platform - the leading PaaS solution for eCommerce.API and other technical documentation of the commercetools platform - the leading PaaS solution for eCommerce.
Query Predicates - commercetools platform
Learn about the commercetools platform - Query Predicates(47 kB)
https://docs.commercetools.com/assets/img/opengraph-visual.png

Today in the daily we agreed, that we want to implement a basic radius search with google maps and commercetools.
The user puts in any free text as in gooogle maps, street, city, postalcode etc.
The geocoding service geocodes the free text to a geo json point.
We will use this geo json point to do a radius search in commercetools channels api.

Please check:
https://simplemaps.com/data/de-cities
We can use this data for free an dont need to ask google for that.


parallel should be more verbose?

Parallel offers the "-v" option, which prints the job run before each output. This helps in various debugging when a command in a job list fails:
       -v       Verbose.  Print the job to be run on stdout (standard output).

Should this depend on a verbose flag? Or be the deafult.

Good idea. +1 for this set as default.


Integrate Welcome Bot

I can add a welcome bot config file having a proper message that will show up when any user will open up an issue or pull-request for the first time.
For reference, check out: https://github.com/apps/welcome
Please assign it to me as a part of Cross Woc.

@muthuannamalai12 go ahead.

@JINDAL-JJ  For the custom message shown by the welcome bot we need a code of conduct. So for that reason I have opened a issue for code of conduct file. Kindly assign me that #11  issue.


Enhanced Docker Support using docker-compose

There are two environments, one for local development and one for production use.
dev.yml contains the configuration for local development, consisting of two services:

A service called django that basically just runs the runserver command.
postgres

In development, the code folder is mounted into the container so that runservers auto code reloading works. As of now, I had no time to take a look at the code reloading using node.
docker-compose.yml is for production use, consisting of 4 or 7 services if celery is installed:

Nginx as a reverse proxy
Gunicorn as an upstream server for nginx running the django app
postgres
Redis
RabbitMQ as celery broker (optional)
Celery Worker (optional)
Celery Beat (optional)

Environment variables for production are defined using an environment file called env.production.
I'm currently working on a fork that goes beyond the scope of this PR here: https://github.com/jayfk/cookiecutter-django-docker
The idea is to experiment with all docker and docker-compose features in a seperate project and to contribute to upstream as soon as the changes are mature enough. In case someone is interested, join me there.

Thanks for all this hard work. Would it be possible to sketch out some basic documentation of usage of Docker like what we have for Heroku and Dokku? It would go in the deployment section: https://github.com/pydanny/cookiecutter-django/blob/master/{{cookiecutter.repo_name}}/README.rst#deployment

Amazing work, I was working on something similar.  I'll help with the documentation.

:+1: :+1: :+1:
For reference, there's a super basic walkthrough at https://realpython.com/blog/python/django-development-with-docker-compose-and-machine/

This looks really good! It's great to have a working Docker configuration, for both development and production.
I like this PR overall, but I have a couple of comments:

Is entrypoint.sh really necessary? If it's only used to set environment variables, I would argue it's better to keep them in the compose .yml files. It's more explicit, there's fewer places to check if something goes wrong. Same for gunicorn.sh.
You could add USER django to the Dockerfile and avoid having to write su -m django -c "<cmd>" for every command. I think it's less error-prone this way.
The development configuration should support Celery too.

Is entrypoint.sh really necessary? If it's only used to set environment variables, I would argue it's better to keep them in the compose .yml files. It's more explicit, there's fewer places to check if something goes wrong. Same for gunicorn.sh.

The purpose of entrypoint.sh is to make sure that the environment variables cookiecutter is using don't have to be set multiple times in different formats.
If you use the postgres container with a different user/password combination, you'd have to set the environment variables like this:
For the database:
POSTGRES_PASSWORD=mysecretpass
POSTGRES_USER=postgresuser

For Django:
DATABASE_URL=postgres://postgresuser:mysecretpass@postgres:5432/postgresuser

I really didn't wan't to change too much about the current implementation so I created entrypoint.sh as a compat layer.
A pure docker solution would look like this:
DATABASES = {
'default': {
    'ENGINE': 'django.db.backends.postgresql_psycopg2',
    'NAME': env("POSTGRES_ENV_POSTGRES_USER", default="postgres"),
    'USER': env("POSTGRES_ENV_POSTGRES_USER", default="postgres"),
    'PASSWORD': env("POSTGRES_ENV_POSTGRES_PASSWORD", default=""),
    'HOST': 'postgres',
    'PORT': 5432,
 }

}
This could be added to the docs for people that prefer a cleaner solution.

You could add USER django to the Dockerfile and avoid having to write su -m django -c "" for every command. I think it's less error-prone this way.

That's a good point.  This can be put in the Dockerfile or the .yml file. The .yml might be the better place, because more people are looking at it. This allows everyone to see the the user at a quick glance. What do you think?

The development configuration should support Celery too.

I always like to keep the dev environment relatively simple, but that's a matter of taste.

If this works, and no one objects, I would like to merge it in. It doesn't have to be perfect, it just has to work. We can always refactor and improve on our Docker support as it is used.

I would like to put my $0.02 and ask that this be merged; I am waiting to give this is a try as we exclusively deploy on docker in production.

@jayfk Thanks for this. I'm going to give it a try on my machine and comment accordingly (Maybe this weekend or meantime). I don't want to hold up, but I would like to try it out once before merging it in.
There are couple of things, before that:

env.production – can we have sensible defaults hard-coded and then use .env (not tracked) to override or provide the values as needed. We would not like to track anything that stores credentials.
Is there any specific reason to rabitmq when we already have one redis instance.
There are some existing documentation for docker https://github.com/pydanny/cookiecutter-django/blob/master/{{cookiecutter.repo_name}}/docs/docker_ec2.rst , it needs to be cleaned up/modified.
I think it would be very helpful, if we can improvise the documentation with relevant hyperlinks where applicable. We can/should also use wiki for documentation that might look noise in the codebase and provide a hyperlink to it.
When we say you can use docker setup in production, can we have documentation where someone would like to have redis/postgres running on a independent machines. Imagine a scenario of scaling up the stack against a load balancer, else we should just say use this docker setup in development and it's not for production explicitly. I would not prefer someone get stuck while trying to scale horizontally in production, because they used docker as suggested here.
Please rebase your branch on top of master branch of this repo, currently it has merge conflicts.

PS:

That said, adding things to a single repository makes things monolithic & little hard to maintain, a separate discussion thread for it has already been initiated (https://github.com/pydanny/cookiecutter-django/issues/260), please help out with your feedback.
In the case of docker, looking at it's acceptance and demand, I think we should not have a major issue maintaining it in this project, but before merging I would be interested to know reasonable answer to point 5.
Like @pydanny code doesn't have to be perfect, but I would not like to compromise on documentation part. Please provide reasoning for anything done where needed as comments like in the case of entrypoint.sh.

Cheers,

What about a .env.example with sensible defaults (tracked) and docker-compose.yml linking to .env (not tracked). We could then add documentation that the file should be renamed and that it is wise to not track the file in version control.

No, other than that you have to set some additional configurations using redis: http://celery.readthedocs.org/en/latest/getting-started/brokers/redis.html

3+4. I totally agree with you. I'm currently working on more documentation

Scaling to more than one host with docker-compose is currently being worked on at docker. They have to get the host to host network part in place, before they can introduce the functionality to docker-compose.
Once this is merged in, it should work out of the box for the current setup. You'd spin up a swarm cluster and run the whole stack on multiple hosts. You may have to add a flag to your postgres service that no other service should run on the same host, but that's about it.
To your main concern: They'd not get stuck, it's just currently not supported out of the box. They'd have to use external tools for host to host networking like weave. There's a guide here: http://weave.works/guides/weave-and-docker-platform/chapter4/compose-scalable-swarm-cluster-with-weave.html
We could (and probably should) add this to the documentation.

Related issues:
https://github.com/docker/compose/issues/1803
https://github.com/docker/compose/pull/1676

@jayfk thanks for updates. There are a lot of new information coming, which are important too. Let's get things documented and we should be good. ;-)

yes. Please.
Let's go with additional configuration and use redis only for celery. If there are no other technical requirements/issues to rabitmq. This will make one less application to maintain across all the deployment setups.. e.g. Heroku, Ubuntu. (We have been using redis as broker in production, and didn't face any issue as such)

We should focus on focusing the local development version of Docker for cookiecutter-django. Once we get that looking really good, we can focus on production deployments. The advantage there is:

Narrows the scope of this pull request.
Allows us to see how it works for many users and adjust accordingly before providing an 'official' docker-deployment solution.

Also, I want to say @jayfk, this is great work and great dialogue.

@pydanny +1

@pydanny +1 . I think that until we have, over time, adjusted everything to work well in production, it would be good to leave extremely explicit that this docker setting was not meant to be used in a production environment. Done that, I have no objection to include configuration for docker.
some random thoughts :smiley: : :
I still have my doubts about security, specifically on what is included via dependencies of Docker containers. eg.: https://github.com/pydanny/cookiecutter-django/pull/238#issuecomment-103665409
How can I be sure that any of the dependencies does not include any security breach caused by lack of knowledge about techniques of safety or security hole purposely included?.
I still have very little experience with docker, perhaps that question already has been answered somewhere

@luzfcb My thought has been to have docker for cookiecutter-django only for local development. For local development it shines, and security isn't that much of an issue.
As for production-readiness, I'm not keen on endorsing that until we've had Docker for local development for some time. In other words, it's a way to lower the barrier of entry for people on systems where installing our requirements is hard (like Windows users).

I still have my doubts about security, specifically on what is included via dependencies of Docker containers. eg.: #238 (comment)

I'm always looking from the perspective of what we currently use to install software on our servers. While some people install from scratch and compile everything on their own, it's relatively safe to say that most people use package managers like apt or yum.
When using a package manager you trust the people maintaining the package to make the right decisions regarding dependencies, security and sane default settings. That's the same thing for docker images. You'll have to trust the people that have put the image together.
The cool thing for docker image is, you can go down the whole chain to see what they have done. If you look at the dockerfiles, you can see a chain of images they build up on and what they are doing on their part (mostly apt installing software and providing a default config that runs in the foreground).
By following the chain and looking at the individual docker and config files, and, more important what it runs at the end, I found it easier to to understand what the image does exactly.
In the end, it's just a new technology (or an old technology reinvented and tweaked) you have to get your head around at first to understand all the implications on the different layers involved.
Imagine someone in the 90's popping op in the linux mailing list, saying that he invented a great technology to install software. All one had to do is to run apt-get install whatnot and they are ready to run. I think the reactions would have been like today with docker. It's not secure, what if someone screws up with a config along the way etc.?
I think once a technology evolves and more and more people put their eyes on it most of these questions go away because people build trust in it.
This is not to defender docker, there are absolutely horrible examples for insecure docker images. If you look at the official django image that runs runserver by default, you get the idea.
That's why I think the ongoing discussion on this issue is a vital thing, because the end result is more quality.

Catched up with upstream.
Commit c7ea475 addresses all the points discussed here. It'd nice if a native speaker could take a quick look at the documentation.

LGTM.
I'm merging this in. As we use it we can fine tune things as needed. Excellent work @jayfk and many thanks to @martinblech for making the initial pass!

Awesome work! :+1:
Kudos to @jayfk @martinblech and everyone else for making this happen. :blush:


Cards

Hello everybody! Is possible to use more than 1 hidden content on semantic Ui cards?
I need to reveal 3 images on one card.

Hidden content is part of reveal, so check the docs for that component. hidden content can include any content inside which will be revealed. Just make sure it matches the size of visible content


Type check data config files

Figure out a way to have VSCode apply the expected Typescript types to the various user-supplied configuration files in data/ and warn for incorrect configuration.
Related to #71

https://marketplace.visualstudio.com/items?itemName=KurtGokhan.tsschema

https://github.com/vega/ts-json-schema-generator

npx ts-json-schema-generator --path 'src/**/*.ts' --type 'PackedRawSimulationConfig' --tsconfig tsconfig.json

[ ] Fix up types so the raw json files are as expected (currently they assume a post-extended thing)

The thing that broke at 04233a7eb9a2c853852d87bfd1b1071e2245b493 is https://github.com/vega/ts-json-schema-generator/issues/166

Done as of 6427b945fe21ee9e788b0dd5fad792e99c070d6c


MP GO:0000935     division septum

should
GO:0000935    division septum
def
A cell septum which functions in the compartmentalization of a cell into two daughter cells at division. A division septum spans a cell and does not allow exchange of organelles or cytoplasm between compartments.
have the parent
GO:0032153   cell division site
Definition (GO:0032153 )
The eventual plane of cell division (also known as cell cleavage or cytokinesis) in a dividing cell
since
GO:0005826    actomyosin contractile ring
etc are parts, and it is in the division plane?

I don't think so. I think the cell division site is the place where the cells will divide, and the septum is the physical barrier that forms in some organisms. The contractile rings sets up at the site of division and is one of the things that delineates the site. Since the contractile ring exists in organisms that don't have a septum, it can't be a part of the septum.

I don't think the contractile ring should be part of the septum, but  that the septum is part of the "division site"
(division site is a broad term encompassing everything in the division plane, it seems).
I took
"The eventual plane of cell division..."
To mean "any structure which is part of the eventual plane of cell division"
The septum is assembled in the plane of cell division, so I assumed it to be part of the cell division site.
I thought it was a grouping terms for all of the structures of interest to the cytokinesis community. Historically we have used "cell division site" when we did not have enough info to pin down to one of these sub structures. Possible septum components would be annotated here.

I guess it depends, if the "cell division site" ONLY exists prior to division, or also during and after division.  The current def is ambiguous in this regard.
I think it is used for all 3. You can have a "cell division site" in a divided cell.

In the bigger modeling picture, I think that we would want to represent the division site as the place where something happens. Would you want the gene products that are part of the mature septum to be grouped with those that are acting at the divisions site? I don't know enough about septa to judge, but that would seem strange to me.

I requested the term originally as a grouping term, because when we got our early localization dataset we could not distinguish between septa, cytokenetic ring etc, so we wanted a broader term to encompass all stuctures at the division plane.
Maybe it is no longer interpreted this way?  I'm happy if it is refined but we would need to fix things.... obsoletion might be best though...

I'm not sure how it is currently interpreted. Certainly your broader interpretation wouldn't make any annotations incorrect. If you really want, I can make the septum part of the division site.

I would prefer broader but maybe a better name like
"cell division site apparatus"  would work better
to encompass any of the cell division machinery and features which  occur in the division plane?

I think that name is more confusing. I think I'd rather stick with the current name and make division septum part of the cell division site. It seems to fit with all of the other structures that are listed.

I'm worried that I'm using it differently to everyone else! Would like input from @mah11  @Antonialock

I have used "cell division site" as a catch all term for anything that localizes to the division plane at any point, but the paper isn't fine-grained enough to say to what exact structure, or at what particular point, the gene product acts. I agree that the def "The eventual plane of cell division" is not appropriate for this usage (since we use it for anything that is at the eventual site of cell division + at the site of cell division).
I agree it is useful to have a "catch all term" for things going to this site, but we cannot annotate to BP "cytokinesis", or other more fine grained cytokinesis structures because the paper doesn't provide enough information.
I don't think that "cell division site" is a very useful term as it is currently defined (sounds a bit wishy washy? - if you know this then you can probably annotate to a more specific term anyway?)....personally I think it could be redefined to also include during and after division.

yes that was certainly the intent when the term was created.....

Then let's go ahead and relax the definition.

unfortunately I'll  be working this week... if anyone wants to do tickets with me...glad I decided to fetch my laptop...
I'll be

I should have been paying more attention to this item. Sorry! cc'ing @dsiegele.


Switch from colored to owo_colors/anstream

Refs #5499
Summary
This switches us from the colored crate to the owo-colors and anstream crates for handling terminal colors. The eventual goal here is to support the FORCE_COLOR env var, but this PR doesn't actually do that yet; that'll come in a separate PR.
The approach here is to separate concerns: we always write colored text (using owo-colors) and we wrap our output streams in anstream::AutoStream, which can detect if the terminal supports colors, and strip out the ANSI color codes if not.
Some points for reviewer attention:

I stripped out the fix for ANSI color codes in Windows 10 that was added in #3583, because it's not clear if this will still be needed on Windows, or was just working around a bug in the colored crate. It's also not clear what the equivalent of this workaround for anstream would be. We need someone to test this on Windows 10, which I don't have available; if nobody else does either, I can get a VM.
Some test snapshot outputs changed where they include invalid / non-printable characters, because anstream is doing something odd with them when it detects a non-terminal. This won't change things for most users who are running from a terminal. Need to look into this more to understand what's happening; I'd initially thought anstream was stripping out the invalid characters, but in the github diff view it doesn't look like that's quite what's happening. Not sure what we can do differently here, short of scrapping the whole approach of using anstream.
There's one place I had to replace let tip = "...".bold().green(); with let tip = "...".bold(); let tip = tip.green();. This is because with owo-colors the former causes a compiler error: "...".bold() creates a temporary that is freed before tip is used. Naming the temporary allows it to live long enough. This was only a problem one place, since most places we use chained styling methods, the result is used immediately, so there isn't a lifetime problem. Naming the temporary was the compiler-suggested fix; if there's a nicer way let me know!
The new ruff_linter::colors; module isn't strictly needed in this PR (at the moment it's purely passing through to anstream), but I think it's more robust if we consolidate our color-choosing logic; this will be needed in the next PR that adds support for FORCE_COLOR (see below).

TODO:

[ ] test on Windows 10
[ ] investigate changed test snapshots with invalid characters

Why doesn't this PR already support FORCE_COLOR?
Anstream doesn't have any built-in support for FORCE_COLOR. owo-colors has optional support for it, via the supports-color feature, but this requires using a less convenient (and likely less efficient) if-supports-color API. And doing color support selection in owo-colors is irrelevant if we are using anstream, because if anstream doesn't recognize FORCE_COLOR itself, it'll just happily strip out the color codes anyway. So my plan for FORCE_COLOR is to add a check for it in ruff_linter::colors::choice function, forcing it to return "yes colors" regardless of terminal. But I think it's clearer to add that behavior change in a separate PR.
Test Plan
Existing test suite passes.
I also verified that cargo run -- check ... does have colored output in my terminal by default,  does not have colored output if I set NO_COLOR=1, does not have colored output if I set CLICOLOR=0, does not have colored output if I pipe to less, and does have colored output if I set CLICOLOR_FORCE=1 and pipe to less.

This looks good to me! I'll hold off on approving while we figure out what's up with those snapshots.

It does look like this is a regression; I presume that's because of the extra stream filtering done by anstream:
ruff on main [$] via 𝗥 v1.77.1
➜ hyperfine --warmup 10 "./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e"
Benchmark 1: ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e
  Time (mean ± σ):     129.7 ms ±   1.6 ms    [User: 1119.6 ms, System: 75.5 ms]
  Range (min … max):   127.1 ms … 132.6 ms    22 runs

ruff on cjm/colors [⇡$] via 𝗥 v1.77.1
➜ hyperfine --warmup 10 "./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e"
Benchmark 1: ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e
  Time (mean ± σ):     144.7 ms ±   1.5 ms    [User: 1131.5 ms, System: 84.2 ms]
  Range (min … max):   141.8 ms … 147.0 ms    20 runs

That's pretty significant; it's like 11%.
Do we still want to go ahead with this change? I think we have two alternatives:

Switch to owo-colors but don't use anstream, just use owo-colors and if-supports-color. It sounds like that might also be a regression, but maybe a smaller one?
Stick with colored and just add support for FORCE_COLOR by checking the env var and setting a global override using colored::control. I presume this would be zero regression.

@charliermarsh @MichaReiser

Oh wow. I'm surprised it's that significant -- thanks for benchmarking! (Maybe @MichaReiser will be less surprised?) I agree that 11% is way too much for something that's largely internal convenience with no user-facing benefit. Sorry for sending you on this path... That's my fault.
For context, the motivation for moving to owo-colors is that we use it in uv and we generally like the API a bit more than colored. I also thought it supported FORCE_COLOR out-of-the-box, so it seemed like a good excuse to migrate, but I since realized that I misread the comments on the other issue.
My vote would be to just implement FORCE_COLOR manually and close this for now. If you remove anstream, you'll then need to spend more time on this migration for questionable benefit, and we still won't be aligned with uv, which reduces the overall value.

I'm not surprised. I don't remember the exact numbers but I know it was significant enough that I didn't dare to put up a PR ;) (although my solution wasn't as good as @carljm's).
I prefer to create a build of both versions and run hyperfine as a single command to reduce the chance that any other programs (or caches) influence the benchmark. I do this by building main and copy it to ./target/release/ruff-main (It allows me to iterate on the branch version). But I do get the same numbers and the regression is worse when running in cached mode (not surprising)
hyperfine \
          --warmup 10 \
          --runs 100 \
          "./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ --no-cache -e" \
          "./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e"
Benchmark 1: ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ --no-cache -e
  Time (mean ± σ):     304.9 ms ±  15.6 ms    [User: 1608.4 ms, System: 76.1 ms]
  Range (min … max):   293.7 ms … 389.4 ms    100 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e
  Time (mean ± σ):     324.9 ms ±   7.0 ms    [User: 1616.1 ms, System: 84.4 ms]
  Range (min … max):   315.6 ms … 360.9 ms    100 runs

Summary
  ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ --no-cache -e ran
    1.07 ± 0.06 times faster than ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e

hyperfine \
          --warmup 10 \
          --runs 100 \
          "./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ -e" \
          "./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ -e"
Benchmark 1: ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ -e
  Time (mean ± σ):      76.9 ms ±   0.9 ms    [User: 63.9 ms, System: 50.0 ms]
  Range (min … max):    75.3 ms …  79.3 ms    100 runs

Benchmark 2: ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ -e
  Time (mean ± σ):      96.6 ms ±   1.0 ms    [User: 74.6 ms, System: 58.9 ms]
  Range (min … max):    94.9 ms … 102.3 ms    100 runs

Summary
  ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ -e ran
    1.26 ± 0.02 times faster than ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ -e

It seems that the AutoStream::auto method is somewhat involved. I list a few ideas without having looked at the code (I'm on the train and have very bad connectivity :( ). Can you change the code to always create a non colored stream to test if that changes the runtime in anyway. If it does, then we know that determining whether the terminal is colored or not is expensive and we should look into caching (owo-colors has a caching mechanism) or ensure that we move the stream creation out of any loop (if that's the case today). If the performance remains unchanged. Try always to create a colored stream. Does this change performance? If neither of the two helps. Are we locking the output stream the same as we did before (see https://docs.rs/anstream/latest/anstream/struct.AutoStream.html#method.lock)? I recommend limiting the investigation to 1-2h.
CPython is an edge case because it is a project with many diagnostics and Ruff prints all the diagnostics (it creates a 2MB diagnostic file using concise formatting). I strongly suspect that the slowest part of running ruff is my terminal rendering this wall of text. Do we see any regression when linting a project that has adopted Ruff (e.g. airflow?). I'm undecided how much the perf regression should bother me. I suspect that this use case will get slower when we switch to output-format=full and again when we start showing diffs for fixes and escape non-printable characters in code frames and diffs (which we currently print and who knows what that does to the user's terminal). Now, that's a bad excuse for an internal refactor making Ruff slower, even if it is an edge case. So maybe yes, keeping colored is still the best solution today.
Long term, I would love to see us having our own ruff_markup and ruff_console crates similar to biome (biom_markup and biome_console) that abstracts the whole console output with a markdown. But that's slightly out of scope ;)
@carljm would you mind creating an issue that the code frame and diff rendering should escape non-visible characters?

Reading Micha's comment: I think it makes sense to do some basic testing to understand whether (1) the terminal detection is a contributor to the slowness (hardcode to always use a non-colored stream), and then (2) whether the stream-stripping is a contributor to the slowness (hardcode to always use a colored stream, which presumedly is zero-cost). But yeah, let's timebox it to an hour or so, since it seems unlikely to ship right now.

Yeah, confirmed that the regression doesn't improve at all if we force no-color (always filter the streams):
ruff on  cjm/colors [⇡$!] via 𝗥 v1.77.1 took 9s
➜ git di
diff --git a/crates/ruff_linter/src/colors.rs b/crates/ruff_linter/src/colors.rs
index 946216464..89e6c7073 100644
--- a/crates/ruff_linter/src/colors.rs
+++ b/crates/ruff_linter/src/colors.rs
@@ -6,6 +6,7 @@ pub fn none<S: RawStream>(stream: S) -> AutoStream<S> {
 }

 pub fn auto<S: RawStream>(stream: S) -> AutoStream<S> {
+    return none(stream);
     let choice = choice(&stream);
     AutoStream::new(stream, choice)
 }

ruff on  cjm/colors [⇡$!] via 𝗥 v1.77.1 took 41s
➜ hyperfine --warmup 10 "./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ -e" "./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ -e"
Benchmark 1: ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ -e
  Time (mean ± σ):      66.0 ms ±   0.7 ms    [User: 53.0 ms, System: 61.1 ms]
  Range (min … max):    64.6 ms …  68.1 ms    44 runs

Benchmark 2: ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ -e
  Time (mean ± σ):      80.6 ms ±   0.6 ms    [User: 61.3 ms, System: 69.0 ms]
  Range (min … max):    79.4 ms …  82.6 ms    36 runs

Summary
  ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ -e ran
    1.22 ± 0.02 times faster than ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ -e

ruff on  cjm/colors [⇡$!] via 𝗥 v1.77.1 took 8s
➜ hyperfine --warmup 10 "./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ --no-cache -e" "./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e"
Benchmark 1: ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ --no-cache -e
  Time (mean ± σ):     131.5 ms ±   4.4 ms    [User: 1116.9 ms, System: 75.5 ms]
  Range (min … max):   127.4 ms … 146.3 ms    20 runs

Benchmark 2: ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e
  Time (mean ± σ):     145.7 ms ±   3.4 ms    [User: 1127.2 ms, System: 84.2 ms]
  Range (min … max):   141.3 ms … 155.1 ms    20 runs

Summary
  ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ --no-cache -e ran
    1.11 ± 0.05 times faster than ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e

And it (mostly) disappears if we run with color always on (no stream filtering):

ruff on  cjm/colors [⇡$!] via 𝗥 v1.77.1 took 9s
➜ git di
diff --git a/crates/ruff_linter/src/colors.rs b/crates/ruff_linter/src/colors.rs
index 946216464..cca490ed2 100644
--- a/crates/ruff_linter/src/colors.rs
+++ b/crates/ruff_linter/src/colors.rs
@@ -7,7 +7,7 @@ pub fn none<S: RawStream>(stream: S) -> AutoStream<S> {

 pub fn auto<S: RawStream>(stream: S) -> AutoStream<S> {
     let choice = choice(&stream);
-    AutoStream::new(stream, choice)
+    AutoStream::new(stream, ColorChoice::Always) //choice)
 }

 pub fn choice<S: RawStream>(stream: &S) -> ColorChoice {

ruff on  cjm/colors [⇡$!] via 𝗥 v1.77.1 took 42s
➜ hyperfine --warmup 10 "./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ -e" "./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ -e"
Benchmark 1: ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ -e
  Time (mean ± σ):      63.9 ms ±   0.5 ms    [User: 51.1 ms, System: 60.9 ms]
  Range (min … max):    62.8 ms …  65.2 ms    45 runs

Benchmark 2: ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ -e
  Time (mean ± σ):      64.8 ms ±   0.6 ms    [User: 51.9 ms, System: 60.9 ms]
  Range (min … max):    63.8 ms …  66.1 ms    45 runs

Summary
  ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ -e ran
    1.01 ± 0.01 times faster than ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ -e

ruff on  cjm/colors [⇡$!] via 𝗥 v1.77.1 took 8s
➜ hyperfine --warmup 10 "./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ --no-cache -e" "./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e"
Benchmark 1: ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ --no-cache -e
  Time (mean ± σ):     131.2 ms ±   4.9 ms    [User: 1123.2 ms, System: 74.8 ms]
  Range (min … max):   127.1 ms … 145.6 ms    23 runs

Benchmark 2: ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e
  Time (mean ± σ):     133.4 ms ±   5.1 ms    [User: 1121.9 ms, System: 76.6 ms]
  Range (min … max):   129.0 ms … 147.1 ms    22 runs

Summary
  ./target/release/ruff-main ./crates/ruff_linter/resources/test/cpython/ --no-cache -e ran
    1.02 ± 0.05 times faster than ./target/release/ruff ./crates/ruff_linter/resources/test/cpython/ --no-cache -e

I think this confirms that the anstream approach to this problem, while conceptually nice, is just inherently pretty slow.
If we really do like the owo-colors API better than colored, I'm still open to adjusting this PR to remove anstream and just use owo-colors with if-supports-color, while I have all this context paged in. But based on Micha's previous experience, I might do that work and find it's still too much regression (though I'm curious where the regression actually comes from in that case.)
For now I'll close this and put up a separate PR to just add FORCE_COLOR support with no library changes.
I'll also open a separate issue about escaping non-printable chars in code frames / diffs.

Just in case anyone comes back to this PR in future, I wanted to also record some of my discoveries about the invalid-characters behavior here.
It is sort of true that this PR improves consistency between what users see and what insta sees, but only if the user is running in a no-color environment, so that anstream strips their output (like it does in tests). If the user is running in a color environment (probably the more common scenario), then this PR actually increases the divergence between what the user sees and what we see in insta, because the color-using user will see the somewhat-unpredictable results of directly outputting the control char, where insta will stop seeing the control char at all (because anstream strips it.)
Additionally, anstream's stripping is kind of unpredictable in the face of \x1b / ^[ / ESC, which makes sense, since that is the prefix for ANSI color codes as well. Depending on the exact next characters in the string after the ESC char, anstream might end up stripping one or two additional characters after the ESC char; this is the cause of the cases in this PR where we have an entire '} go missing.
So I don't think the current behavior of this PR is something we'd want to merge, and I'm honestly not sure what we should do regarding non-printable chars (escaping them seems reasonable, but oddly neither diff nor git diff do that, and I think we should understand why before we diverge from their behavior), but I filed #10841 for further consideration.

Minor curiosity... why didn't Codspeed show this performance regression?

I don't know the answer, but IIRC CodSpeed can't / doesn't measure the cost of allocations, so if this the regression came from increased allocations, that wouldn't have shown up.

Spot-checking some of the benchmarks that Codspeed runs, it looks like they are library benchmarks, not full sub-process benchmarks (i.e. they benchmark calling some library function with some data), so I think they are completely blind to the performance of console I/O.

Oh yeah, that's interesting.

IIRC CodSpeed can't / doesn't measure the cost of allocations, so if this the regression came from increased allocations, that wouldn't have shown up.

That could be (I guess CodSpeed just measures CPU instructions?). But I would suspect that at least some of the cost here has to be actually scanning the strings for the ANSI escape codes (that can't be free!), and I would think CPU instrumentation would catch that.

Some quick thoughts for anyone that comes back to this

It looks like the performance is purely with stripping and not overhead from choosing the stream type (since it stayed about the same with force-none and went away with force-always)

How much of a concern is performance for "piping to a file" (none) vs "showing to the user (usually always)
If people want to give a reproduction case they want me to look into, I can see if there are more gains, particularly geared to your workflow.  When I first created anstream, I knew performance for stripping was going to be a concern and specially optimized it compared to the more popular stripping implementations but I was limited in my test cases and was focused on microbenchmarks (since this was before anstream::AutoStream existed)

I recommend centralizing color definitions, e.g. https://github.com/rust-lang/cargo/blob/master/src/cargo/util/style.rs
With the above and with anstyle API improvements (e.g. rust-lang/cargo#13368), I've been finding anstyle is sufficient for my needs for styling and there isn't a reason to pull in a separate library (anstyle is a dependency of anstream)
If there are concerns for escape codes, feel free to start a discussion on anstyle repo
I recommend trying out anstyle-svg for snapshotting of ANSI escape codes.  snapbox, CLI focused snapshotting alternative to insta that is being pulled out of cargo, has native support for this.

Hi @epage
It's an honor to see you chime in on this discussion.
Regarding using anstyle directly. I assume what you recommend here is to do something similar to the annotated-snipped crate (together with a Stylesheet that the Renderer uses):
https://github.com/rust-lang/annotate-snippets-rs/blob/master/src/renderer/display_list.rs#L201-L222

imo for something like Ruff, you likely don't need the generalization that was done in annotate-snippets but could hard code things like Cargo did

https://github.com/rust-lang/cargo/blob/master/src/cargo/util/style.rs
https://github.com/rust-lang/cargo/pull/13368/files

While the original purpose of anstyle was to existing public APIs (like annotate-snippets or clap) and not as much to be used for styling. I think its been tweaked well enough to also work for styling and it was with that lens that I made the suggestion.


[feature]: Slim images from the GitHub Container Registry

I'm trying to slim my Docker image like so:
---
# https://docs.docker.com/ci-cd/github-actions/
name: Publish Docker Image

on:
  push:
    branches:
      - master
    paths:
      - "Dockerfile"
  workflow_dispatch:

permissions: read-all

jobs:
  build:
    runs-on: ubuntu-22.04
    permissions:
      packages: write
    steps:
      - name: Checkout repo
        uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633
      - name: Set up QEMU
        uses: docker/setup-qemu-action@b7249025a94417def5eea224a7408d279c7becfb
      - name: Set up Docker Buildx
        id: buildx
        uses: docker/setup-buildx-action@d70bba72b1f3fd22344832f00baa16ece964efeb
      - name: Login to GitHub Container Registry
        uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ github.token }}
      - name: Build the image
        uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0
        with:
          context: .
          builder: ${{ steps.buildx.outputs.name }}
          push: false
          tags: ghcr.io/t145/black-mirror:latest
          cache-from: type=registry,ref=ghcr.io/t145/black-mirror:buildcache
          cache-to: type=registry,ref=ghcr.io/t145/black-mirror:buildcache,mode=max
      # https://github.com/kitabisa/docker-slim-action
      - name: Slim the image
        uses: kitabisa/docker-slim-action@e641d62304259303c8557c27e10965f7348c7eb4
        env:
          DSLIM_HTTP_PROBE: false
        with:
          target: ${{ github.repository }}:latest
          tag: 'slim'
      - name: Push all tags
        run: docker image push "${{ github.repository }}" --all-tags

But I get an error message like this:
slim on target: T145/black-mirror:latest
/tmp/slim-1.40.11-linux/slim b --target T145/black-mirror:latest --continue-after 1
cmd=build state=started
cmd=build info=params continue.mode='timeout' rt.as.user='true' keep.perms='true' tags='' image-build-engine='internal' target.type='image' target.image='T145/black-mirror:latest'
time="2024-04-20T07:12:52Z" level=error msg="image.inspector.NoImage: err=API error (400): invalid reference format: repository name must be lowercase"
time="2024-04-20T07:12:52Z" level=fatal msg="slim: failure" error="API error (400): invalid reference format: repository name must be lowercase"

If I designate ghcr.io/t145/black-mirror:latest it still can't pull the image due to not recognizing the Docker credentials. Is this a problem that can be fixed on my end?

But I get an error message like this:

The target image is invalid, it should be ghcr.io/${{ github.repository }}:latest.

[...] it still can't pull the image due to not recognizing the Docker credentials.

What's the error?

What worked for me here is adding the load: true. This adds it to the local docker instance so that it can be used by slim.
- name: Build the image
        uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0
        with:
          context: .
          builder: ${{ steps.buildx.outputs.name }}
          push: false
          load: true
          tags: ghcr.io/t145/black-mirror:latest
          cache-from: type=registry,ref=ghcr.io/t145/black-mirror:buildcache
          cache-to: type=registry,ref=ghcr.io/t145/black-mirror:buildcache,mode=max


Fix cleaning of resources for permanently failed tasks.

If a task is permanently failed, it's resources should not be considered "expected," so they can be cleaned up.

retest this please

retest this please

Looks good. I suppose we'll need to remember to revisit this logic if we ever add support for shared volumes.


Upgrade examples/*/README.md

[ ] Add gifs
[ ] Explain helpers (namespaces, classes, functions) more

[ ]  Explain helpers (namespaces, classes, functions) more

example_::ask_delay function in examples/events/src/hard.cxx for example.


How is the current time defined for execution of a clause.

Most of the Cicero template use the timestamp for the transaction. Is that the right way to access the current time? Would the time at which the logic is called be preferable?

In general, I think it is better to use the time in the incoming transaction. It makes unit testing much easier as you don't have to use mock clocks etc.

As of Cicero 0.12, API calls for parsing and execution lets the user pass a "currentTime" parameter in the following format: 'YYYY-MM-DDTHH:mm:ssZ'. This parameter is also used to determine the local timezone for execution.


Bump  and  to memo + forwardRef

Overview
The title of this PR -- keeping chugging along converting stuff to forwardRef + memo + hooks.
Screenshots (if applicable)
N/A no visual change, just a component change.
Testing

[x] Updated Typescript types and/or component PropTypes
[x] Added / modified component docs
[x] Added / modified Storybook stories

Think this was actually superseded by the codemod in #825 so I'll just keep it as is! Too fast.


Transaction Details hardcoded to bellatrix

Description
Right now we request the transaction details using the bellatrix.Transaction. However, this structure might change in the future, so the details should be requested using a standard structure as a Hash.
https://github.com/cortze/goteth/pull/63#pullrequestreview-1539550611
Proposal
In order to make the transaction request compatible with the rest of the tool, we intend to request the details inside the block, at the same time it is converted to an AgnosticBlock taking into account the current fork. Then, inside the block we would store an array of AgnosticTransaction.
// This Wrapper is meant to include all common objects across Ethereum Hard Fork Specs
type AgnosticExecutionPayload struct {
	FeeRecipient  bellatrix.ExecutionAddress
	GasLimit      uint64
	GasUsed       uint64
	Timestamp     uint64
	BaseFeePerGas [32]byte
	BlockHash     phase0.Hash32
	Transactions  []local_spec.AgnosticTransaction
	BlockNumber   uint64
	Withdrawals   []*capella.Withdrawal
}

I agree with this update. I'll also like to leave the APIClient interface as clean as possible. Right now, we have a lot of data parsing from transactions in an APIClient method, when the actual call to the EL node is only to fetch the transaction.Receipt from a given tx.Hash .
From my understanding, this data parsing should be part of the AgnosticTransaction, and should be identified/parsed when parsing the Block.


Better way to debug during the run (faster rendering)

Title

Matplotlib rendering is added in #7


Adding related repositories to README

Coverage remained the same at 69.697% when pulling 775911e72647fb0d2735bc4b6ed1b663655272bf on mtlynch:link-repos into 2a7ca071f9f968e2fecc93cc4bb6f847ecc58be7 on JeetShetty:master.


Installation failed

Dear Petersen,
Thank you very much for this great package. I have tried to install it on a Mac with a clean Python 3.6 in a virtual environment following the instructions but it fails. Here is the error:
(DSO_v2) igor@iMac-SB deep-symbolic-optimization-master % pip install -e ./dso
Obtaining file:///Users/igor/Downloads/deep-symbolic-optimization-master/dso
Preparing metadata (setup.py) ... done
Requirement already satisfied: pytest in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (7.0.1)
Requirement already satisfied: cython in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.29.32)
Requirement already satisfied: numpy<=1.19 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.19.0)
Requirement already satisfied: tensorflow==1.14 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.14.0)
Requirement already satisfied: numba==0.53.1 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.53.1)
Requirement already satisfied: sympy in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.9)
Requirement already satisfied: pandas in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.1.5)
Requirement already satisfied: scikit-learn in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.24.2)
Requirement already satisfied: click in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (8.0.4)
Requirement already satisfied: deap in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.3.3)
Requirement already satisfied: pathos in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.2.8)
Requirement already satisfied: seaborn in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.11.2)
Requirement already satisfied: progress in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.6)
Requirement already satisfied: tqdm in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (4.64.1)
Requirement already satisfied: commentjson in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.9.0)
Requirement already satisfied: PyYAML in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from dso==1.0.dev0) (6.0)
Requirement already satisfied: llvmlite<0.37,>=0.36.0rc1 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from numba==0.53.1->dso==1.0.dev0) (0.36.0)
Requirement already satisfied: setuptools in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from numba==0.53.1->dso==1.0.dev0) (59.6.0)
Requirement already satisfied: keras-preprocessing>=1.0.5 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.1.2)
Requirement already satisfied: six>=1.10.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.16.0)
Requirement already satisfied: wheel>=0.26 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (0.37.1)
Requirement already satisfied: astor>=0.6.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (0.8.1)
Requirement already satisfied: absl-py>=0.7.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.3.0)
Requirement already satisfied: google-pasta>=0.1.6 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (0.2.0)
Requirement already satisfied: wrapt>=1.11.1 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.14.1)
Requirement already satisfied: protobuf>=3.6.1 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (3.19.6)
Requirement already satisfied: keras-applications>=1.0.6 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.0.8)
Requirement already satisfied: termcolor>=1.1.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.1.0)
Requirement already satisfied: grpcio>=1.8.6 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.48.2)
Requirement already satisfied: gast>=0.2.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (0.5.3)
Requirement already satisfied: tensorboard<1.15.0,>=1.14.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.14.0)
Requirement already satisfied: tensorflow-estimator<1.15.0rc0,>=1.14.0rc0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.14.0)
Requirement already satisfied: importlib-metadata in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from click->dso==1.0.dev0) (4.8.3)
Requirement already satisfied: lark-parser<0.8.0,>=0.7.1 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from commentjson->dso==1.0.dev0) (0.7.8)
Requirement already satisfied: python-dateutil>=2.7.3 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pandas->dso==1.0.dev0) (2.8.2)
Requirement already satisfied: pytz>=2017.2 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pandas->dso==1.0.dev0) (2022.7)
Requirement already satisfied: ppft>=<IP_ADDRESS> in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pathos->dso==1.0.dev0) (<IP_ADDRESS>)
Requirement already satisfied: pox>=0.3.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pathos->dso==1.0.dev0) (0.3.0)
Requirement already satisfied: multiprocess>=0.70.12 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pathos->dso==1.0.dev0) (<IP_ADDRESS>)
Requirement already satisfied: dill>=0.3.4 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pathos->dso==1.0.dev0) (0.3.4)
Requirement already satisfied: iniconfig in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (1.1.1)
Requirement already satisfied: pluggy<2.0,>=0.12 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (1.0.0)
Requirement already satisfied: packaging in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (21.3)
Requirement already satisfied: py>=1.8.2 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (1.11.0)
Requirement already satisfied: attrs>=19.2.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (22.2.0)
Requirement already satisfied: tomli>=1.0.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (1.2.3)
Requirement already satisfied: joblib>=0.11 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from scikit-learn->dso==1.0.dev0) (1.1.1)
Requirement already satisfied: scipy>=0.19.1 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from scikit-learn->dso==1.0.dev0) (1.5.4)
Requirement already satisfied: threadpoolctl>=2.0.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from scikit-learn->dso==1.0.dev0) (3.1.0)
Requirement already satisfied: matplotlib>=2.2 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from seaborn->dso==1.0.dev0) (3.3.4)
Requirement already satisfied: mpmath>=0.19 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from sympy->dso==1.0.dev0) (1.2.1)
Requirement already satisfied: importlib-resources in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tqdm->dso==1.0.dev0) (5.4.0)
Requirement already satisfied: typing-extensions>=3.6.4 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from importlib-metadata->click->dso==1.0.dev0) (4.1.1)
Requirement already satisfied: zipp>=0.5 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from importlib-metadata->click->dso==1.0.dev0) (3.6.0)
Requirement already satisfied: h5py in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from keras-applications>=1.0.6->tensorflow==1.14->dso==1.0.dev0) (3.1.0)
Requirement already satisfied: pillow>=6.2.0 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from matplotlib>=2.2->seaborn->dso==1.0.dev0) (8.4.0)
Requirement already satisfied: cycler>=0.10 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from matplotlib>=2.2->seaborn->dso==1.0.dev0) (0.11.0)
Requirement already satisfied: pyparsing!=2.0.4,!=2.1.2,!=2.1.6,>=2.0.3 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from matplotlib>=2.2->seaborn->dso==1.0.dev0) (3.0.9)
Requirement already satisfied: kiwisolver>=1.0.1 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from matplotlib>=2.2->seaborn->dso==1.0.dev0) (1.3.1)
Requirement already satisfied: markdown>=2.6.8 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorboard<1.15.0,>=1.14.0->tensorflow==1.14->dso==1.0.dev0) (3.3.7)
Requirement already satisfied: werkzeug>=0.11.15 in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from tensorboard<1.15.0,>=1.14.0->tensorflow==1.14->dso==1.0.dev0) (2.0.3)
Requirement already satisfied: dataclasses in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from werkzeug>=0.11.15->tensorboard<1.15.0,>=1.14.0->tensorflow==1.14->dso==1.0.dev0) (0.8)
Requirement already satisfied: cached-property in /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages (from h5py->keras-applications>=1.0.6->tensorflow==1.14->dso==1.0.dev0) (1.5.2)
Installing collected packages: dso
Running setup.py develop for dso
ERROR: Command errored out with exit status 1:
command: /Users/igor/Documents/ProjSymbReg/code/DSO_v2/bin/python3 -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/Users/igor/Downloads/deep-symbolic-optimization-master/dso/setup.py'"'"'; file='"'"'/Users/igor/Downloads/deep-symbolic-optimization-master/dso/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(file) if os.path.exists(file) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' develop --no-deps
cwd: /Users/igor/Downloads/deep-symbolic-optimization-master/dso/
Complete output (28 lines):
running develop
running egg_info
writing dso.egg-info/PKG-INFO
writing dependency_links to dso.egg-info/dependency_links.txt
writing requirements to dso.egg-info/requires.txt
writing top-level names to dso.egg-info/top_level.txt
reading manifest file 'dso.egg-info/SOURCES.txt'
writing manifest file 'dso.egg-info/SOURCES.txt'
running build_ext
building 'dso.cyfunc' extension
clang -DNDEBUG -g -fwrapv -O3 -Wall -I -I -I /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include -I /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include -I /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include -I -I/Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include -I/Users/igor/Documents/ProjSymbReg/code/DSO_v2/include -I/Users/igor/.pyenv/versions/3.6.15/include/python3.6m -I/Users/igor/Documents/ProjSymbReg/code/DSO_v2/include -I/Users/igor/.pyenv/versions/3.6.15/include/python3.6m -c dso/cyfunc.c -o build/temp.macosx-12.6-x86_64-3.6/dso/cyfunc.o
In file included from dso/cyfunc.c:759:
In file included from /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include/numpy/arrayobject.h:4:
In file included from /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include/numpy/ndarrayobject.h:12:
In file included from /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include/numpy/ndarraytypes.h:1822:
/Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: warning: "Using deprecated NumPy API, disable it with "          "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
#warning "Using deprecated NumPy API, disable it with "
^
1 warning generated.
clang -bundle -undefined dynamic_lookup -L/usr/local/opt/readline/lib -L/usr/local/opt/readline/lib<EMAIL_ADDRESS>-L/Users/igor/.pyenv/versions/3.6.15/lib -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/readline/lib<EMAIL_ADDRESS>-L/Users/igor/.pyenv/versions/3.6.15/lib -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -I -I -I /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include -I /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include -I /Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/numpy/core/include -I build/temp.macosx-12.6-x86_64-3.6/dso/cyfunc.o -o build/lib.macosx-12.6-x86_64-3.6/dso/cyfunc.cpython-36m-darwin.so
clang: error: no input files
/Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/setuptools/dist.py:493: UserWarning: Normalizing '1.0dev' to '1.0.dev0'
warnings.warn(tmpl.format(**locals()))
/Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/setuptools/command/easy_install.py:159: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.
EasyInstallDeprecationWarning,
/Users/igor/Documents/ProjSymbReg/code/DSO_v2/lib/python3.6/site-packages/setuptools/command/install.py:37: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
setuptools.SetuptoolsDeprecationWarning,
error: command 'clang' failed with exit status 1
----------------------------------------
ERROR: Command errored out with exit status 1: /Users/igor/Documents/ProjSymbReg/code/DSO_v2/bin/python3 -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/Users/igor/Downloads/deep-symbolic-optimization-master/dso/setup.py'"'"'; file='"'"'/Users/igor/Downloads/deep-symbolic-optimization-master/dso/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(file) if os.path.exists(file) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' develop --no-deps Check the logs for full command output.
Any help would be appreciated.

After restarting the Mac (and deleting some installed versions of python -- but this is not relevant as I used pyenv instead), I was able to install it successfully.

I am now installing the latest version of this package and I am getting the same error. However, restarting does not seem to help this time around. I would appreciate any suggestions.
Obtaining file:///Users/igor/Documents/ProjSymbRegTest2/dso
Preparing metadata (setup.py) ... done
Requirement already satisfied: pytest in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (7.0.1)
Requirement already satisfied: cython in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.26.1)
Requirement already satisfied: numpy<=1.19 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.19.0)
Requirement already satisfied: tensorflow==1.14 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.14.0)
Requirement already satisfied: numba==0.53.1 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.53.1)
Requirement already satisfied: sympy in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.9)
Requirement already satisfied: pandas in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.1.5)
Requirement already satisfied: scikit-learn in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.24.2)
Requirement already satisfied: click in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (8.0.4)
Requirement already satisfied: deap in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.4.1)
Requirement already satisfied: pathos in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.2.8)
Requirement already satisfied: seaborn in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.11.2)
Requirement already satisfied: progress in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (1.6)
Requirement already satisfied: tqdm in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (4.64.1)
Requirement already satisfied: commentjson in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (0.9.0)
Requirement already satisfied: PyYAML in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (6.0.1)
Requirement already satisfied: prettytable in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from dso==1.0.dev0) (2.5.0)
Requirement already satisfied: setuptools in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from numba==0.53.1->dso==1.0.dev0) (59.6.0)
Requirement already satisfied: llvmlite<0.37,>=0.36.0rc1 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from numba==0.53.1->dso==1.0.dev0) (0.36.0)
Requirement already satisfied: astor>=0.6.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (0.8.1)
Requirement already satisfied: absl-py>=0.7.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.4.0)
Requirement already satisfied: wrapt>=1.11.1 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.16.0)
Requirement already satisfied: wheel>=0.26 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (0.37.1)
Requirement already satisfied: google-pasta>=0.1.6 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (0.2.0)
Requirement already satisfied: keras-preprocessing>=1.0.5 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.1.2)
Requirement already satisfied: protobuf>=3.6.1 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (3.19.6)
Requirement already satisfied: tensorflow-estimator<1.15.0rc0,>=1.14.0rc0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.14.0)
Requirement already satisfied: termcolor>=1.1.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.1.0)
Requirement already satisfied: keras-applications>=1.0.6 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.0.8)
Requirement already satisfied: six>=1.10.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.16.0)
Requirement already satisfied: gast>=0.2.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (0.5.4)
Requirement already satisfied: grpcio>=1.8.6 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.48.2)
Requirement already satisfied: tensorboard<1.15.0,>=1.14.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorflow==1.14->dso==1.0.dev0) (1.14.0)
Requirement already satisfied: importlib-metadata in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from click->dso==1.0.dev0) (4.8.3)
Requirement already satisfied: lark-parser<0.8.0,>=0.7.1 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from commentjson->dso==1.0.dev0) (0.7.8)
Requirement already satisfied: python-dateutil>=2.7.3 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pandas->dso==1.0.dev0) (2.8.2)
Requirement already satisfied: pytz>=2017.2 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pandas->dso==1.0.dev0) (2023.3.post1)
Requirement already satisfied: multiprocess>=0.70.12 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pathos->dso==1.0.dev0) (<IP_ADDRESS>)
Requirement already satisfied: dill>=0.3.4 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pathos->dso==1.0.dev0) (0.3.4)
Requirement already satisfied: pox>=0.3.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pathos->dso==1.0.dev0) (0.3.0)
Requirement already satisfied: ppft>=<IP_ADDRESS> in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pathos->dso==1.0.dev0) (<IP_ADDRESS>)
Requirement already satisfied: wcwidth in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from prettytable->dso==1.0.dev0) (0.2.12)
Requirement already satisfied: packaging in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (21.3)
Requirement already satisfied: attrs>=19.2.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (22.2.0)
Requirement already satisfied: tomli>=1.0.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (1.2.3)
Requirement already satisfied: py>=1.8.2 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (1.11.0)
Requirement already satisfied: pluggy<2.0,>=0.12 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (1.0.0)
Requirement already satisfied: iniconfig in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from pytest->dso==1.0.dev0) (1.1.1)
Requirement already satisfied: threadpoolctl>=2.0.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from scikit-learn->dso==1.0.dev0) (3.1.0)
Requirement already satisfied: joblib>=0.11 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from scikit-learn->dso==1.0.dev0) (1.1.1)
Requirement already satisfied: scipy>=0.19.1 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from scikit-learn->dso==1.0.dev0) (1.5.4)
Requirement already satisfied: matplotlib>=2.2 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from seaborn->dso==1.0.dev0) (3.3.4)
Requirement already satisfied: mpmath>=0.19 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from sympy->dso==1.0.dev0) (1.3.0)
Requirement already satisfied: importlib-resources in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tqdm->dso==1.0.dev0) (5.4.0)
Requirement already satisfied: zipp>=0.5 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from importlib-metadata->click->dso==1.0.dev0) (3.6.0)
Requirement already satisfied: typing-extensions>=3.6.4 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from importlib-metadata->click->dso==1.0.dev0) (4.1.1)
Requirement already satisfied: h5py in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from keras-applications>=1.0.6->tensorflow==1.14->dso==1.0.dev0) (3.1.0)
Requirement already satisfied: pillow>=6.2.0 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from matplotlib>=2.2->seaborn->dso==1.0.dev0) (8.4.0)
Requirement already satisfied: pyparsing!=2.0.4,!=2.1.2,!=2.1.6,>=2.0.3 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from matplotlib>=2.2->seaborn->dso==1.0.dev0) (3.1.1)
Requirement already satisfied: kiwisolver>=1.0.1 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from matplotlib>=2.2->seaborn->dso==1.0.dev0) (1.3.1)
Requirement already satisfied: cycler>=0.10 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from matplotlib>=2.2->seaborn->dso==1.0.dev0) (0.11.0)
Requirement already satisfied: werkzeug>=0.11.15 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorboard<1.15.0,>=1.14.0->tensorflow==1.14->dso==1.0.dev0) (2.0.3)
Requirement already satisfied: markdown>=2.6.8 in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from tensorboard<1.15.0,>=1.14.0->tensorflow==1.14->dso==1.0.dev0) (3.3.7)
Requirement already satisfied: dataclasses in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from werkzeug>=0.11.15->tensorboard<1.15.0,>=1.14.0->tensorflow==1.14->dso==1.0.dev0) (0.8)
Requirement already satisfied: cached-property in /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages (from h5py->keras-applications>=1.0.6->tensorflow==1.14->dso==1.0.dev0) (1.5.2)
Installing collected packages: dso
Running setup.py develop for dso
ERROR: Command errored out with exit status 1:
command: /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/bin/python -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/Users/igor/Documents/ProjSymbRegTest2/dso/setup.py'"'"'; file='"'"'/Users/igor/Documents/ProjSymbRegTest2/dso/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(file) if os.path.exists(file) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' develop --no-deps
cwd: /Users/igor/Documents/ProjSymbRegTest2/dso/
Complete output (19 lines):
running develop
running egg_info
writing dso.egg-info/PKG-INFO
writing dependency_links to dso.egg-info/dependency_links.txt
writing requirements to dso.egg-info/requires.txt
writing top-level names to dso.egg-info/top_level.txt
reading manifest file 'dso.egg-info/SOURCES.txt'
writing manifest file 'dso.egg-info/SOURCES.txt'
running build_ext
building 'dso.cyfunc' extension
clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -I/Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages/numpy/core/include -I/Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/include -I/Users/igor/.pyenv/versions/3.6.15/include/python3.6m -I/Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/include -I/Users/igor/.pyenv/versions/3.6.15/include/python3.6m -c dso/cyfunc.c -o build/temp.macosx-12.6-x86_64-3.6/dso/cyfunc.o
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
/Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages/setuptools/dist.py:493: UserWarning: Normalizing '1.0dev' to '1.0.dev0'
warnings.warn(tmpl.format(**locals()))
/Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages/setuptools/command/easy_install.py:159: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.
EasyInstallDeprecationWarning,
/Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/lib/python3.6/site-packages/setuptools/command/install.py:37: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
setuptools.SetuptoolsDeprecationWarning,
error: command 'clang' failed with exit status 1
----------------------------------------
ERROR: Command errored out with exit status 1: /Users/igor/.pyenv/versions/3.6.15/envs/dsrnew_test2/bin/python -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/Users/igor/Documents/ProjSymbRegTest2/dso/setup.py'"'"'; file='"'"'/Users/igor/Documents/ProjSymbRegTest2/dso/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(file) if os.path.exists(file) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' develop --no-deps Check the logs for full command output.


Added Rectangle functionality

Rectangle functionality :smile:
#570

wow, thx @timhovius ! Can you add some unit tests? Thx for your time

Yes I'll do that tonight 😉

Unit tests added :+1:

Added #1251 for an error in the unit tests

what about the merge? is that going to happen ?

we track this in #1450

Could anyone explain how to use <agm-rectangle></agm-rectangle>.
I'm having this issue.
Can't bind to 'north' since it isn't a known property of 'agm-rectangle'.
1. If 'agm-rectangle' is an Angular component and it has 'north' input, then verify that it is part of this module.

any help or feedback will be appreciated!


fix issues with remote debugger connect

Fix issues with remote debugger connect:

close the web socket connection when terminating debugging
check to make sure there's a device available before trying to connect
pipe embedder stdout to the console view

@danrubel

LGTM


Clean install with mysql does not create database.

A clean install via Docker-Compose seems not to populate the database. As soon as I start the container I get this notification:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'speedtest-tracker.cache' doesn't exist (Connection: mysql, SQL: delete from cache)
I checked the database connection, and that is not the issue. The given user can login to the database with the provided password. The database is just not populated.
2024-02-03T08:29:29.938393053Z In Connection.php line 829:
2024-02-03T08:29:29.938407775Z
2024-02-03T08:29:29.938415946Z   SQLSTATE[42S02]: Base table or view not found: 1146 Table 'speedtest-tracke
2024-02-03T08:29:29.938421701Z   r.cache' doesn't exist (Connection: mysql, SQL: delete from cache)
2024-02-03T08:29:29.938425834Z
2024-02-03T08:29:29.938429715Z
2024-02-03T08:29:29.938636527Z In Connection.php line 608:
2024-02-03T08:29:29.938650171Z
2024-02-03T08:29:29.938658059Z   SQLSTATE[42S02]: Base table or view not found: 1146 Table 'speedtest-tracke
2024-02-03T08:29:29.938664394Z   r.cache' doesn't exist
2024-02-03T08:29:29.938668670Z
2024-02-03T08:29:29.938672659Z
2024-02-03T08:29:29.946987107Z s6-rc: warning: unable to start service laravel-automations: command exited 1
2024-02-03T08:29:29.948247325Z /run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
2024-02-03T08:29:29.948259976Z prog: fatal: stopping the container.

Works as a charm now! Thanks for your quick solution. I love your speed
tracker!
Tiebolt
Op za 3 feb. 2024 13:42 schreef Alex Justesen @.***>:

Closed #1090
https://github.com/alexjustesen/speedtest-tracker/issues/1090 as
completed via #1093
https://github.com/alexjustesen/speedtest-tracker/pull/1093.
—
Reply to this email directly, view it on GitHub
https://github.com/alexjustesen/speedtest-tracker/issues/1090#event-11692554057,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQOK6NTNG62GNB3QNSZLCFTYRYWD7AVCNFSM6AAAAABCXZYA72VHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRGY4TENJVGQYDKNY
.
You are receiving this because you authored the thread.Message ID:
@.***
com>


[HUDI-296] Explore use of spotless to auto fix formatting errors

see jira: https://jira.apache.org/jira/projects/HUDI/issues/HUDI-296
The main changes are described below:
[1]. Add spotless plugin to the project by reference to the usage of jrtom and avro. We would run mvn spotless:check to check style and mvn spotless:apply to fix style errors.
[2]. Change the base of eclipse-java-google-style.xml to https://github.com/google/styleguide/blob/gh-pages/eclipse-java-google-style.xml and have some minor modifications.
[3]. Change max property of LineLength in checkstyle.xml for the lack of strict limit of eclipse-java-google-style.xml
[4]. Add SuppressionFilter module to handle violation between checkstyle plugin and eclipse-java-google-style.xml.
[5]. Add AvoidNestedBlocks module to checkstyle.xml to handle indentation in case statement.
[6]. Add RealtimeUnmergedRecordReader.java to checkstyle-suppressions.xml to handle indentation violation between checkstyle plugin and eclipse-java-google-style.xml.
CC @vinothchandar Please review when you get a chance. Thanks.

@vinothchandar I can restart the build in travis page, see . It seems that only committers would restart?

ah. really?.. Then better to run these locally to iterate? It seems to fail from some spotless issue.
Also can we make this work with our checkstyle rules that are already in place?

we spent a bunch of time tweaking it for our needs and got it consistent with code styling. So love to make minimal one-time formatting changes to this setup if possible cc @bvaradar

@vinothchandar @bvaradar Please restart the build due to the exception(The forked VM terminated without properly saying goodbye. VM crash or System.exit called), travis log link(https://api.travis-ci.org/v3/job/595435352/log.txt).
PS: The exception has been seen many times before, any solutions or suggestions?

This PR uses both the existing checkstyle.xml(used by maven checkstyle plugin) and eclipse-java-google-format.xml(used by spotless plugin) placed in /style folder to check code style.
After this one-time formatting, we would then benefit from spotless plugin which auto fixes formatting errors by running mvn spotless:apply. CC @vinothchandar @bvaradar

@bvaradar what do you think? I am okay if this is one time.

btw spotbugs might be a good thing to explore as well. https://spotbugs.github.io


How to set outputDir in the vue cli plugin?

What problem does this feature solve?
I am developing a vue cli plugin and I need to set outputDir via an environment variable. But I can't write this in the plugin. Is there any other way to set it up?
  api.extendPackage({
    vue: {
      outputDir: process.env.NODE_ENV === 'mp' ? './dist/mp/common' : './dist/web'
    }
  })

What does the proposed API look like?

already solved!
  "scripts": {
    "mp-build": "vue-cli-service build --mode mp --dest ./dist/mp/commom",
  },


how to debug

How to debug like guzzle client request
Types
    bool
    fopen() resource

Default
None

Constant
GuzzleHttp\RequestOptions::DEBUG

$client->request('GET', '/get', ['debug' => true]);
thanks

You may create your own Guzzle client first and set the debug request option on it. Then, set that client as the HTTP client to use with the provider. Like this:
$client = new GuzzleHttp\Client([
    'debug' => true,
]);

$provider->setHttpClient($client);

Now, all requests made by the provider will use your custom client with it's custom options.