Add ability to attach protocols to generated models

Motivation
We need all of our models generated by swift-openapi-generator to comply with protocols like Equatableor Identifiable to work with our overlaying architecture. Manually extending each generated model to conform to these protocols is insufficient and cumbersome, especially as the number of models increases.
Proposed solution
Add a feature to the swift-openapi-generator that allows specifying which protocols the generated models should conform to.  This could be implemented as a configuration option in the generator, enabling automated protocol conformance during the model generation process.
Alternatives considered
The current workaround is manually extending each generated model, like so:
extension ModelA: Equatable {}
extension ModelB: Equatable {}
extension ModelC: Equatable {}
extension ModelD: Equatable, Identifyable {
    var id: Int
    //...
}

However, this approach is not scalable and becomes unwieldy as the number of models grows.
Additional information
If there is already an existing feature to achieve this, i apologize for the oversight and kindly request guidance to the relevant documentation. I could not find any reference to such a feature in the current documentation.
References:
Identifiable Documentation
Equatable Documentation
Thank you for considering this request.

Hey, thanks for the quick response.
I have overseen that the DTO is already conforming to Hashable. This makes, of course, everything a lot easier. So my request gets kind of needless.
Indeed the Identifiable protocol suggestion would be more like a "nice to have".
I could imagine that the generator could add the Identifiable to the model as soon it sees a property id exists that also conforms to the constraint of the protocol.

This is similar to #383, where could conceivably attach arbitrary conformances or macros that are stated in the config file and it be up to the adopter to ensure these are available in their project.
It wouldn't be too different from the ability we have know to express additionalImports.

That's true, @simonjbeaumont, and the macro itself would contain the logic for how to e.g. implement Identifiable, instead of the generator having to know how to do it. I like that.

+1 to this. In my use case it would also be useful to have ability to add Identifiable conformance to some types. There is literally no other way to do this - I have a library that uses swift-openapi-generator to generate the type and expose them publicly.
It would be nice if Swift allowed to add public conformance to a protocol in an extension:
public extension Components.Schemas.SortType: Identifiable { // compiler error: 'public' modifier cannot be used with extensions that declare protocol conformances
    public var id: String { rawValue }
}

Unfortunately this is not possible in Swift, so the only solution I can see is to solve it in the openapi generator.

Hi @shadone,
does this work?

extension Components.Schemas.SortType: Identifiable { // compiler error: 'public' modifier cannot be used with extensions that declare protocol conformances
    public var id: String { rawValue }
}

(without the public modifier on the extension, only on the id property).

@czechboy0 yes, that works, sorry I forgot to mention this solution in my post. However this "hack" would be needed in every module that imports my library. Additionally it triggers a warning in Xcode 16 / Swift 6

Extension declares a conformance of imported type 'CommentSortType' to imported protocol 'Identifiable'; this will not behave correctly if the owners of 'LemmyKit' introduce this conformance in the future

Which can be silenced by adding "retroactive" flag
extension Components.Schemas.SortType: @retroactive Identifiable {
    public var id: String { rawValue }
}

This solution feels more like a hack to me, I think the only proper solution is to allow adding custom protocol in the generator itself

does the SortType publicly conform to the protocol here or just the "shape" of the protocol

I believe the visibility of the conformance is always derived from the visibility of the extended type and the protocol, i.e. there is no way to privately conform a public type to a public protocol.
But to get more details, starting a thread on the Swift Forums might be a good next step, if you're interested in the lower level compiler details.


pip3 not found when building from Dockerfile in Raspbian

Please tick all applicable boxes.

[x] I am using Python 3.5.3 or higher (run python --version on the command line)
[x] I have followed the official guides to install the bot for my system
[ ] I have updated my dependencies to the latest version using the appropriate update script

Which version are you using?

[x] The latest master version (release-260419)
[ ] The latest review version

What type of issue are you creating?

[x] Bug
[ ] Feature request
[ ] Question

Description of issue
When I build from Dockerfile in Raspbian, I get this /bin/sh: pip3: not found error and stop.
Steps to reproduce

Clone repository git clone https://github.com/Just-Some-Bots/MusicBot.git
Move to repo's dir cd MusicBot
Build docker image from Dockerfile docker build -t musicbot
Got error /bin/sh: pip3: not found

Log file
Please attach your MusicBot log file (located at logs/musicbot.log) to this issue. You can do so by dragging and dropping the file here. If you do not include your log file, you WILL be asked to provide one.
log.log

It should work with the review branch. Try that first

I changed the first line of the Dockerfile to the following and it worked for me.
FROM alpine

I changed the first line of the Dockerfile to the following and it worked for me.
FROM alpine

I confirm that it works when we remove ":edge"

I changed the first line of the Dockerfile to the following and it worked for me.
FROM alpine

I confirm that it works when we remove ":edge"


datepicker should support new angular $locale.DATETIME_FORMATS.FIRSTDAYOFWEEK parameter

Angular's $locale service now supports FIRSTDAYOFWEEK parameter that is supposed to control which week of day appears first in the calendar (daypicker template in Angular UI). Currently, Sunday is always the first one even though most of the locales use Monday as the first day of the week. Please work this into your next release.

Please work this into your next release.

Sure, feel free to send us a PR


Add the MirageOS snap.

This change is

mirageos/README.md, line 20 [r1] (raw file):

   file. There must be a way to install from this file, instead of redefining
   the dependencies, install them and call make. If we find how to do this,
   the plugin can be upstreamed to snapcraft.

Nice one! Maybe you can file a bug on the Snappy Playpen once this lands, so we can track this.

Comments from Reviewable

Comments from Reviewable

Reviewed 4 of 4 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

@dholbach reported: https://bugs.launchpad.net/snapcraft/+bug/1602733


Removed TilePryingDoAfterEvent

About the PR

Removed TilePryingDoAfterEvent.
Why / Balance

Requested in space-wizards/space-station-14#24503
Technical details

Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

FYI resolves / fixes autoresolves it.

FYI resolves / fixes autoresolves it.

Ah, was confused to why it didn't like correctly.


Types generation is not documented in cli help

 ➜ npx platformatic db help
     (...)
Available commands:

* `help` - show this help message.
* `help <command>` - shows more information about a command.
* `init` - initiate default application.
* `start` - start the server.
* `migrate` - run migrations.
* `seed` - run a seed file.

Same for schema


Add AWS_REGION in config template

As the title says, currently data loader script does not allow to specify the AWS region for deploying the DynamoDB tables. By default it is set to use 'us-east-1' zone.
I think it will be a good idea to add that config also inside the template. I have taken the note that the code supports adding a config for AWS_REGION and it does look for that setting while creating a connection object but this info is missing inside the template.

Added

This is done now.  See the utility-emissions-channel/chaincode/node/lib/aws-config.js.template


Docs: build-guide

A simple guide to help build all the components of the goldstone NOS and finally generate an ONIE-installer.

@HarshaF1 Thanks for your work. Documentation was always missing in this project. So really appreciate your work.
I'd like to check whether this step doesn't work anymore. https://github.com/oopt-goldstone/goldstone-buildimage#how-to-build
I want to be able to build the NOS image only with the buildimage repo (with submodules).
@KazuyaAnazawa I'd appreciate your comment as well because I haven't built the image for a while.

@HarshaF1 Thanks for your work. Documentation was always missing in this project. So really appreciate your work.
I'd like to check whether this step doesn't work anymore. https://github.com/oopt-goldstone/goldstone-buildimage#how-to-build I want to be able to build the NOS image only with the buildimage repo (with submodules).
@KazuyaAnazawa I'd appreciate your comment as well because I haven't built the image for a while.

You are right @ishidawataru . We can build the ONIE installer just with buildimage.
The steps mentioned in the build-guide would be needed if someone wants to change/update any of the submodules. I will rephrase the description in the document and commit again.

Thanks!


When internet is slow, getting a timeout log but not getting a callback

Hi @TatankaConCube
I am using this 'connectycube_sdk: ^2.11.2' for adding chat in our application. When the network is good, things work well but when network is flaky i can see the internal logs of timeout but couldn't  get the callback.
I tried resetting the timeout too but that too didn't work.
Can you please help with this issue

do you mean this CubeChatConnection.instance.connectionStateStream listener? could you please provide the log with the 'timeout' issue you say? can you reproduce the same issue in our Chat Sample?

@TatankaConCube yes i did use this as well. Also i have used
CubeChatConnectionSettings.instance.totalReconnections = 1;
CubeChatConnectionSettings.instance.reconnectionTimeout = 300;

the reconnection manager will try to reconnect after losing the connection (the state changes to the ForceClosed), does the reconnection manager try to reconnect? do you receive the updated state ForceClosed?

@TatankaConCube yes it tries to reconnect. But after all the tries fail it doesnot give the timeout callback.

no activity for a long time, closing.


builder and team classes need smashed together

on 2nd thought, this actually kinda makes sense how it is currently done


Want to factor config.toml out of ~/.config

Using autograder from one semester to the nest seems to involve too much manual hacking of config.toml
It would be useful if we could switch config.toml without modifying the one in ~/.config. Maybe a venv-like thing? Or an environment variable for the path to config.toml?

now the directory name (only) can be read from the shell environment variable GRADE_CONFIG_DIR. No need to put "config.toml" in that path.


Add --non-interactive to @prisma/migrate

Problem
I have a script that seeds the database with fake data. But before it does, it first checks that I'm not running this in production env/DB (😅) and after that, It tries to run prisma migrate reset --preview-feature like so:
const prismaBinary = join(__dirname, "..", "node_modules", ".bin", "prisma");

execSync(`${prismaBinary} migrate reset --preview-feature`, {
  env: {
    ...process.env,
    DATABASE_URL: config.DATABASE_URL,
  },
});

The thing is, when it tries to run it, I get the following error:
Error: We detected that your environment is non-interactive. Running this command is not supported in this context.
Error: Command failed: /home/eliya/projects/screendow/packages/server/node_modules/.bin/prisma migrate reset --preview-feature

Suggested solution
Add a flag --non-interactive or --force
Alternatives
run the reset manually and only then run the seed script
Additional context

None

This will be addressed in #4773. Closing as duplicate.

This will be addressed in #4773. Closing as duplicate.


[Bug]: Cannot list CFOrgs created as admin user

What happened?
When using cf create-org the CFOrg entry is created in the cf namespace, but a cf o call does not list any of those created.
What you expected to happen
The org to be listed if successfully created by the same user.
Acceptance Criteria
GIVEN An admin user accessing cf on k8s
WHEN I call cf create-org and then interact with the new org
THEN I can successfully list, target, and create spaces in the org
How to reproduce it (as minimally and precisely as possible)
❯ cf create-org MyOrg
Creating org MyOrg as kubernetes-admin...
OK
TIP: Use 'cf target -o "MyOrg"' to target new org
❯ cf target -o MyOrg
Organization 'MyOrg' not found.
FAILED
❯ cf o
Getting orgs as kubernetes-admin...

No orgs found.
❯ kubectl get CFOrg -n cf
NAME                                          DISPLAY NAME   AGE
cf-org-47ca075f-302a-4339-ad4b-d017b24d164f   MyOrg          15s
cf-org-fe4d0d21-9169-4995-9c5a-972a2dc34059   test           82m
❯ cf create-org MyOrg2
Creating org MyOrg2 as kubernetes-admin...
OK

TIP: Use 'cf target -o "MyOrg2"' to target new org
❯ kubectl get CFOrg -n cf
NAME                                          DISPLAY NAME   AGE
cf-org-47ca075f-302a-4339-ad4b-d017b24d164f   MyOrg          26s
cf-org-8d192488-d31a-420b-a405-f83bf25c89df   MyOrg2         4s
cf-org-fe4d0d21-9169-4995-9c5a-972a2dc34059   test           82m
❯ cf o
Getting orgs as kubernetes-admin...

No orgs found.

Anything else we need to know?
Using an EKS IAM user with username of format<EMAIL_ADDRESS>which worked fine to install korifi.
Originally used a cf-admin user as the admin username, but changed post installation to my username as I could not admin the install with that service account. Can successfully cf login and execute cf create-org. Using cf namespace. Have validated correct roles have been applied.
Environment
Revision of codebase:
Kubernetes version (use kubectl version):

Client Version: v1.25.2
Kustomize Version: v4.5.7
Server Version: v1.22.13-eks-15b7512
Cloud provider or hardware configuration: EKS with IAM linking enabled
Others:

Also occurs on the new 0.3.0 release. Here's the output:-
cf create-org MyOrg
Creating org MyOrg as ...
Organization 'MyOrg' already exists.
OK

❯ cf o
Getting orgs as ...

No orgs found.

I noticed it said getting orgs as ... so I installed the whoami plugin.
Also when I install the whoami plugin I get this:-
Installing plugin Whoami Plugin...
OK

Plugin Whoami Plugin 0.2.0 successfully installed.
❯ cf whoami
FAILED
Nobody is logged in
FAILED
Interesting - you are logged in, but your username is empty. Mysterious!
You are logged in as  at https://api.aws.12factor.xyz

This appears to be a mismatch between IAM Users in EKS and the concept of the default cf-admin install user which karifi seems unable to fetch as an identity, even though this cf-admin user in IAM successfully installed Korifi. (I did a full reinstall).
Help greatly appreciated as I'm at a hackathon with 75 people who may need to use this in the morning UK time!!! Thanks.

It seems v0.3.0 is also failing to create new orgs fully. cf create-orgs is hanging but CFOrg is created and the namespace, but no role bindings in the namespace. Can't fine any other errors except this from the korifi-api pod:-
{"level":"error","ts":1664394149.6585557,"logger":"Org Handler","msg":"Failed to create org","correlation-id":"a32d83d6-7828-4617-b0d7-8cc7f53cf786","Org Name":"MyNewOrg","error":"cf org did not get Condition `Ready`: 'True' within timeout period 120000 ms","stacktrace":"[code.cloudfoundry.org/korifi/api/apierrors.LogAndReturn](http://code.cloudfoundry.org/korifi/api/apierrors.LogAndReturn)\n\t/workspace/api/apierrors/errors.go:35\[ncode.cloudfoundry.org/korifi/api/handlers.(*OrgHandler).orgCreateHandler](http://ncode.cloudfoundry.org/korifi/api/handlers.(*OrgHandler).orgCreateHandler)\n\t/workspace/api/handlers/org_handler.go:67\[ncode.cloudfoundry.org/korifi/api/handlers.(*AuthAwareHandlerFuncWrapper).Wrap.func1](http://ncode.cloudfoundry.org/korifi/api/handlers.(*AuthAwareHandlerFuncWrapper).Wrap.func1)\n\t/workspace/api/handlers/auth_aware_handler.go:81\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2109\[ncode.cloudfoundry.org/korifi/api/handlers.(*AuthenticationMiddleware).Middleware.func1](http://ncode.cloudfoundry.org/korifi/api/handlers.(*AuthenticationMiddleware).Middleware.func1)\n\t/workspace/api/handlers/authentication_middleware.go:66\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2109\[ngithub.com/gorilla/handlers.loggingHandler.ServeHTTP](http://ngithub.com/gorilla/handlers.loggingHandler.ServeHTTP)\n\t/go/pkg/mod/github.com/gorilla/handlers@v1.5.1/logging.go:47\[ncode.cloudfoundry.org/korifi/api/handlers.HTTPLogging.Middleware.func1](http://ncode.cloudfoundry.org/korifi/api/handlers.HTTPLogging.Middleware.func1)\n\t/workspace/api/handlers/http_logging_middleware.go:28\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2109\[ncode.cloudfoundry.org/korifi/api/handlers.CorrelationIDMiddleware.Middleware.func1](http://ncode.cloudfoundry.org/korifi/api/handlers.CorrelationIDMiddleware.Middleware.func1)\n\t/workspace/api/handlers/correlation_id_middleware.go:30\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2109\[ngithub.com/gorilla/mux.(*Router).ServeHTTP](http://ngithub.com/gorilla/mux.(*Router).ServeHTTP)\n\t/go/pkg/mod/github.com/gorilla/mux@v1.8.0/mux.go:210\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2947\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1991"}
{“level”:“info”,“ts”:1664394149.6586468,“logger”:“Org Handler”,“msg”:“handler returned error”,“correlation-id”:“a32d83d6-7828-4617-b0d7-8cc7f53cf786",“error”:“cf org did not get Condition `Ready`: ‘True’ within timeout period 120000 ms”}

Hey @adamfowleruk ,
I saw on that slack thread that you seem to have figured org creation out. If that is sorted out, can we close the issue?
Regarding the cf whoami plugin - we never thought about cf plugins support - I will open a separate issue about that. For the time being you could use the /whoami endpoint - it is not part of the CF API but we implemented it for our own purposes:
❯ cf curl /whoami
{"name":"cf-admin","kind":"User"}

I have figured it out, but I think we need to change this to a documentation bug and keep it open. I'll happily send a PR about this for the Install.MD file on Monday but it will vex anyone else on EKS as it's a very specific 'fix'.
For others' benefit, and until the docs PR is issued by me, you need to use the full URN for the new 'cf-admin' user in all fields, even though it can theoretically be mapped with a shorthand of the user in EKS. CF doesn't seem to like that. i.e. ADMIN_USERNAME is the URN, and there needs to be a specific 'username' field (not in the docs) with the URN, and the EKS mapUsers need this explicitly too.

@adamfowleruk Are you still up to PR-ing the install guide change?

It looks like we need a generic explore about running Korifi on EKS. The way they integrate their own IAM user management with Kubernetes looks quite involved and it leverages group bindings, which we don't support at the moment. I will create that explore and close this once I've verified the warning behaviour is correct.


bug fix: make sure cri image is pinned when it is pulled outside cri

Fixes: #9726
Update the CRIImageService.UpdateImage routine to pass image ref to getLabels so that a CRI image could be correctly pinned if it's pulled outside of CRI, e.g. via ctr image pull.

/retest

/test pull-containerd-node-e2e

Thanks @mikebrow @ruiwen-zhao @adisky. The PR is updated, please take another look. thanks!

/retest

Hi folks, the pause image is still not pinned when upgrading from 1.6.28 to 1.6.33. During the upgrade, the pause image remained unchanged. Although I use ctr image import pause.tar to load the same pause image again, it won't add the pinned label.
log: time="2024-10-24T09:34:11.679108113Z" level=info msg="ImageUpdate event &ImageUpdate{Name:registry.k8s.io/pause:3.9,Labels:map[string]string{io.cri-containerd.image: managed,},XXX_unrecognized:[],}"


http response is not accepted by browser

I created a simple HEADERS response followed by a DATA frame to the browser (both firefox and chrome)
hpack_encoder = Encoder()
frm_headers = HeadersFrame(stream_id)
headers = {":status": 200,"content-length": 2,"content-type": "text/plain"}
encoded_headers = hpack_encoder.encode(headers,huffman=False)
frm_headers.flags.add('END_HEADERS')
ssl_sock.send(frm_headers.serialize())
ssl_sock.send(frm_data)
and browser didn't show anything. so I dumped the content of encoded_headers and got '\\x012_\ntext/plain\x88'. If I move the byte '\x88', which is ":status: 200", to the head, i.e. '\x88\\x012_\ntext/plain', both browsers display the response data correctly. Thus I think hpack encoder should place the pseudo-header fields in the beginning of HEADERS frame. RFC 7540 mentions this in section <IP_ADDRESS>,

All pseudo-header fields MUST appear in the header block before regular header fields. Any request or response that contains a pseudo-header field that appears in a header block after a regular header field MUST be treated as malformed

So, that's an interesting idea. Right now, HPACK simply does not police this: it allows the possibility of emitting header fields that are not in order. That's obviously somewhat problematic whenever someone passes in a dictionary which can lose the order.
My inclination is to split the difference: if you pass HPACK a dictionary it will 'fix' the order for you, but if you pass an iterable of two-tuples it'll leave them alone. How does that sound to you @derekchentrendmicro?
(Also, note that HPACK is now a separate library with its own repository at github.com/python-hyper/hpack.)

You can see the proposed change at python-hyper/hpack#32. If it resolves your problem @derekchentrendmicro, then please let me know and I'll aim to ship a release containing the fix.

Also, fwiw @derekchentrendmicro, unless you're really trying to do something clever you may find hyper-h2 is the tool you want, rather than constructing frames yourself.

it's good, especially for testing, to have the choice to preserve the order or not.
 It looks interesting. I'll see if it can fulfill my needs.


Readium Box account down => broken "test library" in Travis

https://github.com/readium/readium-js-viewer/blob/develop/grunt/createTestLibrary.js#L18
var testbooksUrl = 'https://readiumfoundation.box.com/shared/static/9tv7s250je6io8nebxvh.zip';

Related: https://github.com/readium/readium-js-viewer/issues/305

Fixed: https://github.com/readium/readium-js-viewer/commit/b3763d5e9f66768ab40b4db6da184c15b0f1d9a6


UtilityTokenInterface::burn() should not require burner

UtilityTokenInterface::burn() should not have burner as an argument. UtilityToken also doesn’t.

This will be taken care with issue #499


Enabled Codecov for GitHub Actions

Made the following changes:
-Created a coverage XML file
-Added codecov upload to github action

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@25562bc). Click here to learn what that means.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff            @@
##             master       #2   +/-   ##
=========================================
  Coverage          ?   96.34%
=========================================
  Files             ?        6
  Lines             ?      246
  Branches          ?        0
=========================================
  Hits              ?      237
  Misses            ?        9
  Partials          ?        0

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


expose shared memory linking

closes #94
I have not tested it for speed or added unittests.
As unit tests have changed significantly in #93 I suggest merging that first, and I will add them then.

Implementing in new PR as files needed on master has change significantly


upgrade to support dbt-core v1.4.0

Background
The latest version of dbt Core,dbt-core==1.4.0, was published on January 25, 2023 (PyPI | Github). In fact, a patch, dbt-core==1.4.1 (PyPI | Github), was also released on the same day.
How to upgrade
https://github.com/dbt-labs/dbt-core/discussions/6624 is an open discussion with more detailed information. If you have questions, please put them there! https://github.com/dbt-labs/dbt-core/issues/6849 is for keeping track of the community's progress on releasing 1.4.0
The above linked guide has more information, but below is a high-level checklist of work that would enable a successful 1.4.0 release of your adapter.

[x] support Python 3.11 (only if your adapter's dependencies allow)
[ ] Consolidate timestamp functions & macros
[x] Replace deprecated exception functions
[ ] Add support for more tests

the next minor release: 1.5.0
FYI, dbt-core==1.5.0 is expected to be released at the end of April. Please plan on allocating a more effort to upgrade support compared to previous minor versions. Expect to hear more in the middle of April.
At a high-level expect much greater adapter test coverage (a very good thing!), and some likely heaving renaming and restructuring as the API-ification of dbt-core is now well underway. See https://github.com/dbt-labs/dbt-core/milestone/82 for more information.

Done for dbt-fal, #732 and #736.
Thanks for reaching out!


Refactor PoC for chat client and server

I think it would be much cleaner to have separate submodules for client and server... ie their own folders with init.py etc. This means if multiple files are needed they're kept separate

The final implementation would have a far better code structure. There are already existing folders/modules for client and server.


gpu power: update the ratio model

The node total GPU usage is always 0, and thus forcing GPU energy evenly attributed on all Pods. Since GPU process utilization already accounts GPU resource usage, this PR uses GPU utilization, that is already set in the container metrics, to account GPU energy ratio.

Thanks @rootfs, I'm seeing more reasonable numbers now on the baremetal OCP cluster with the GPU operator installed, with a simple test Pod running matrix multiplication. I am seeing between 20 and 50 Watts for the workload Pod while under load. From DCGM I see 20 Watts at idle and 70 Watts at full load, so between 20-50 seems "right".

thank you @dagrayvid for confirmation!

@marceloamaral can you elaborate?

@sunya-ch second thought, your fix is actually a better one. Reverted mine and used yours


[issue 21] - Enabling WildFly Helm Charts based provisioning test

Description
Enabling WildflyHelmChartProvisionerTest
Part of #21
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change
[x] Chore (non-breaking change which doesn't affect codebase;
test, version modification, documentation, etc.)

Checklist

[x] Code contributed by me aligns with current project license: Apache 2.0
[x] Pull Request contains a description of the changes
[x] Pull Request does not include fixes for multiple issues/topics
[x] Code is self-descriptive and/or documented
[ ] I have implemented unit tests to cover my changes
[ ] I tested my code in OpenShift

/test all

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required

/retest-required

/retest

/retest

/retest


不支持add column if not exists语法，解析会报错

Please provide a detailed title (e.g. "Broker crashes when using TopN query with Bound filter" instead of just "Broker crashes").
Affected Version
1.2.23
The Druid version where the problem was encountered.
Description
解析sql的时，如果有add column if not exists语法会报错，但是sql是可以执行成功的
Please include as much detailed information about the problem as possible.

Cluster size
Configurations in use
Steps to reproduce the problem
The error message or stack traces encountered. Providing more context, such as nearby log messages or even entire logs, can be helpful.
Any debugging that you have already done

Please report this to https://github.com/alibaba/druid


Small cleanup

Removed folders of generated files (pychache and .ipynb_checkpoints), and added those folders to .gitignore
Specified requirements in standard requirements.txt format

Great...!! Thanks Sanders...!! I will also add some commands to my gitignore.... I am still making some changes in my code.


Testing

synchronized queueing in queues.jl
improved logic of function work
visualization added simviz.jl

major first improvement


Implement support for Airplane server

Some servers in our community requested this. We're growing fairly quickly in server count, and larger forks like Purpur now pull us in.

Thank you for the PR!
Most of this backend code in this repository is no longer in use in production. You can find the new repository here: https://github.com/Bastian/bstats-backend
Fortunately @toinouH was kind enough to create a PR on the new repository :)


Verticapylab - connection Autoconnection not working

By default inside the connect.py file, the host parameter is set to "vertica-demo" for the verticapylab_connection function.
This needs to be changed to "verticadb" considering the new changes in VerticaPyLab.

@mail4umar can you please do a PR with the needed changes?


feat: web worker support

Not sure if this should be part of the core, since usual DOM APIs are enabled with envs
Maybe we can enable some kind of presets, like @vitest/frontend with happy-dom, worker by default, or just publish this as a different package
Closes #722

Emmm, interesting. I think I'd prefer to have it separate from the core to avoid the complexity and also could be a playground to dogfooding out programmatic/plugin API

Emmm, interesting. I think I'd prefer to have it separate from the core to avoid the complexity and also could be a playground to dogfooding out programmatic/plugin API

What do you think about something like this:

Config option addons (should not clush with plugins, the best I came up with) receives array of strings
These strings are paths to modules that export default a function with arguments equeal to __vitest_worker__  and config (maybe?). I wouldn't really want to expose them, but I need them to extend VitestRunner
Call these addons with setupFiles

We can also just expose some kind of function like defineAddon() that receives a function with the same arguments ^

In the end I decided that using VitestRunner is quite a niche usecase, you would usually just await import something. But since I need to change the context, I decided to just use __vitest_worker__ inside web-worker.

@poyoho I am very confused why CI is failing. It says Cannot find name '__vitest_worker__' in mocker.ts. Can you help me?

when build the mock.ts no include worker.ts so do not had the __vitest_worker__ typescript define.
so @sheremet-va you can add this dts in src/index.ts will pass the ci.
declare global {
  let __vitest_worker__: import('vitest').WorkerGlobalState
}

@antfu it failes on build, that's what I've been trying to tell you

@antfu CI is broken.
TBH this PR is taking so long just because of this change with global __vitest_worker__. We should either make every call to __vitest_worker__ with a wrapper with @ts-expect-error inside, or expose __vitest_worker__

I will handle that when we are preparing the release of v0.7


Publish tags/releases

Hi,
Thanks for a great utility!
I was wondering if you're open to publishing tags (and maybe releases) on this repo?
This will allow installing a specific version using npm, even if you don't list the package on npmjs.com.
e.g.
"dependencies": {
       "summernote-cleaner": "git+https://github.com/DiemenDesign/summernote-cleaner.git#v1.10.0"
},

Relates to #74

As I mentioned in the linked issue, I don't use npm to install, or bring in dependencies. If you would like to add it if it makes using the plugin better for you, go for it. Just be mindful that I'd more than likely not update those changes as time goes, but I'm all for someone doing that if it helps.

@DiemenDesign thanks for your response.
I understand. I think I could submit a PR with a github action that can automate the release. With that in mind, I was wondering if you make a habit of updating the version in the package.json when you merge a PR?

I don't, but I probably should. Lazy developer, I know, lol.


Swap out php converter for better one

Ideally we can turn this package into an npm module and rely on it.
https://github.com/incarnate/curl-to-php

I'm leaning toward dropping PHP support and linking to incarnate's project: https://incarnate.github.io/curl-to-php/


Singleton feature-service

Hello, is there any way to register feature-service as a singleton ?
I would like to share instance of service between multiple feature apps. Singleton service A should be initialized in create function so i can take service B (also singleton) registered as dependency and put it into constructor of servcie A. Featurehub runs create function for each feature app integrated so each feature app has its own instance of feature service.
Of course I can create instances of both services elsewhere and pass it to featureServiceDefinitions. But it would be much cleaner if I can specify if service is singleton directly in featureServiceDefintion.

I would like to achieve something like this.
export const ServiceADefinition = ({
	id: 'service-a',
	dependencies: {
		featureServices: {
			'service-b': '^1.0.0'
		}
	},
	create: (env: any) => {
		return {
			'1.0.0': () => ({
				// both services A and B should be singletons
				featureService: new ServiceA(env.featureServices['service-b'])
			})
		};
	},
	singleton: true // possible setting?
});

You can just move the feature service instance to the upper function scope (in create) to create a singleton instance that is used for all consumers.
export const ServiceADefinition = ({
	id: 'service-a',
	dependencies: {
		featureServices: {
			'service-b': '^1.0.0'
		}
	},
	create: (env: any) => {
		const featureService = new ServiceA(env.featureServices['service-b']);

		return {
			'1.0.0': () => ({
				// both services A and B should be singletons
				featureService
			})
		};
	},
});

You can just move the feature service instance to the upper function scope (in create) to create a singleton instance that is used for all consumers.
export const ServiceADefinition = ({
	id: 'service-a',
	dependencies: {
		featureServices: {
			'service-b': '^1.0.0'
		}
	},
	create: (env: any) => {
		const featureService = new ServiceA(env.featureServices['service-b']);

		return {
			'1.0.0': () => ({
				// both services A and B should be singletons
				featureService
			})
		};
	},
});

exactly what I needed


[WIP] [2.4] Support API URL for WeChat notifier

Proposed changes
Support API URL for WeChat notifier
Related PR:
https://github.com/rancher/rancher/pull/24353
https://github.com/rancher/types/pull/1044

Types of changes

New feature (non-breaking change which adds functionality)

Linked Issues
https://github.com/rancher/rancher/issues/23507

Further comments

fix en-us and support translation


Display Issue (Bad Colour Choice) for Restart Notification

With the latest Atom version 1.12.2 and Atom Material (Dark), the following issue remains...
It happens when the below notification is triggered (after updating packages that require restart). It's just a bad choice of color which makes it almost impossible to see the restart text on the button both before and after the clicking.

Hope it can be fixed soon. Thanks.

Can confirm.


Both Server and StreamingServer accept middleware arrays

Builds on top of #277 and #281

Minor update to avoid failing test on legacy PHP 5.3 :shipit:


#49: GitHub CI Benchmarking

Heads up: The build time on Phoenix (both CPU and GPU) using the previous slurm scripts was very slow, almost assuredly slower than it was on an actual node. I don't know if this had to do with the resource request or something else. But we should pay attention that the run-time is not likewise much worse via this benchmark CI than it is on an "actual" node.

(perhaps useful for something https://github.com/MFlowCode/MFC/commits/autobench/)

[Feature request @henryleberre ] A dump of the nsight sys CLI output using flags that make it... readable/usable. Main goal is to make sure that a specific nvtx range has not gotten disproportionately more expensive for an unknown reason.

Heads up: The build time on Phoenix (both CPU and GPU) using the previous Slurm scripts was very slow, almost assuredly slower than it was on an actual node. I wonder if this had to do with the resource request or something else. But we should pay attention that the run-time is not likewise much worse via this benchmark CI than it is on an "actual" node.
For example, check this out: MFlowCode/MFC/actions/runs/7215702552/job/19660473029
Obviously, it doesn't take 30 minutes to build and 1.25 hours to test CPU MFC on Phoenix using 12 cores (which should be the whole node, I think). Please let me know if you find a "fix" for this.

I am amending this comment. Test is indeed slow because all jobs run on one core right now (despite the -j 24 flag), it's rebuilding the postprocess code and dependencies, and the -a option.

I added a linting script and CI job therefor. Although I fixed a few warnings and errors, an undergraduate student could have a field day fixing the rest.

[Feature request @henryleberre ] A dump of the nsight sys CLI output using flags that make it... readable/usable. Main goal is to make sure that a specific nvtx range has not gotten disproportionately more expensive for an unknown reason.

@sbryngelson Perhaps this feature could be added in a later revision?

@sbryngelson I think this PR is mostly ready. Related tickets:

Fixed #266.. argument parsing was a nightmare.
Fixed #230.
Implemented #49 per 🤝.

Caveats:

The current list of benchmark cases is just that of 3D examples. toolchain/bench.yaml lists the benchmark cases and how they run.
No PR comments. A quirk of how GitHub Actions implements the pull_request trigger makes it so that it cannot have a GITHUB_TOKEN with the ability to post comments, if the PR is made from a fork - which is almost always the case for us. It currently just prints the Markdown it would have posted as a comment. There are ways to get around this (sigh) but I didn't venture (too deep into) into this territory where security, practicality, and ease-of-use clash.

@sbryngelson I think this PR is mostly ready. Related tickets:

Fixed Run Phoenix jobs using available CPU cores #266.. argument parsing was a nightmare.
Fixed Is it worth linting the toolchain/? #230.
Implemented Use GitHub CI to continuously benchmark some example cases #49 per 🤝.

Caveats:

The current list of benchmark cases is just that of 3D examples. toolchain/bench.yaml lists the benchmark cases and how they run.
No PR comments. A quirk of how GitHub Actions implements the pull_request trigger makes it so that it cannot have a GITHUB_TOKEN with the ability to post comments, if the PR is made from a fork - which is almost always the case for us. It currently just prints the Markdown it would have posted as a comment. There are ways to get around this (sigh) but I didn't venture (too deep into) into this territory where security, practicality, and ease-of-use clash.

Great! So how do we keep track of performance then? Or check a PR's performance?
I can tune the examples myself or add more as needed.

[Feature request @henryleberre ] A dump of the nsight sys CLI output using flags that make it... readable/usable. Main goal is to make sure that a specific nvtx range has not gotten disproportionately more expensive for an unknown reason.

@sbryngelson Perhaps this feature could be added in a later revision?

Sure, so long as it doesn't require a major toolchain update.

@sbryngelson, could you give me the output of these commands on Phoenix? (or grant me read permissions)
$ ls /storage/coda1/p-sbryngelson3/0/sbryngelson3/runners/actions-runner-3/_work/MFC/MFC/master/
$ ls /storage/coda1/p-sbryngelson3/0/sbryngelson3/runners/actions-runner-3/_work/MFC/MFC/master/
$ .. any *.out files in /storage/coda1/p-sbryngelson3/0/sbryngelson3/runners/actions-runner-3/_work/MFC/MFC or one level down

These runs are under your account so I otherwise cannot debug without resorting to iteratively pushing and retriggering these workflows with aggressive logging.

For nsys profiling on some systems (like Phoenix) we need the nsys command to precede the mpi binary call like so nsys profile --stats=true --trace=mpi,nvtx  mpirun -np 1 ../../build/no-debug_gpu_mpi/simulation/simulation. This particular case gives an output that does indeed make sense:
 Simulating a 399x0x0 case on 1 rank(s)
 [  0%]  Time step        1 of 2 @ t_step = 0
 Final Time    0.000000000000000
Generating '/scratch/4450742/nsys-report-2eff.qdstrm'
[1/3] [========================100%] report12.nsys-rep
[2/3] [========================100%] report12.sqlite
[3/3] Executing 'nvtxsum' stats report

 Time (%)  Total Time (ns)  Instances    Avg (ns)       Med (ns)      Min (ns)     Max (ns)    StdDev (ns)   Style         Range
 --------  ---------------  ---------  -------------  -------------  -----------  -----------  -----------  -------  ------------------
     54.5      126,113,739          1  126,113,739.0  126,113,739.0  126,113,739  126,113,739          0.0  PushPop  MPI:MPI_Init
     22.4       51,874,387          1   51,874,387.0   51,874,387.0   51,874,387   51,874,387          0.0  PushPop  Time_Step
     18.6       43,032,719          1   43,032,719.0   43,032,719.0   43,032,719   43,032,719          0.0  PushPop  MPI:MPI_Finalize
      3.0        6,944,330          3    2,314,776.7       80,242.0       73,200    6,790,888  3,876,427.7  PushPop  RHS-Riemann
      0.7        1,687,441          3      562,480.3       23,976.0       19,438    1,644,027    936,649.6  PushPop  RHS-MPI
      0.5        1,130,619          3      376,873.0       82,640.0       73,695      974,284    517,392.4  PushPop  RHS-WENO
      0.2          498,715          3      166,238.3       22,361.0       19,634      456,720    251,568.2  PushPop  RHS-CONVERT
      0.0          111,616        387          288.4          190.0          178       21,550      1,085.9  PushPop  MPI:MPI_Bcast
      0.0           85,226          3       28,408.7       24,963.0       22,657       37,606      8,048.1  PushPop  RHS_Flux_Add
      0.0           36,969          2       18,484.5       18,484.5       16,421       20,548      2,918.2  PushPop  MPI:MPI_Barrier
      0.0              998          3          332.7          266.0          254          478        126.0  PushPop  Viscous
      0.0              952          3          317.3          327.0          260          365         53.2  PushPop  RHS_Hypoelasticity

Generated:
    /storage/home/hcoda1/6/sbryngelson3/MFC/examples/1D_sodshocktube/report12.nsys-rep
    /storage/home/hcoda1/6/sbryngelson3/MFC/examples/1D_sodshocktube/report12.sqlite

FYI @henryleberre  (to make your life easier) -- Summit is going offline, so not much focus (if any) needs to be placed on the lfs scheduler/"template", and I don't think we use any computers with PBS scripts anymore. Of course this sort of secretly means that all the complexity of these computers is being offloaded into SLURM scripts.

@henryleberre I added open issues that your PR here might touch. If it won't, remove them (or leave them until you know).


feat: make ddev composer create fully compatible with composer create-project

The Issue
Composer installer plugins and scripts may lead to error while cloning a package with ddev composer create. Some install instructions in the docs therefor use --no-scripts to avoid issues. Users do not know about the special behavior of ddev composer create and the differences to composer create-project therefor adding --no-plugins and --no-scripts by default would avoid issues automatically.
How This PR Solves The Issue
This PR adds the --no-plugins and --no-scripts to the composer create-project command to avoid issues by default and makes the manual usage of these options superfluous.
There may be rare cases where plugins and scripts should be run, therefor the new flag --preserve-flags is introduced to fallback to the old behavior and not add these two options. But normally it should be fine to running scripts and plugins later with composer install.
The composer create command now emulates exactly the behavior of the original create-project command:

clone
ddev only: move to project root
call post-root-package-install script
ddev only: restart project and generate config files if available for project type
call pre-update-cmd or pre-install-cmd script
update or install
call post-update-cmd or post-install-cmd script
call post-create-project-cmd script

Manual Testing Instructions
Craft CMS and Laravel were using the --no-scripts option in the quick start guide and must be tested to still work properly.
Automated Testing Overview

Related Issue Link(s)
Release/Deployment Notes

I appreciate the creativity here and look forward to looking at this more, but you should know that ddev composer create has a long history of incremental changes, and there are lots of ways it can go bad in various contexts (including NFS). So I really wouldn't be willing to bring this in before the upcoming release.

I appreciate the creativity here and look forward to looking at this more, but you should know that ddev composer create has a long history of incremental changes, and there are lots of ways it can go bad in various contexts (including NFS). So I really wouldn't be willing to bring this in before the upcoming release.

No hurry to get it in. Has to be tested for all project types. Thanks to @rpkoller who makes a great job in testing :)
But this is a big step for ddev composer create and will save us time in implementing project type specific workarounds!

Manually tested craftcms without the --no-scripts and it worked fine.

Rebased.

Please make sure when working on this that ddev composer create errors out if no args are provided.

I moved this to v1.22.5, assuming we can do it with no disruption to people.

Rebased, fixing conflicts. Hopefully correctly.

The test failure here in TestConfigSetValues is due to ddev config --docroot=web being actually overwritten by the discovered docroot, for example public in https://github.com/ddev/ddev/actions/runs/6668917097/job/18125558518?pr=5058
So the test has actually caught a real problem with the code (or the rebase).

after working on #5499 @rfay asked me to review this.. I took a more thorough look and I now understand most of it. It obviously needs to be rebased and probably adapted a bit if my PR gets in...
Thoughts that I have for now:

There may be rare cases where plugins and scripts should be run, therefor the new flag --preserve-flags

I wonder what those rare cases are, do we know any?
Also, instead of adding such a flag I wonder if something more like --with-scripts and --with-plugins is more obvious.
Also, while I could test and understand the need for --no-scripts like on craftcms, why are we also adding --no-plugins. Is there an example of this.
I would also like to ask, and I just saw #4273, the slowness that trigger that improvements, was it because of the shared folder or something else? Would that still be an issue with mutagen. Isn't running composer install in the root directory after rsyncing what composer create creates a similar impact of performance of what an rsync do afterwards? Not trying to undo the whole work, but i like the idea of ddev doing as little as possible so to keep compatibility with the composer create command as much as I can so I am trying to understand that need.
Finally, a crazy idea, not for this PR but just sharing it: I was looking a bit at the code on composer and I saw this: https://github.com/composer/composer/blob/da83d29d8ac634783bc70b0f3b7847bae3e081d9/src/Composer/Command/CreateProjectCommand.php#L232
I am wondering if we can have a global composer plugin of our own (ddev owned) that could hook into this and do the initial rsync and then continue whatever composer create needs to do on a new dir. Obviously this would fail if --no-plugins is actually needed for any reason or bypass by the user, so we should have a fallback behavior as well.

and I just saw https://github.com/ddev/ddev/pull/4273, the slowness that trigger that improvements, was it because of the shared folder or something else?

Both Colima (with sshfs) and NFS often fail to sync properly with massive file changes, and of course the changes are really slow with NFS. Mutagen solves this problem, but using a separate directory that's not a mount and then copying has worked far better.

Rebased, hope I didn't make any mistakes.
This now is based on

#5499 from @hanoii

So it will need testing and careful review. I hope we can recover it, as it's important work.

is it already testable again at this point or is some more work needed? cuz i have to install a few different composer based projects tonight to document how the handle a certain functionality. and it would be a good way testing this patch as well?

Please try simple testing, artifacts in https://github.com/ddev/ddev/pull/5058#issuecomment-1616077076 seem to have been updated properly. We'll see if it passes all automated tests also.

[ ] TestConfigSetValues is failing
[ ] @rpkoller points out that ddev composer create with no argument should be disallowed.

TestConfigSetValues fails because of the addition of typo3ConfigOverrideAction:
https://github.com/gilbertsoft/ddev/blob/fbd8b3e7045a13c6743ee0344a1f52da93b945d5/pkg/ddevapp/typo3.go#L168-L182

Fixed so you have to have exactly one arg to ddev composer create
Removed typo3ConfigOverrideAction. Maybe we'll find out why he did that now. Seems rather major that it wired the docroot.

There may be rare cases where plugins and scripts should be run, therefor the new flag --preserve-flags is introduced to fallback to the old behavior and not add these two options. But normally it should be fine to running scripts and plugins later with composer install.

It seems like you could add --no-install as part of the composer create-project call, and then run composer install afterwards. That should ensure that the end result is the same as running composer create-project with scripts allowed in most cases, without requiring users to run install separately.
This Pr is meant to resolve this problem:

Users do not know about the special behavior of ddev composer create and the differences to composer create-project

Users wouldn't normally need to run composer install after running composer create-project, so requiring that now will just change how that lack of knowledge trips people up rather than directly alleviating the problem.

I think @ultimike has generally proposed the create --no-install followed by install, it's simpler, easy to understand, and easy to debug.

@GuySartorelli Would you be willing to spend a little time with composer create here? It fails TestComposerCreateAutocomplete due to interplay between the intention here and your intentions. It would be much appreciated! If you see an obvious solution just push it into a branch and I'll cherry-pick it.

@GuySartorelli Would you be willing to spend a little time with composer create here? It fails TestComposerCreateAutocomplete due to interplay between the intention here and your intentions. It would be much appreciated! If you see an obvious solution just push it into a branch and I'll cherry-pick it.

This PR is reverting a change that I noted as necessary in my PR. See https://github.com/ddev/ddev/pull/5756#discussion_r1473974649
I haven't looked too closely at this PR or the discussion here, but a quick text search for the word "flag" doesn't come up with any discussion that indicates why this was being reverted. If reverting it isn't necessary, I'd recommend not reverting that change.

Thanks @GuySartorelli - I set it back to the way you had it, passes the test locally now. Will hope to get your full review on this once it's passing tests.
Note that this predated your work by 8 months, just got stalled although it got rave reviews. Hard to get something as stale as this in, but we're trying.

Yay, it finally passed tests and perhaps is resurrected. If all of you could review now it would be so fantastic.

Flag name
preserve-flags is a bit of a confusing name for the new flag, which (if I'm not mistaken) is really just a way to say "Don't add --no-scripts and --no-plugins". It seems like maybe this should be replaced with two scripts: --with-scripts and --with-plugins, so it's really clear what the flag does.
preserve-flags suggests to me "DDEV will ignore some of your flags, so you need to use --preserve-flags to have it respect them" which is obviously not the case.
Behavioural change
I still think don't really understand what this PR is solving - but based on some of the comments in here I still stand by my comments in https://github.com/ddev/ddev/pull/5058#issuecomment-1928594749 that it might make sense to have the composer create-project use --no-install, and then run a composer install in the project dir (with scripts and plugins allowed) afterward.
Utimately, the behaviour I'd expect of ddev composer create would be that it does exactly the same thing as if I ran composer create-project in an empty directory. If that wasn't true before, and this PR makes that true, then yay! If this PR moves in the opposite direction, that would seem concerning to me.

I still think don't really understand what this PR is solving - but based on some of the comments in here I still stand by my comments in https://github.com/ddev/ddev/pull/5058#issuecomment-1928594749 that it might make sense to have the composer create-project use --no-install, and then run a composer install in the project dir (with scripts and plugins allowed) afterward.

The composer create-project here does in fact use --no-install, then do a second pass with --install. Please give it a try and see what it does.

Utimately, the behaviour I'd expect of ddev composer create would be that it does exactly the same thing as if I ran composer create-project in an empty directory. If that wasn't true before, and this PR makes that true, then yay! If this PR moves in the opposite direction, that would seem concerning to me.

That's what @gilbertsoft was trying to accomplish here. (If it were in fact possible to run composer create-project in an empty directory, which it's not)
This is in fact a difficult journey, because it was @gilbertsoft 's initiative, and I was a little reluctant about it. However, @rpkoller has been very supportive, and the idea seems good. Maybe we'll be successful, maybe not.

Good point.  The flip side is that this will be out of sync with the quickstarts before it gets pulled, but we can survive that.
I sure hope there's nothing bad about this.
But we also need experience with this in the meantime, so it's a catch-22

People who are looking at the latest docs and using the stable DDEV won't be able to use the quickstart.
Out of curiosity, cuz i haven't considered that point as a potential problem yet, are there many people using the current stable version of DDEV with the latest version of the docs on ddev.readthedocs.io?  I wouldn't have expected that this is the case cuz, at least me myself tend to use the docs that come along or are on par with the version i currently use?

@rpkoller so often people use the latest version and get confused. I think we should figure out a better way to do this, and maybe have another branch for breaking-docs-changes.
Often we want to update the docs for current users. Sometimes (like here) we don't want to until they have it in their hands.
Most people don't know there are two versions, or know what the two versions mean.
Would love to have you think about this (in a new issue if we don't have one). We've talked about it many times.

I think we should figure out a better way to do this, and maybe have another branch for breaking-docs-changes.

Probably worth opening a discussion thread about this.

@GuySartorelli

https://github.com/orgs/ddev/discussions/5832

Rebased


RuleSetProvider: Error reading configuration file

Expected Behavior
Running ./gradlew detekt on detekt itself should not fail with exception.
Observed Behavior
Running ./gradlew detekt sometimes returns the following:
Ignoring listeners of task graph ready event, as this build (:detekt-gradle-plugin) has already executed work.
> Task :detekt-api:detekt FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':detekt-api:detekt'.
> io.gitlab.arturbosch.detekt.api.RuleSetProvider: Error reading configuration file

Stacktrace provides a bit of additional information:
Caused by: java.util.ServiceConfigurationError: io.gitlab.arturbosch.detekt.api.RuleSetProvider: Error reading configuration file
        at io.gitlab.arturbosch.detekt.core.RuleSetLocator.load(RuleSetLocator.kt:29)
        at io.gitlab.arturbosch.detekt.cli.config.DefaultPropertiesConfigValidator$validate$1.invoke(DefaultPropertiesConfigValidator.kt:20)
        at io.gitlab.arturbosch.detekt.cli.config.DefaultPropertiesConfigValidator.validate(DefaultPropertiesConfigValidator.kt:27)
        at io.gitlab.arturbosch.detekt.cli.config.ConfigValidatorsKt.checkConfiguration(ConfigValidators.kt:18)
        at io.gitlab.arturbosch.detekt.cli.runners.Runner.execute(Runner.kt:30)
        at io.gitlab.arturbosch.detekt.invoke.DefaultCliInvoker.invokeCli(DetektInvoker.kt:51)
        ... 93 more
Caused by: java.util.zip.ZipException: invalid distance too far back
        ... 99 more

Steps to Reproduce
I'm not sure it's reproducable 100% of times, but still:

Clone PR branch for #2410
Checkout it's parrent commit (4ea5873)
Run ./gradlew detekt (should work as expected)
Checkout PR branch
Run ./gradlew detekt`

Context
I'm trying to contribute to the project, and I'm unable to walk through steps of contribution guildelines.
Your Environment

Version of detekt used: 1.7.0-beta1 (master branch, ref 4ea5873)
Version of Gradle used (if applicable): 6.2.1
Operating System and version: Ubuntu 19.10
Java version just in case:

openjdk version "1.8.0_242"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.242-b08, mixed mode)

Does this also occur with a state before the mentioned commit 4ea5873 ?

Yes, that's exactly what happened. I've rebased my branch onto fresh master from several commits earlier. That explains why I was able to see detekt results earlier and then started to get the error. Didn't try stopping the daemon. After reboot it's working again, so that's most probably it.

@r4zzz4k thanks for the insights.
I will close this for now.


Changes to Model ID and Manufacture have no effect

I am hoping to add multiple PTVO devices to my Z2M/HA system, each configured differently (using a different external converter file).
That requires each to have a different Model ID (representing the IO configuration).
I have tried changing it in the Firmware Configuration tool:

However when added to Zigbee2MQTT (in Home Assistant), the Manufacturer and Model ID always come up as the default:

I have tried reading back the settings from the firmware file (which verifies the modified config is there), as well as removing the device from Z2M (and restarting both Z2M and Home Assistant), then repairing. No matter what I try, the devices always identify as ptvo.switch.
I believe this could be a bug in the Firmware Configuration tool?
Many thanks for any investigation you can do.

After some more investigation, it seems that this may have something to do with a previous External Converter file within Home Assistant somehow modifying the Model ID to the previous value. I'm still working on getting to the bottom of it, but it appears less likely to be a firmware issue!

You should delete device in Z2M, restart Z2M and rejoin your device again. Z2M should display the new ModelId.


Update rules_python to 0.28.0

for WORKSPACE dependencies. MODULE.bazel already uses this version.

All the jobs seem to be mistakenly showing as queued, where in fact they have run successfully (I can see it in the Actions tab). Merging the PR.


Special C2 Headquarters Modifier Inconsistency in Standard/Display for Land and Sea Units

The Special C2 Headquarter Text Modifier attribute/field "AA" is only shown in 2525D (May 2014) "APPENDIX E - SEA SURFACE SYMBOLS" Symbol Figure ("FIGURE E-2") but is not shown in the accompanying table (TABLE E-II).
However, this same modifier is not shown APPENDIX D - LAND SYMBOLS, in FIGURE D-3 (where it likely should be shown), but it is shown in the accompanying table, TABLE D-II.
More importantly, because there is no valid symbol with just a frame and no central icon, there is no way to currently display this "AA" text in the icon center of a valid symbol.
Suggested corrective action is:

Add Special C2 Headquarter Field "AA" to FIGURE D-3

Add Special C2 Headquarter Field "AA" to TABLE E-II

If not already done, add symbol with just empty frame to symbol sets (Note: 2525C did have a "Special C2 Headquarters" symbol, but it appears to have been retired at 2525D )
a. Note: I see where this Change Request, 15-036-DS, was possibly already approved here https://github.com/Esri/joint-military-symbology-xml/issues/192 , but I don't see any Unspecified/"000000" entries in the repo data

I'm not sure if this modifier/text is used in symbols sets other than land/sea, but I noticed this issue while trying to create a set of symbols similar to:

I will author a CP making sure that the standard is consistent regarding this AA amplifier for 2525D Change 1.

@csmoore @abouffard already brought this to the committee and they are aware. The CP will pass.

https://app.asana.com/0/22998302507476/43808146567937

CP 15-036-DS has now been implemented in JMSML (#209) and once these changes are reflected in updated domain ranges in military features data feature classes, special C2 HQ symbols can be created.
We are waiting to receive all approved 2525D Change 1 CPs from DISA.  Once received, I will review them to determine if a CP was already approved to add the AA amplifier code to the diagrams and tables in the standard.  That information will then determine what we do next regarding drafting a new CP.

@csmoore , please confirm fix and close.

Verified the "unspecified" entries in symbolset domains, @abouffard - did you want me to close this issue or are you using this issue to also track the administrative updates to those text modifier figures/tables in the standard?

Don't close it yet.  I'll draft a CP we can track then I'll close this.

It was determined by the SSMC that this does not require a CP and any corrections to the standard to address the issue described herein can be handled by an administrative change.  I will work with @mepler to identify any administrative changes that need to be made.  Closing on the basis that no CP will be written for this.  DISA is aware that this needs to be looked at from an administrative standpoint.

Closing this is fine-as long as it is being tracked to closure somewhere with the other admin issues. Also, if this is a valid field, please add to the missing database fields at https://github.com/Esri/military-features-data/issues/141


Backend: Habitable Planet % Funtion

This is the 30% "chance" that planet will be counted as habitable. Will make habitable planet counter in dashboard go up by one.

Closing issue since we changed habitability to a Boolean


issue killing subprocesses using cd with failure at startup

Hello,
I've run into an interesting problem, and reduced to it what I think is a minimal case. I have the following Procfile (note this requires python 3.x to run):
server: cd inner && python -m http.server 8000
failure: sleep 1 && false

Running foreman start in a directory with an inner subdirectory (so the cd doesn't fail), I get:
% foreman start
10:20:30 server.1  | started with pid 15205
10:20:30 failure.1 | started with pid 15206
10:20:32 failure.1 | exited with code 1
10:20:32 system    | sending SIGTERM to all processes
10:20:32 server.1  | terminated by SIGTERM

However, the server is still running:
% lsof -i tcp:8000
COMMAND     PID     USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
python3.7 15207 mikeyhoy    3u  IPv4 0xe5175633836f0ad9      0t0  TCP *:irdmi (LISTEN)

If I remove the cd inner && from the server child command, it works as expected, the subprocess getting terminated. Even more interestingly, if I remove the failure child, and exit foreman normally with Control-C, it correctly kills the subprocess. So it only seems to happen if another child process fails at startup.
Any ideas on what's going on?
Thanks.
EDIT: I'm using the current version,
% foreman --version
0.87.1

Maybe due to https://github.com/ddollar/foreman/issues/779? That issue has been addressed in overman, a foreman fork, see https://github.com/ddollar/foreman/pull/780#issuecomment-1294980165


OperationId is not defined for post

when i use cmd openapi-python-generator, get an exception:
/python3.8/site-packages/openapi_python_generator/language_converters/python/service_generator.py", line 158, in generate_operation_id
raise Exception(f"OperationId is not defined for {http_op}")  # pragma: no cover
Exception: OperationId is not defined for post
here is the openapi json file:

Please provide an openapi.json file that i can use to test this.

{   "openapi": "3.0.1",   "info": {     "title": "searchword",     "description": "",     "version": "1.0.0"   },   "tags": [],   "paths": {     "/apipath/login": {       "post": {         "summary": "login接口",         "x-apifox-folder": "",         "x-apifox-status": "developing",         "deprecated": false,         "description": "",         "tags": [],         "parameters": [           {             "name": "username",             "in": "query",             "description": "",             "required": true,             "example": "{{username}}",             "schema": {               "type": "string"             }           },           {             "name": "passwd",             "in": "query",             "description": "",             "required": true,             "example": "{{passwd}}",             "schema": {               "type": "string"             }           }         ]       }     }   } }

this file is generated by Apifox which is an api toolkit.

This is not a valid Openapi document. Every operation usable for the generator must have such an operation id, as it is used to generate naming. For more information, see here:
https://swagger.io/docs/specification/paths-and-operations/
especially the section on operationId
I added a custom exception that will identify this issue better.


Kill Roblox fuction for Bloxtrap Menu

Can you add a "Kill Roblox" option to the Bloxtrap menu incase if someone ever experience situations where the Roblox application would become unresponsive or begins to malfunction, if these situations ever happen people could just go to the Bloxtrap menu and terminate the running Roblox Processes

Task Manager


MNT: Do not directly import pyepics anywhere but control_layer

✔ ~/source/bnl/ophyd [master {NSLS-II/master}|✚ 17…3⚑ 2]
13:39 $ git grep 'from epics\>'
ophyd/epics_compat.py:from epics import get_pv as _get_pv, caget, PV, caget, caput
✔ ~/source/bnl/ophyd [api_support_multiple_epics_libraries L|…2⚑ 2]
13:45 $ git grep 'import epics\>'
.travis.yml:  - python -c "import epics; print(epics.__version__)"
.travis.yml:  - python -c "import epics.ca; print(epics.ca.find_libca())"
.travis.yml:  - python -c "import epics; print(epics.caget('XF:31IDA-OP{Tbl-Ax:X1}Mtr'))"
ophyd/epics_compat.py:import epics
ophyd/epics_compat.py:    import epics
ophyd/epics_compat.py:    import epics
✔ ~/source/bnl/ophyd [api_support_multiple_epics_libraries L|…2⚑ 2]
13:45 $

Codecov Report

Merging #463 into master will increase coverage by 0.01%.
The diff coverage is 73.79%.

@@            Coverage Diff             @@
##           master     #463      +/-   ##
==========================================
+ Coverage    91.2%   91.22%   +0.01%
==========================================
  Files          48       49       +1
  Lines        6984     6952      -32
==========================================
- Hits         6370     6342      -28
+ Misses        614      610       -4

Impacted Files
Coverage Δ

ophyd/tests/test_positioner.py
100% <ø> (ø)
:arrow_up:

ophyd/tests/test_mca.py
100% <ø> (ø)
:arrow_up:

ophyd/tests/test_ophydobj.py
100% <ø> (ø)
:arrow_up:

ophyd/tests/test_pseudopos.py
100% <ø> (+0.76%)
:arrow_up:

ophyd/tests/test_scaler.py
100% <ø> (ø)
:arrow_up:

ophyd/tests/test_areadetector.py
97.51% <ø> (-0.04%)
:arrow_down:

ophyd/tests/test_signalpositioner.py
100% <ø> (ø)
:arrow_up:

ophyd/tests/__init__.py
100% <ø> (+23.8%)
:arrow_up:

ophyd/tests/test_timestamps.py
100% <ø> (ø)
:arrow_up:

ophyd/areadetector/plugins.py
92.23% <0%> (-0.23%)
:arrow_down:

... and 12 more

Continue to review full report at Codecov.

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

@teddyrendahl @ZLLentz @hhslepicka @klauer @prjemian   This is a pretty major re-organization of imports.
The idea is to push all of the imports into _LIB_shim.py which are imported into epic_compat.py which is what is actually used by the code.  This should allow ophyd to switch between pyepics, caproto, pyca,etc assuming the library can provide a small handful of functions and a PV class that duck-types to the pyepics PV class.
We could probably get the required list down to {get_pv, threading_class, setup} if we tried.

@stuartcampbell done

This is exciting! @ZLLentz Any interest in adding a PyCA compat layer?

@danielballan I'll write a pyca compat layer at some point, but it's not super high on the list of priorities right now. I'm glad that the option is available in case I find a pressing need to switch. To be fully open, I'm much more excited by the prospects of a future caproto than by the prospects of revisiting pyca.


Add okhttp-4.x plugin

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

@kezhenxu94 @EvanLjp Please check on codes. The tests seem good.

LGTM. And the tests seems passed.


refactor content index store clear / data format

Switched back to using IndexedStorePath as value in content-index cache, and switch to use of ISPN Query API when clearing index entries for a store (on store deletion). This avoids iterating all keys in the content index (which can have millions of entries) and the horrible memory profiles that implies.

retest this please


New to flutter

Hey there I am new to flutter so would help to include in the README how to run the different examples/widgets.

Hey @imthaghost,
you only need to update your main.dart page.
void main() => runApp(
  MaterialApp(
    debugShowCheckedModeBanner: false,
    home: RegisterWithPhoneNumber(), // change this line to, like: LoginExample()
  )
);


Crash when attempting to install singer

Acknowledgement

[X] I have read Getting-Started and FAQ

🐛 Describe the bug
https://github.com/user-attachments/assets/f2297945-89a1-435c-a0d1-3e0c322bd8c2
Kernel Version: 6.12.1-273-tkg-eevdf-llvm (64-bit)
Graphics Platform: Wayland
Graphics Processor: Mesa Intel® HD Graphics 530
Interestingly, nothing happens when navigating to empty/ no archive containing directory.
When navigating to a directory containing an archive, the XDG Portal window closes, with no state (seemingly) changed in the application.
Explains how to reproduce the bug

Install OpenUtau from aur package openutau-bin
Open application
Tools > Install singer
Navigate to directory containing compressed file

OS & Version
Arch Linux
Logs
ALSA lib pcm_direct.c:2178:(_snd_pcm_direct_new) unable to create IPC semaphore
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2722:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:878:(find_matching_chmap) Found no matching channel map
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
ALSA lib pcm_oss.c:404:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_oss.c:404:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_a52.c:1036:(_snd_pcm_a52_open) a52 is only for playback
ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card
ALSA lib pcm_usb_stream.c:481:(_snd_pcm_usb_stream_open) Invalid card 'card'
ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card
ALSA lib pcm_usb_stream.c:481:(_snd_pcm_usb_stream_open) Invalid card 'card'
ALSA lib pcm_direct.c:2178:(_snd_pcm_direct_new) unable to create IPC semaphore
ALSA lib pcm_direct.c:2178:(_snd_pcm_direct_new) unable to create IPC semaphore

Just tested this, it seems to work under different xdg portals or with different permissions: specifically i ran it as root and it worked normally.

It's not about permissions. This is COSMIC importing the file correctly

Can't replicate on this machine.


Repo sync for protected CLA branch

The pull request is created from main637866111116218032 to main to fix git push error for protected CLA branch

@ghogen : Thanks for your contribution! The author(s) have been notified to review your proposed change.


"Unrecognized command line argument" when use "sudo -E" in Max OS X

I would like to add to this that the same error occurs under Ubuntu 15.
Calling gvm from anything but the command line seems to make the use keyword unusable.
Example code:
$bash -c "gvm use go1.5.3"
ERROR: Unrecognized command line argument. 'use'
$gvm use go1.5.3
Now using version go1.5.3

Workaround: Make a link from .gvm/scripts/env/use to .gvm/script/use
ln -s .gvm/scripts/env/use $.gvm/script/use

@eyecikjou567 it does not work for me on centos 6.5


When installing dart sdk on linux via the deb repo, not all commands have /usr/bin links created for them

Followed instructions here:
https://www.dartlang.org/downloads/linux.html
But only /usr/bin/dart is linked to /usr/lib/dart/bin/dart
dart2js, etc, and not linked.

CC @sgjesse

This issue seems to be a duplicate of #19926.


adds dma/backdoor for infinite memory configuration

you already have to do that...

You do?
We should fix that then. I didn't realize that was an implication of an earlier PR.

As we discussed this morning, and as solved in #524, it's annoying to run make clean when switching between machines. The runtime library should be smart enough to know when certain features aren't available (granted, in cosimulation only)
It seems like a solution would be to add bits in the rom for certain DMA features. Is my sense correct?

It seems reasonable - although proper makefile dependency listing would defect solve the problem we discussed this morning.

merge?


Move deployments in Maven Central from io.flagsmith -> com.flagsmith

This will involve following the migration steps for the java client as documented here and then repointing the build job to com.flagsmith here.

Linked to https://github.com/Flagsmith/flagsmith-java-client/issues/88


Disable/enable per project to avoid clashing with other linters

As per this discussion https://github.com/atom-community/linter/issues/682 I'm having some major headaches switching between projects where some use standard and others use eslint, jshint etc.
While linter-eslint, linter-jshint and linter-jscs have settings to enable the linters only when they encounter their respect .rc files. Standard doesn't have any .rc file so how do we solve this?
I would love a universal standard for setting a preferred linter for JS project, in e.g. package.json (think a "lint" key) or equivalent. That's perhaps a bit ambitious in the short run, so in the short run, I'd propose the following:
An atom setting named ~enableOnlyOnPackageKey where, if true, the linter should only be enabled if there's a "standard" key found in package.json (no matter it's content). It should default to false. Other ideas?

You should already be able to do this. There is an option Check for standard which defaults to false.
See here.

Ah, perfect. Thanks a lot :+1:


Refined language about example application

Have you looked over the sample application? I would love to know if there you have any suggestions or critiques about how it's built. Thanks for including it in the Readme!

Thanks! All language refinements are welcome :)
I noticed your project structure is quite the same as mine. The only difference I have my API and its dependencies under /app/api/. Since my application is quite large already.
I've got some tips about building API's, but these are all refinements. They don't have to be included in this sample but its good to know about them. I am currently writing an article about which i'm going to publish about next week. Its about defining entities and using presenters and decorators.


#97 Trouble 'upgrading' project from PTVS 2.1 to 2.2 RC

Changes project factory to return empty GUIDs by default to avoid circular references.

:+1:


Checklist for submitting formal review

Here is a checklist of things to complete before submitting a formal review. An abridged version from info on this site:
https://mne.tools/stable/install/contributing.html#mne-python-coding-conventions

[ ] Test coverage for new functionality (test output of boxy.py and compare to another source, such as p_pod)

[ ] Document new functionality (thorough docstring explanations and tutorials explaining functionality)

[x] Avoid public API changes if possible (don't think we've made any such changes... Just added our own functions)

[x] Add deprecation warnings if removing/changing functionality (again, don't think this applies to us)

[ ] Describes changes in the changelog, "doc/whats_new.rst" (sounds like this should be done AFTER the PR is finalised)

[ ] Test locally before opening PR (kind of did both, tested locally and using CI tests)

[ ] Make tests fast and thorough (currently tests compare raw, epoch, evoke to p_pod. Anything else? Need to make smaller data files for such tests)

[x] adhere to pep8 (currently seems fine, but can check by running "make flake")

[ ] Use consistent variable names (should make sure variable names make sense too)

[x] follow NumPy style for docstrings (again, should be fine now but can be checked by running "make docstyle")

[ ] Docstrings and documentation pages should cross-reference mentioned classes, functions, etc. (can probably use the "plot_70" tutorial as an example)

[x] Use single quotes where possible

[x] Prefer generators or comprehensives over filter() and map() (need to check into this...)

[x] Use explicit functional constructors (eg. list(), dict(), set())

[x] Avoid nested functions or class methods if possible

[x] Avoid *args and **kwargs in function/method signatures

[x] Import in this order (python built-in > standard scientific (eg. numpy, scipy) > others > MNE imports)

[x] Methods should modify in-place and return self

[x] Functions should return copies, where applicable

[x] Docstrings should contain informative names for return values, even if that particular name isn't used

[x] Visualisation capabilities should be available in method and function form

thanks for getting this together, glad we have already done most, I think we are almost there

Yeah I think we're getting close. Helps that a lot of the checklist doesn't really apply to us since we're basing the code on what's already in mne.

I made a PR to address the list: https://github.com/kylemath/mne-python/pull/25


i meet bollow error todaycan you help me

library(INLA)
n <- 10
locations <- data.frame(x = runif(n), y = runif(n))
values <- rnorm(n)
w <- matrix(0, n, n)
for (i in 1:n) {
for (j in 1:n) {
dist <- sqrt((locations$x[i] - locations$x[j])^2 + (locations$y[i] - locations$y[j])^2)
if (dist < 0.2) {
w[i, j] <- 1
}
}
}
formula <- values ~1+f(1,model = "bym",graph =  w)
undebug(INLA:::inla.interpret.formula)
result <- inla(formula, data = locations, family = "gaussian")
print(result)

is my model have wrong?think you!

Your component specification is wrong. You likely need this:
library(INLA)
n <- 10
locations <- data.frame(index = seq_len(n), x = runif(n), y = runif(n))
values <- rnorm(n)
w <- matrix(0, n, n)
for (i in 1:n) {
for (j in 1:n) {
dist <- sqrt((locations$x[i] - locations$x[j])^2 + (locations$y[i] - locations$y[j])^2)
if (dist < 0.2) {
w[i, j] <- 1
}
}
}

formula <- values ~1+f(index,model = "bym",graph = w)
result <- inla(formula, data = locations, family = "gaussian")
print(result)

@finnlindgren ,it work,thank you.but i find other problem,my data does't fit gaussian,so i chose poisson,
library(INLA)
set.seed(123)
n <- 100
lambda <- 3
y <- rpois(n, lambda)
data <- data.frame(y = y)
formula <- y ~ 1
result <- inla(formula, data = data, family = "poisson",
control.family = list(hyper = list(prec = list(prior = "gamma", param = c(1, 0.1)))))
i meet those error,the ,
control.family = list(hyper = list(prec = list(prior = "gamma", param = c(1, 0.1))))is shoud be deleted?thank you.i just want set a hyper
Error in inla.core.safe(formula = formula, family = family, contrasts = contrasts,  :
Model poisson [ likelihood ], has none hyperparameters, but 'hyper' is  list(prec = list(prior = "gamma", param = c(0.5, 0.1)))


issues after install

HI,
after install Arrayy via composer:

How to fix it? tks

maybe you have installed it with composer + php >= 7.0 but running the code the php < 7.0?
PS: here you can see that the code is working on php >= 7.0 -> https://3v4l.org/bS7Ah

Oh, yes!
my code is php version 5.6, but library Arrayy this not working php version be lower 7.x ?

"A PHP array manipulation library. Compatible with PHP 7+"
The code update from PHP 5 to PHP 7 should not be very hard, there are not that may BREAKING CHANGES (BC) -> https://www.php.net/manual/en/migration70.incompatible.php
And I would recommend to use a even more up-to-date version of php, because PHP 7.0 is already END OF LIFE (EOF) -> https://www.php.net/supported-versions.php


Add Astro setup page

Subject
Astro
Description
We want to create a Yamada UI setup page using Astro.
Try Astro.
Are you willing to participate in creating this documentation page and create a pull request?
Yes

I try it.

Closed due to lack of demand.


[DO NOT MERGE - yet] Use ava

Codecov Report

Merging #97 into master will decrease coverage by 1.49%.
The diff coverage is 84.18%.

@@            Coverage Diff            @@
##           master      #97     +/-   ##
=========================================
- Coverage   75.65%   74.16%   -1.5%
=========================================
  Files          47       69     +22
  Lines        1828     2249    +421
  Branches      253        0    -253
=========================================
+ Hits         1383     1668    +285
- Misses        445      581    +136

Impacted Files
Coverage Δ

5-logging/lib/images.js
45.45% <ø> (-4.55%)
:arrow_down:

6-pubsub/lib/background.js
87.5% <ø> (-1.64%)
:arrow_down:

3-binary-data/lib/images.js
45.45% <ø> (-4.55%)
:arrow_down:

4-auth/config.js
94.11% <ø> (-0.33%)
:arrow_down:

7-gce/lib/oauth2.js
34.28% <ø> (-63.09%)
:arrow_down:

7-gce/config.js
94.11% <ø> (-0.33%)
:arrow_down:

6-pubsub/lib/images.js
54.54% <ø> (-3.79%)
:arrow_down:

optional-container-engine/config.js
58.82% <ø> (ø)

4-auth/lib/oauth2.js
97.14% <ø> (-0.23%)
:arrow_down:

6-pubsub/config.js
94.11% <ø> (-0.33%)
:arrow_down:

... and 109 more

Continue to review full report at Codecov.

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


Add support for computed class property names (#120)

First time contributor here - someone please check this for sanity :smile:
I think this implements #120 quite completely. I'm working on a PR for the corresponding changes required in Babel, tracked by babel/babel#4499.

The CI failures (on Node 5 only, out of the whole build matrix) appear to be unrelated to the PR's content. (Right?)

Thanks for contributing.
This looks good, the only thing that I'm worried about this is how the ambiguous cases are handled. For example this class:
class Bar {
   [x] = blub
   ['y'];
}

Does it contain two or one properties? I would assume one with a value of blub['y']. But I'm not sure what the spec says about this if it does.
What would your changes produce for this example?

Current coverage is 94.03% (diff: 100%)

No coverage report found for master at 015035c.

Powered by Codecov. Last update 015035c...f09ab3f

My immediate answer is that ASI applies like everywhere else (and there are existing tests for literal-named properties reflecting this). Doing a little bit of research and will follow up soon.

I found this
https://github.com/tc39/proposal-class-public-fields/issues/25
Not sure what the current status is, but semicolons might be required in the case i posted.

There's some existing tests, which cover the ASI rules in this case for computed methods.

Good catch.

There's also tc39/proposal-class-public-fields/pull/45 (an open PR at the moment) which suggests the semicolon is not in the spec, but IMHO it's safe to assume it will be (given past discussions and the nontrivial ambiguity otherwise).

@danez your class Bar parses as having one property.

Yeah ref https://github.com/babel/babel/pull/3332

Looks fine to me? We made semicolons necessary before but it was reverted

The tests like right to me

@jeffmo what will the spec say about this case? Or is it not yet decided?
class Bar {
   [x] = foo
   ['y'];
}

@danez: Grammatically, that would be the same as:
class Bar {
  [x] = foo['y'];
}

This is just the practical fallout of supporting ASI in the language unfortunately.


Forces count seems to have issues with "count forces above 100%" feature

@Aeon234 Hey, seems like the feature we merged did break something after all.
I've had bug reports that the forces are no longer counted, e.g.:

Since this happened right after the release and that's the exact part of the codebase that was touched, it's very probable that it was the cause. The old version is still up (2.8.0), but I've reverted the changes and pushed a patch version (2.8.1).
Before we re-merge anything, could you do some more testing, especially with users of the addon that weren't part of the development/testing before? I previously used to give out beta versions to my M+ team, but as I mentioned, since I'm not playing at the moment (and neither are they) I can't help with that.

I'll take a look and have my mplus team + guildies take it for a test drive. I even ran keys on 2.8.0 and everything was working fine. I'll report back with what I find

Just a status update.
Had both my own mythic plus team and my raid team test it out. combined about 10 ppl tested it and for all of them it worked without a problem. Be it showing forces up to 100% or over 100%.
I did find a small bug in some occasions so we fixed that up and now having everyone re-test to make sure that both it works and the bug is fixed. Will report back tomorrow after everyone runs some keys.

@happenslol
Hey, sorry for the long delay. Fixing the bug got put on a hold for a bit since I got busy with work and his m+ group had to pause while a member was moving. They're back to running keys now though.
However, we've finally finished fixing up the bug that was happening with counting. It'd always go over 100%, but in some instances it would calculate wrong. I figured out it was due to the add-on sometimes running OnCombatLogEvent first, other times running UpdateForces first. I changed it so regardless of the order, it should count correctly. @Aeon234 has been running keys for the past week and it hasn't failed or bugged yet. He's handed the new version to his m+ group and they're going to run keys over the next week or so. If it looks all good, we'll make another PR.
Also, neither Aeon nor his m+ group has ever once run into an instance of it not counting trash % entirely. Not sure what the issue was with the user in your screenshot.

Seems I owe you an apology then. The timing of the comment I got was right when the new version was published, so the connection seemed obvious to me, but it must've been a fluke.
Thanks for testing it so thoroughly. I'm happy to merge the feature again if you open another PR!

@happenslol Hello! Sorry for the long delay again. I'm pretty sure it's working. Aeon has run keys for the past 3-4 weeks without any count going off. However, he hasn't run enough for me to want to make a PR. I'd wager only maybe in the ball park of 20ish keys (however he did give his m+ buddies the current version after 5 keys or so - so that's maybe 15 keys of them all using it and not failing for a single person). Still, I want him to do more before we actually make a PR and merge in something that has a bug.
Hopefully that'll happen in the next 2-3 weeks depending on whenever he runs more keys to test every scenario, but it looks good so far.
It hasn't failed yet when:

unclampforcespercent is enabled with MDT installed
unclampforcespercent is enabled without MDT installed
unclampforces disabled

Will make a PR whenever I feel it's tested robustly enough. Thanks for patience.

Hey, what's the status on this? I've rewritten a lot of the counting logic with the changes introduced in TWW in 4.0, so the code for this will probably need to be ported. I'd be happy to help with that, but if no one is working on this anymore I'd like to close out the issue or at least mark it as a feature request that's open to contributions.

Sorry for the late response and silence! Aeon actually took a break from M+ before TWW launch, so we paused testing then. Then, I redid some of the logic of the count at the start of TWW to make it cleaner. Got it to a complete state after on/off testing a month or so back, and Aeon has been testing it/giving it to his guild to test as well. It was working fine for 3-4 weeks for everybody, then he ran into an instance where the count didn't tick for the very last mob earlier this week. So I've been investigating that, but have been getting busy with work.
Feel free to push up all of the new rewritten counting logic and I'll refactor it to fit the new code.

oh, I'm dumb. I saw you pushed it up already, haha. I'll work on refactoring it.


kit-info incorrect with the new "release" setting

With the new value of release in /etc/ego.conf in [global] section the output of kits is not correct.

/etc/ego.conf:
*****************
[global]
release = 1.2

this is ready to be merged, IMHO


Different config grouping

Problem

Too complex configs structure. Hard to understand for beginner.
Hard to check all configs that are becoming a certain group, i.e. what will be used when loading web in index.php.

Idea
The idea is that files are placed differently when copied from packages to application.
For example, the following is in the maker and doer packages:
config
  common.php - common group in composer.json
  web.php - web group in composer.json
  params.php - params group in composer.json

will be copied to app as:
config
  common
    `maker-common.php`
    `doer-common.php`
  web
    `maker-web.php`
    `doer-web.php`
  params
    `maker-params.php`
    `doer-params.php`

Result

Easy to get an idea what configs form a group.
Likely lesss scary for beginners.
It is now harder to get an idea what configs a certain package provided (do we need it?)
Configs in the pacakge aren't grouped the same way.
In this approach app configs could be also moved to groups i.e. config/web/app.php. This way there will be a single "standard" way to place configs for both app and packages.

Tried that. Doesn't work well.


Fix indentation to link content to the list items

This fixes the indentation of the content within the lists to make sure that
code and images are properly part of the list item. This also fixes the file
extensions so that the (case-sensitive) preview on GitHub can find the files.

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

Thanks for your contribution!
@billmath Please confirm these changes and let me know when to merge the pull request. Thanks!

Somewhat funny to see that some of the uploaded image files are a mix of uppercase and lowercase, while some of the img links in the document have been added with the opposite mix.

#sign-off

@illfated Yeah, I was really confused about that odd mix of upper and lower case extensions too. I was considering changing them to be consistent as well but that wouldn’t have worked from within the GitHub editor.
I can still do that if you would want that.

@poke : No worries. I have tried creating a pull request for that earlier, but it got downvoted by one of the MS Docs team managers. I think the repository contains too many occurrences of opposite case between file name extension and the link contents, so it may create more trouble than productive results. Thanks for the suggestion, though.

#sign-off


Swapchain panics with UnsupportedDimensions given min_image_extent

Info

Version of vulkano: 0.11.1
OS: Windows 10
GPU (the selected PhysicalDevice): GTX 1080
GPU Driver: Nvidia v/ 417.22

Issue
let caps = surface.capabilities()?;
swapchain.recreate_with_dimensions(caps.min_image_extent)?;

The above code panics with UnsupportedDimensions. min_image_extent is [0, 0]. I'm not sure if caps reports the wrong min_image_extent or what is wrong but this seems like a bug to me. Though I am unable to test it on another computer or gpu.

@TurboCartPig My impression is that the swapchain dimensions have to match their surface and that the min and max extent just describe what the bounds are (I could be totally wrong on this). Is it possible for you to resize the surface (or associated window) to min_image_extent and then then recreate the swapchain using caps.current_extent?
Or maybe you mean to be using caps.current_extent anyway?

On some platforms the swapchain can be any size i.e. caps.min_image_extent would work.
However that is certainly not cross platform, as some platforms (those that specify a currentExtent) need the swapchain size to equal currentExtent which will always be the window size anyway, so just set the swapchain to the window size everytime and it will be fine.
Please refer to the triangle example for window recreation https://github.com/vulkano-rs/vulkano/blob/1d83993e844e84792737f6e0c2a3819e3912e844/examples/src/bin/triangle.rs#L333
and also this comment for initial window creation is very useful https://github.com/vulkano-rs/vulkano/blob/1d83993e844e84792737f6e0c2a3819e3912e844/examples/src/bin/triangle.rs#L146

My code looks something like this at the moment
let dimensions = {
            let caps = self
                .surface
                .capabilities(self.device.physical_device())?;

            let current_extent = caps.current_extent.unwrap_or(caps.min_image_extent);

            if current_extent < caps.min_image_extent {
                caps.min_image_extent
            } else if current_extent > caps.max_image_extent {
                caps.max_image_extent
            } else {
                current_extent
            }
        };

        let (new_swapchain, new_images) = self.swapchain.recreate_with_dimension(dimensions)?;

So my swapchain dimensions should match the surface dimensions. The problem is that when I minimize the window, the current extent becomes [0, 0], same as min_image_extent, Causing a panic.
So should I pass some arbitrary minimum dimensions. That works as far as I have tested. But how would I know that those dimensions will be supported. I thought that was min_image_extent was for.

My solution is to stop rendering when the window is minimized. i.e. when we get a dimension of (0, 0)

That seems reasonable. I will close the issue then as this does not seem to have anything to do with vulkano.


Feature/slack login

Currently users have to add the slackbot to their channel to sign in - so unless had admin rights to their slack channel they can't sign into the app.
This PR allows the users to Sign In OR Add Bot to Channel.
It also customises the slackbot welcome message for new vs existing teams.

ping @edenspiekermann/backend


Improvements to probes, Kubelet initialized

Does this PR introduce a user-facing change?:
NONE

/assign @kron4eg

/retest