text:
ci: build and deploy with GitHub Actions

related to INFRA-1258

@ThorbenLindhauer (tagging you as the main contributor): as you can see, we're moving from building the community projects on GitHub actions instead of "our" Jenkins.
We made this move to improve transparency as well as provide better feedback for contributors.
I'm going to leave this note in all affected repositories once we're done making the changes.
If you experience issues related to our changes to GitHub Actions, please let us know!

repo: camunda/camunda-dmn-xlsx


text:
Properties panel is empty for all DMN connections

Describe the Bug
I can't view or change the connections' properties in the DMN table.
Steps to Reproduce

Create a connection in a DMN tab
Select connection

Expected Behavior
At least the ID is visible.
Environment

OS: MacOS 10.14
Camunda Modeler Version: 3.4.1, 3.5.0

Is this a regression? Did it work in v3.4.x?

Same in 3.4.1.

Thanks.

In some places this is intentional behavior. In DMN 1.1 a lot of connections do not contain IDs. This changes with DMN 1.2 / 1.3.

I believe this is intentional behavior.
In DMN 1.1 a lot of connections do not contain IDs. Actually they do not contain anything editable. This changes with DMN 1.2 / 1.3.

Right, the requirements don't have ID in the XML too.

Fixed via https://github.com/camunda/camunda-modeler/pull/1688

source: gharchive/issue

authors: barmac nikku

repo: camunda/camunda-modeler

license: MIT

license_type: permissive

license_source: github-api


text:
feat(startProcessInstance): add the text field to set up variables when starting a new process instance

This is a Camunda Platform part of #2437. There will be the Camunda Cloud/Zeebe part of #2437.
I decided to move all logic to the StartInstanceTool right before calling Camunda REST API. I'm not sure about it 🤷🏻♂.

Note that machine-generated error is not super helpful:

UX review:

Variables are optional. This should be clear by adding the information to the label: Variables (optional)
We cannot add example data as value. This would lead to the unintended creation of a variable or would force the user to manually delete it each time when starting an instance. Better: put the example outside of the field and let the field empty.
If we have a textarea component, we should use it here. A single-line text input might be insufficient.

Please consider these changes.
As inspiration, this is the solution in Camunda Cloud:

Link target in screenshot: Variables

Note that machine-generated error is not super helpful:

As the first iteration of this topic, I believe a JSON validation that just returns just true/false is okay.

@aivinog1 Are you willing to implement the suggestion left by @andreasgeier? If so, please let us know. Otherwise, we will probably close this PR but you can get back to it when you have time.

Cool, then I keep it open :)

@aivinog1 will you continue to work on this or shall I close this PR?

@MaxTru Please, do not close this, I'll look at it on 16th October 🙂

@MaxTru Please, do not close this, I'll look at it on 16th October slightly_smiling_face

Sure - will leave it open. I assume you mean November 16? :-)

Hey @MaxTru @barmac @andreasgeier! Finally, I've found time to look at this. Can you check this out, please? :)

I have two comments:

For me this still does not work, it complains that even simple strings are not valid JSONs. Do I miss something:?

The UI looks a bit broken (see Screenshot above). @andreasgeier maybe you can advice?

For me this still does not work, it complains that even simple strings are not valid JSONs. Do I miss something:?
JSON uses double quotes. So it should be{"a":"b"} in your example.

For me this still does not work, it complains that even simple strings are not valid JSONs. Do I miss something:?

JSON uses double quotes. So it should be{"a":"b"} in your example.

Ups. Yeah indeed it works that way.
Implementation wise this looks good! Thanks for this contribution.
I think the UI needs some cleanup:

The PR breaks the UI of "deploy" => there is now a horizontal scroll bar?

This looks broken. @andreasgeier maybe you can advice?

@aivinog1
Cool to see your progress! Feedback from product design:

avoid breaking the layout of the dialog (horizontal scrollbar)
avoid bold text and links within labels

Suggestion:
[Label:] Variables (optional)
[Textarea in full width]
[Description:] Must be a proper JSON object. Learn more about variables.

Hey @MaxTru @andreasgeier! I've fixed all your review comments, can you check this out, please? :)

@andreasgeier Screencast for you

Looks good!
Some minor things:

Could you please fix the linting errors? (e.g. run npm run lint)
Could we please give the textArea a min and max width to avoid something like this:

The link provided by @andreasgeier pointed to the Cloud docs, but we should use Platform docs here. I suggest to use: https://docs.camunda.org/manual/latest/reference/rest/process-definition/post-start-process-instance/#request.
@andreasgeier I think the description should be more explicit to educate the user that it needs to be a JSON object according to the structure described in the docs. So what about.

[Description:] Must be a proper JSON variables object. [Learn more and find an example for variables](https://docs.camunda.org/manual/latest/reference/rest/process-definition/post-start-process-instance/#request).

By the way @aivinog1 => this really looks great already. If you want, I can take over the final polishing things. Please let me know.

@MaxTru It is done. Can you check again, please? :)

Nice! Merged.
Thanks for the contribution <3

source: gharchive/pull-request

authors: MaxTru aivinog1 andreasgeier barmac


text:
Support setting capture device by label

Currently the only way to select the video capture device is using MediaStreamConstraints deviceId. This is not helpful because the deviceId changes with every new browser session and therefore is not predictable.
However the media devices label property is predictable. Supporting the option to specify the device by label would enable creating multiple VideoCaptures for multiple devices

Thanks will investigate and come back to you . PR is welcome

authors: cancerberoSgx rmcandrews

repo: cancerberoSgx/camera-capture


text:
chore: add 1.9-stable as test reference

Add CKF 1.9 stable as test reference so SQA can perform testing on all the combinations from the "ckf-1.9-stable" object.

Left some comments. Not sure if it's in scope but I think we should make the same updates (k8s version + maybe juju versions) for latest/edge. Maybe juju versions for 1.8 as well?

The scope of this task is to add a ckf-1.9 reference that SQA can take right away, we won't tell them to test latest/edge or 1.8/edge|stable, for now the focus is entirely on ckf-1.9.

repo: canonical/bundle-kubeflow


text:
juju private-address returns wrong IP

Hi,
Nagios checks etc. uses results returned from private-address. Seems on hosts where there's multiple, this can sometimes be wrong:
| ubuntu@comet:~$ sudo juju-run infra/0 "unit-get private-address"
| 10.220.254.1
Is it returning the first?
| ubuntu@comet:~$ sudo juju-run infra/0 "ip -4 addr"
| 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
|     inet 127.0.0.1/8 scope host lo
|        valid_lft forever preferred_lft forever
| 8: br-eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
|     inet 10.220.254.1/24 brd 10.220.254.255 scope global br-eno2
|        valid_lft forever preferred_lft forever
| 9: br-eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
|     inet 10.222.128.23/22 brd 10.222.131.255 scope global br-eno1
|        valid_lft forever preferred_lft forever
Obviously wrong and should be 10.222.128.23:
| ubuntu@comet:~$ sudo juju-run infra/0 "ip route get 8.8.8.8"
| 8.8.8.8 via 10.222.128.1 dev br-eno1  src 10.222.128.23
|     cache
This is from an environment deployed using Juju 2.2.3.
Thanks,
Haw

(by jameinel)
How are we to tell what address is "wrong" vs "right" when all addresses
are private. (10.220.254.1 is certainly an RFC 1918 address.)
Charms are recommended to move away from "unit-get private-address" to
"network-get" (see docs for more complete information), which allows juju
to know what space/binding/etc the charm is trying to talk about, and
allows us to have enough context to know which address of multiple possible
addresses is correct.
On Mon, Dec 4, 2017 at 6:45 AM, Haw Loeung
wrote:

Public bug reported:
Hi,
Nagios checks etc. uses results returned from private-address. Seems on
hosts where there's multiple, this can sometimes be wrong:
| ubuntu@comet:~$ sudo juju-run infra/0 "unit-get private-address"
| 10.220.254.1
Is it returning the first?
| ubuntu@comet:~$ sudo juju-run infra/0 "ip -4 addr"
| 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1
|     inet 127.0.0.1/8 scope host lo
|        valid_lft forever preferred_lft forever
| 8: br-eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP group default qlen 1000
|     inet 10.220.254.1/24 brd 10.220.254.255 scope global br-eno2
|        valid_lft forever preferred_lft forever
| 9: br-eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP group default qlen 1000
|     inet 10.222.128.23/22 brd 10.222.131.255 scope global br-eno1
|        valid_lft forever preferred_lft forever
Obviously wrong and should be 10.222.128.23:
| ubuntu@comet:~$ sudo juju-run infra/0 "ip route get 8.8.8.8"
| 8.8.8.8 via 10.222.128.1 dev br-eno1  src 10.222.128.23
|     cache
This is from an environment deployed using Juju 2.2.3.
Thanks,
Haw
** Affects: juju
Importance: Undecided
Status: New
--
You received this bug notification because you are subscribed to juju.
Matching subscriptions: juju bugs
https://bugs.launchpad.net/bugs/1736050
Title:
juju private-address returns wrong IP
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju/+bug/1736050/+subscriptions

(by hloeung)
I would think it would return the source IP used for the default route (as per above it would be '10.222.128.23').
I'll target this bug to the NRPE charm then. I think it could use 'network-get' as advised to get the ingress-addresses for the configured "nagios_master" or from the Nagios relation.

(by hloeung)
Even with 'network-get', the IP address returned is clearly wrong:
| ubuntu@comet:~$ sudo juju-run nrpe-physical/19 "network-get nrpe-external-master"
| info:
| - macaddress: 2c:44:fd:92:61:11
|   interfacename: eno2
|   addresses:
|   - address: 10.220.254.1
|     cidr: 10.220.254.0/24
| - macaddress: 2c:44:fd:92:61:11
|   interfacename: br-eno2
|   addresses:
|   - address: 10.220.254.1
|     cidr: 10.220.254.0/24
Again, on this host, all outbound connections use the 10.222.128.23 address:
| ubuntu@comet:~$ ip route show | grep '^default'
| default via 10.222.128.1 dev br-eno1 onlink
| ubuntu@comet:~$ ip -o addr show dev br-eno1
| 9: br-eno1    inet 10.222.128.23/22 brd 10.222.131.255 scope global br-eno1\       valid_lft forever preferred_lft forever
| 9: br-eno1    inet6 fe80::2e44:fdff:fe92:6110/64 scope link \       valid_lft forever preferred_lft forever

(by jameinel)
Is this a case of "without setting a specific binding, we end up selecting an arbitrary IP that you feel is incorrect"?
I suppose it could be "when guessing what IP to use, prefer the IP associated with the default gateway".
I think its still guessing, rather than doing something the user explicitly requested. It could be a more educated guess, but I'd like to make sure we have a way for the user to be specific before we do lots of work on heuristics that will always be wrong some of the time.

(by hloeung)
It's still unclear to me what "binding" means and is used by Juju. I think it's the endpoint of the provided relation (per above, "network-get nrpe-external-master").
I think you're right that it could be "when guessing what IP to use, prefer the IP associated with the default gateway". It's better than what it is right now of "when guessing what IP to use, use the IP of the first non-loopback interface".

(by thumper)
If there are no spaces, nor bindings specified, juju should report the address that would be used to contact the API servers.
This has been done in python by opening a UDP socket to the server, and looking at the client IP address, then closing the socket. Since it is a UDP socket, there is no traffic, just a file handle that is released quickly.

repo: canonical/charm-nrpe


text:
Fixed tutorial documentation

Applicable spec:
Overview
Updated documentation to add PostgreSQL extensions and also updated the integration commands.
Rationale
The tutorial was not able to create a working charm so had to be updated.
Juju Events Changes

Module Changes

Library Changes

Checklist

[ ] The charm style guide was applied
[ ] The contributing guide was applied
[ ] The changes are compliant with ISD054 - Managing Charm Complexity
[ ] The documentation is generated using src-docs
[ ] The documentation for charmhub is updated
[ ] The PR is tagged with appropriate label (urgent, trivial, complex)

Can you also complete the checklist and add the appropriate labels (trivial and documentation)? Thank you very much.

authors: alithethird cbartz

repo: canonical/indico-operator


text:
docs: update backup file docs

Applicable spec: N/A
Overview
Update backup guide to be copy-pasteable & fix some bugs with pathing.
Rationale
:)
Juju Events Changes

Module Changes

Library Changes

Checklist

[x] The charm style guide was applied
[x] The contributing guide was applied
[x] The changes are compliant with ISD054 - Managing Charm Complexity
[x] The documentation is generated using src-docs
[x] The documentation for charmhub is updated.
[x] The PR is tagged with appropriate label (urgent, trivial, complex)

Fixed issues w/ lint from the previous PR that I didn't catch locally after running tox -e unit.


text:
tests: add kfp-ui test case in repo level integration tests

Add a test case for reaching kfp-ui and getting back a 200 response.

NOTE: merge after #261

The bundle integration test seems to be failing because of #243, will re-trigger the CI once again.

repo: canonical/kfp-operators


text:
1.24/candidate Non-leader units fail to join

This issue was only seen on 1.24/candidate, not on 1.23.
When deploy the microk8s charm, only the leader comes up:
Unit         Workload  Agent  Machine  Public address  Ports                     Message
microk8s/0*  active    idle   0        10.246.164.250  80/tcp,443/tcp,16443/tcp
microk8s/1   blocked   idle   1        10.246.165.180  80/tcp,443/tcp,16443/tcp  join failed, will try again
microk8s/2   blocked   idle   2        10.246.167.142  80/tcp,443/tcp,16443/tcp  join failed, will try again

In the juju debug-log, we see a number of errors:
ERROR unit.microk8s/1.juju-log Failed to get coredns configmap!  kubectl said: b'Error from server (NotFound): configmaps "coredns" not found\n'
DEBUG unit.microk8s/1.update-status Joining cluster failed. Could not verify the identity of 10.246.164.250. Use '--skip-verify' to skip server certificate check.
ERROR unit.microk8s/1.juju-log Failed to join cluster; deferring to try again later.

I assume that means that the other units are not getting certificates.
inspection-report
juju-crashdump

Hi @Basdbruijne, thank you for reporting the issue.
This appears related to a known issue that may occur sometimes, where the cluster agent service is serving TLS traffic with an outdated certificate. Unfortunately, this situation happens frequently when deploying the MicroK8s charm. This is on our radar and we are working on a fix.
In the meantime, you can try deploying the MicroK8s charm from the edge channel like so:
juju deploy microk8s --channel edge --config channel=1.24/candidate --config skip_verify=true -n 3

Thanks @neoaggelos, the edge channel works as expected.

I am having the same issue. I am deploying microk8s on openstack with the following:
juju deploy microk8s -n 3 --revision 28 --channel stable --series jammy --constraints 'cores=2 mem=4G'
Is there anything I am doing wrong?
Thank you!
error.log

@adelorenzo-portainer I am unable to reproduce the issue with revision 28. Does it happen consistently? Still, would be useful to look into it if it happens frequently enough. Also, does:
juju config microk8s skip_verify=true

perhaps solve your issue?

unfortunately, it did not fix the issue. I noticed that the problem happens when I am using an openstack/microstack cloud. It works ok on a localhost cloud.

ok, so I managed to find a way to have the nodes join the cluster. I logged in on each of them and added the IPs/hostnames to the /etc/hosts.
this is quite strange, given I started the juju deploy with the --config manage_etc_hosts=true option. I hope this helps.

Still seems to be broken for me. I started this with: juju deploy microk8s -n 3 --revision 28 --channel stable --series jammy --constraints 'cores=2 mem=4G' --config skip_verify=true
Here's the current status:
App       Version  Status   Scale  Charm     Channel  Rev  Exposed  Message
microk8s           blocked      3  microk8s  stable    28  no       join failed, will try again

Unit         Workload  Agent  Machine  Public address  Ports                     Message
microk8s/4   blocked   idle   11       x.x.x.217   80/tcp,443/tcp,16443/tcp  join failed, will try again
microk8s/5   blocked   idle   12       x.x.x.162   80/tcp,443/tcp,16443/tcp  join failed, will try again
microk8s/6*  active    idle   13       x.x.x.49    80/tcp,443/tcp,16443/tcp

and the debug-log:
unit-microk8s-4: 14:30:16 INFO juju.worker.uniter found queued "start" hook
unit-microk8s-4: 14:30:16 INFO unit.microk8s/4.juju-log Running legacy hooks/start.
unit-microk8s-5: 14:30:17 ERROR unit.microk8s/5.juju-log cluster:6: Failed to join cluster; deferring to try again later.
unit-microk8s-5: 14:30:18 INFO juju.worker.uniter.operation ran "cluster-relation-changed" hook (via hook dispatching script: dispatch)
unit-microk8s-5: 14:30:19 ERROR unit.microk8s/5.juju-log cluster:6: Failed to get coredns configmap!  kubectl said: b'Error from server (NotFound): configmaps "coredns" not found\n'
unit-microk8s-4: 14:30:19 ERROR unit.microk8s/4.juju-log Failed to get coredns configmap!  kubectl said: b'Error from server (NotFound): configmaps "coredns" not found\n'
unit-microk8s-4: 14:30:20 INFO juju.worker.uniter.operation ran "start" hook (via hook dispatching script: dispatch)
unit-microk8s-5: 14:30:20 ERROR unit.microk8s/5.juju-log cluster:6: Failed to join cluster; deferring to try again later.
unit-microk8s-5: 14:30:22 ERROR unit.microk8s/5.juju-log cluster:6: Failed to join cluster; deferring to try again later.
unit-microk8s-4: 14:30:22 ERROR unit.microk8s/4.juju-log cluster:6: Failed to get coredns configmap!  kubectl said: b'Error from server (NotFound): configmaps "coredns" not found\n'
unit-microk8s-4: 14:30:23 ERROR unit.microk8s/4.juju-log cluster:6: Failed to join cluster; deferring to try again later.
unit-microk8s-5: 14:30:23 ERROR unit.microk8s/5.juju-log cluster:6: Failed to join cluster; deferring to try again later.
unit-microk8s-4: 14:30:24 INFO juju.worker.uniter.operation ran "cluster-relation-changed" hook (via hook dispatching script: dispatch)
unit-microk8s-4: 14:30:25 ERROR unit.microk8s/4.juju-log cluster:6: Failed to get coredns configmap!  kubectl said: b'Error from server (NotFound): configmaps "coredns" not found\n'
unit-microk8s-5: 14:30:26 ERROR unit.microk8s/5.juju-log cluster:6: Failed to join cluster; deferring to try again later.
unit-microk8s-5: 14:30:26 INFO juju.worker.uniter.operation ran "cluster-relation-changed" hook (via hook dispatching script: dispatch)
unit-microk8s-4: 14:30:27 ERROR unit.microk8s/4.juju-log cluster:6: Failed to join cluster; deferring to try again later.
unit-microk8s-4: 14:30:28 INFO juju.worker.uniter.operation ran "cluster-relation-joined" hook (via hook dispatching script: dispatch)
unit-microk8s-4: 14:30:28 ERROR unit.microk8s/4.juju-log cluster:6: Failed to get coredns configmap!  kubectl said: b'Error from server (NotFound): configmaps "coredns" not found\n'
unit-microk8s-4: 14:30:30 ERROR unit.microk8s/4.juju-log cluster:6: Failed to join cluster; deferring to try again later.
unit-microk8s-4: 14:30:33 ERROR unit.microk8s/4.juju-log cluster:6: Failed to join cluster; deferring to try again later.

Hi @plars, apologies for missing this. Which cloud are you using to deploy the MicroK8s charm?

It's a private openstack

In my case it's microstack

@plars @adelorenzo-portainer is it possible to raise the logging verbosity to DEBUG to get more information about the exact error? Something like juju model-config logging-config='<root>=DEBUG' should do

I have the same error when deploying on AWS.

authors: Barteus Basdbruijne adelorenzo-portainer neoaggelos plars


text:
Set kubernetes version based on manifest, set snap version as eskd version

Summary

Set kubernetes version based on manifest, set snap version as eskd version
Changes

Added the ability to set the kubernetes version based on the fetched eksd manifest
Set snap version to eksd version instead of kubernetes version
Organized and cleaned up code
Testing

Manually tested by snapping and installing the snap.
Possible Regressions

Checklist

[X] Read the contributions page.
[X] Submitted the CLA form, if you are a first time contributor.
[X] The introduced changes are covered by unit and/or integration tests.

Notes

nit; should help with keeping the diff concise.

Sorry @neoaggelos  I missed that.

authors: berkayoz ktsakalozos


text:
CI green when scenario tests fail

Currently, CI workflow for scenario tests reports green even though the tests failed.
Probably, it's this line?

This is only an issue in Scenario. However, in all other tests when tox.ini exists but has some test failures the error code is 1 which means we then run the make tests (unnecessary debugging clutter). Similarly, When make tests fail then the error code is 2.
We need to come up with a more robust way to handle the failover to Make and to handle the cases with Make where the directory does not exist. Examples:

Scenario fails in CI although we have no Scenario tests, now we cannot PR.
Do not run Make when Tox has tests failures. Only run Make when Tox does not exist.

authors: MichaelThamm michaeldmitry

repo: canonical/observability


text:
[DPE-3578] clear backup status

Move the status messages in opensearch_backup module to comply with charm.status.{set,clear}. All text has been moved to constant_charms.py.
This PR also simplifies the exception structure, where the plugins should log their own errors if that is not supposed to come back to the plugin manager and the charm itself. The exception OpenSearchPluginClusterNotReadyError has been abandoned in favor of the default exception for the same type of error in constant_exceptions.
Tests have been updated accordingly.

The CI error is caused by a timeout, while waiting for restart: https://github.com/canonical/opensearch-operator/actions/runs/7933066738/job/21680561224
It is unrelated to this change.

repo: canonical/opensearch-operator


text:
🛑 microk8s.io is down

In 9a3fae8, microk8s.io (https://microk8s.io) was down:

HTTP code: 0
Response time: 0 ms

Resolved: microk8s.io is back up in e73e441.

repo: canonical/upptime


text:
🛑 certification.ubuntu.com is down

In 5665d6c, certification.ubuntu.com (https://certification.ubuntu.com) was down:

HTTP code: 503
Response time: 5966 ms

Resolved: certification.ubuntu.com is back up in 64b5399.


text:
set strict mode always to false

fix #371

This change is

Coverage increased (+0.006%) to 66.547% when pulling 3ea03c7e58483e84a1f4f8c7ad7a0a39bc3a7e13 on communication_fix_fix into ab71e44608600304e6925f3c5ab071e17b1f2b0d on master.

repo: canoo/dolphin-platform

license_source: bigquery


text:
Message marked as read but has not yet been Opened!

[PT]
Após enviar a Mensagem no Painel ela já é marcada automaticamente como Entregue e Lida pelo Usuário!
Porém a Mensagem não foi lida ainda!
Alguma Solução?
[EN]
After sending the Message in the Dashboard it is already automatically marked as Delivered and Read by the User!
But the Message hasn't been read yet!
Any solution?

Same here! will try to solve it but If anyone has already fix it... will help a lot. ty

I partially fixed this, I thought I had solved it but later realized i didn't solve everything.
After you open the ticket and leave it, the other messages will appear correctly as unread. Only the first message of the ticket doesn't seem to work.
Examples:

Client sends 1 message (the ticket is created but doesn't show as unread)
Client sends 2 messages (the ticket is created and shows that there is 1 unread message instead of 2)
After the ticket is read once, if the client sends more messages it counts correctly.

Found it, it happens when whaticket assigns the queue to the ticket:

wbotMessageListener.ts
And when you open "UpdateTicketService"

UpdateTicketService.ts
Just gotta find the right way to solve it now

UpdateTicketService.ts
This seems to be working.

wbotMessageListener.ts
This change I had been using for a while, if fixes the quantity of unread messages.

@Horgun so the change in the UpdateTicketService.ts seems to work? I have to add the '+1' in the wbotMessageListener.ts file also? or it was a temporal fix this last one?

authors: Horgun rodrimarchese thiagoaraujo007

repo: canove/whaticket-community


text:
Proper signature for ndarray and opaque objects

This is minor update to handle nanobind::ndarray and opaque objects in function signature.

Thanks for the PR, this should fix #3. I will test it as soon you tell me it's ready :)

There might be more regex based replacements, maybe we should implement a signature pre-processor method which handles all these special cases.

authors: cansik qnzhou

repo: cansik/nanobind-stubgen


text:
Give ChangeDetectorAgent access to last_property

This allows user to detect a new lowest value or a new high by comparing a new value with the existing value.

Perhaps we need new Liquid filters such as greater/lesser to make numeric comarison less messy...

Yea, that might make sense. This looks good though.

@cantino Thanks, I'll file another PR when I think of good syntax for numeric comparison.

authors: cantino knu

repo: cantino/huginn

license: mit


text:
NullReferenceException SyncTrayzor 1.1.13.0 amd64 portable

Crashed while I've been away from computer.
syncthing v0.14.10 "Dysprosium Dragonfly" (go1.7.1 windows-amd64) jenkins@build.syncthing.net 2016-11-01 10:26:25 UTC
Windows 10 Home x64 1607
Version: 1.1.13.0; Variant: Portable; Arch: Amd64
Path: T:\PortableApps\synctrayzorportable-x64\synctrayzor.exe
System.NullReferenceException: Ссылка на объект не указывает на экземпляр объекта.
   в SyncTrayzor.Syncthing.Devices.SyncthingDeviceManager.<PauseDeviceAsync>d__28.MoveNext() в C:\projects\synctrayzor\src\SyncTrayzor\Syncthing\Devices\SyncthingDeviceManager.cs:строка 141
--- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
   в System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   в SyncTrayzor.Services.Metering.MeteredNetworkManager.<UpdateDeviceAsync>d__33.MoveNext() в C:\projects\synctrayzor\src\SyncTrayzor\Services\Metering\MeteredNetworkManager.cs:строка 313
--- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
   в System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   в System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   в SyncTrayzor.Services.Metering.MeteredNetworkManager.<DeviceConnected>d__24.MoveNext() в C:\projects\synctrayzor\src\SyncTrayzor\Services\Metering\MeteredNetworkManager.cs:строка 179
--- Конец трассировка стека из предыдущего расположения, где возникло исключение ---
   в System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state)
   в System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   в System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

Weird, that line of code shouldn't be able to throw that exception. Mind posting the relevant section of your log? You'll find it in the logs subdirectory.

SyncTrayzor — copy.log.zip

Ditto with non-portable version:
Version: 1.1.13.0; Variant: Installed; Arch: Amd64
Path: C:\Program Files\SyncTrayzor\SyncTrayzor.exe
System.NullReferenceException: Object reference not set to an instance of an object.
   at SyncTrayzor.Syncthing.Devices.SyncthingDeviceManager.<PauseDeviceAsync>d__28.MoveNext() in C:\projects\synctrayzor\src\SyncTrayzor\Syncthing\Devices\SyncthingDeviceManager.cs:line 141
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at SyncTrayzor.Services.Metering.MeteredNetworkManager.<UpdateDeviceAsync>d__33.MoveNext() in C:\projects\synctrayzor\src\SyncTrayzor\Services\Metering\MeteredNetworkManager.cs:line 313
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at SyncTrayzor.Services.Metering.MeteredNetworkManager.<DeviceConnected>d__24.MoveNext() in C:\projects\synctrayzor\src\SyncTrayzor\Services\Metering\MeteredNetworkManager.cs:line 179
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)


text:
Feature/word level progress tracking

Pull request checklist
Please check if your PR fulfills the following requirements:

[ ] The changes have been tested successfully.

I have updated the commit as per changes requested. Please check and test it.

Please fix the workflow errors.

repo: capacitor-community/text-to-speech


text:
Git repository disappeared 🤷

Any help on this would be stupendous because it doesn't make sense at all to me.
For, a seemingly non-reason, cap just lost the ability to see my git repo..
00:00 git:wrapper
      01 mkdir -p /tmp
    ✔ 01 deploy@45.32.91.107 0.245s
      Uploading /tmp/git-ssh-digiramp-production-atebit.sh 100.0%
      02 chmod 700 /tmp/git-ssh-digiramp-production-atebit.sh
    ✔ 02 deploy@45.32.91.107 0.250s
00:01 git:check
      01 git ls-remote git@github.com:adjustcreative/digiramp.git HEAD
      01 ERROR: Repository not found.
      01 fatal: Could not read from remote repository.
      01 Please make sure you have the correct access rights
      01 and the repository exists.

Caused by:
SSHKit::Command::Failed: git exit status: 128
git stdout: Nothing written
git stderr: ERROR: Repository not found.
fatal: Could not read from remote repository.

I've copied the line git ls-remote git@github.com:adjustcreative/digiramp.git and pasted directly into terminal and get this:
git ls-remote git@github.com:adjustcreative/digiramp.gitatebit:digiramp atebit$ git ls-remote git@github.com:adjustcreative/digiramp.git
fa174f9d90d2b7fdfa20cf921d7e219bfda0d447	HEAD
905ac6f5b57d34c82e6955d503cfa802d43ff3d9	refs/heads/heroku_mods
fa174f9d90d2b7fdfa20cf921d7e219bfda0d447	refs/heads/master
22bee22ded9d347519146f7ea5a646fb7a4cc23e	refs/heads/vultr_mods

The ssh keys are valid, and added to both Github and locally with ssh-add..
Has anyone seen this issue before?

I'm experiencing the same issue on my Ubuntu 20 server after doing an apt-get upgrade. Everything was working well before that. Quite strange.
@atebit Did you find a solution for this?

Okay. I figured it out. On the remote server, a colleague of mine had created a public-private key pair. I deleted them and it worked.

authors: atebit mrudult

repo: capistrano/capistrano


text:
Save viewed state

This PR starts the work to save viewed state for diffs.
As discussed in #50 the state is saved in workspaceState so that we don't have to change the file.
I've split the work in three stages; the first is done
stage 1 – save basic boolean state

[x] add toggleViewed message: filename -> viewedValue (bool for now)
[x] instrument webview to send these messages
[x] instrument extension to remember it in workspaceState
[x] instrument extension to give the information to the webview when updating the view
[x] instrument webview to reflect the remembered state on update

stage 2 – optional – make it work with multiple tabs open

[ ] instrument extension to notify all relevant webviews about state changes (when the same diff is opened multiple times)

stage 3 – work nicely with changes in the diff file

[ ] include hash of what was viewed in viewedValue
[ ] where webview reflects the remembered state, if the current state doesn't match the hash, don't toggle as viewed but show a message "changed since last viewed"
[ ] clear that message on toggle

"won't" requirements:

[ ] make it a configurable option (because the content of the file isn't changing so I think it's a natural expectation that the state can be saved)

What do you think @caponetto ? I'm particularly not sure about where you would like some of the new interfaces and classes to live.
The first commit is just localized suggested renaming for clarity where we deal with elements inside a diff view, not the diff container itself.

@jacekkopecky can you please rebase your branch with main?

Thank you @caponetto!
If you're happy with it for now, can you please look at the PR description and see if you like the rest of the plan? And would you like to merge first and have me continue in a next PR, or merge when the whole thing is done?

@jacekkopecky good job here! I'll merge this PR already.
Feel free to send others for stage 2 and stage 3, they are very welcome. :)

authors: caponetto jacekkopecky

repo: caponetto/vscode-diff-viewer


text:
🛑 Funky Ducks is down

In 125764a, Funky Ducks (https://funkyducks.ml/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Funky Ducks is back up in 7664d8c.

repo: captainqdev/funkyducks-status


text:
feat: add Catppuccin theme

Hi :wave:
I'm a staff member over at Catppuccin, we are a community-driven pastel colour theme and we've had some requests to integrate with carbon. It consists of 4 soothing warm flavours with 26 eye-candy colours each. Latte is our light mode offering while Frappe, Macchiato and Mocha are our darker options. I have attached some examples showing off all the flavours using the tool.
I completely understand the CONTRIBUTING guidelines explicitly state that carbon is not accepting new themes into the codebase. However, the same guidelines encourage opening a PR for consideration and therefore, I am putting up this PR for Catppuccin to be considered.
Thank you for your work in building this great tool!
Examples:
Latte

Frappe

Macchiato

Mocha

Stellar work as usual, @sgoudham. Hoping they get added 🤞🏼

Hey, thanks for the suggestion!. As of Carbon 3.0.0, the core Carbon team is no longer implementing new themes or languages ourselves (although we are adding the ability to create your own soon!), but we are happy to accept PRs to add new ones.
Please see https://github.com/dawnlabs/carbon#a-note-on-adding-themeslanguages for notes on how to do so 🙂

authors: JoshPaulie mfix22 sgoudham

repo: carbon-app/carbon


text:
fix(overflow-menu): added different styles for focus and hover

Overview
Closes https://github.com/carbon-design-system/carbon-components/issues/436
The first option in the Overflow Menu is always focused on open, which makes it a bit confusing when hovering over the other options as they are currently styled the same way.
I tried @aagonzales's option 2 but could not make it work as the options are separated from the main overflow menu element, so the focus is needed on open to indicate to the browser where it should focus next. So option 1 it is with an underline on focus and the existing styling on hover.

Added
Removed
Changed

_overflow-menu.scss Added different styles for focus and hover

Testing / Reviewing
Make sure the overflow menu works as intended.

Looks good for the most part, just noticed this when tabbing

repo: carbon-design-system/carbon-components


text:
Integrate percy workflow for vanilla package

User Story

As a [user role below]:
IBM.com Library reviewer

I need to:
have visual regression tests for the vanilla package

so that I can:
keep track of visual changes that may impact the vanilla components

Additional information

Percy workflow has already been integrated into React
May need to adjust a number of the components to render static data if in percy

Acceptance criteria

[ ] Added deploy previews for vanilla package

@RobertaJHahn FYI, going to icebox this for now.

Closing this, we have deprecated the vanilla package.

Closing this, we have deprecated the vanilla package.


text:
Web component: Link List -  In  iPhone VO there is no role for the mentioned links

Detailed description
On Voiceover iPhone
Issue: Links found in Horizontal, Vertical, End Of Section links found at the first card in (Vertical With Cards): - in iPhone VO there is no role for the mentioned links
Note: in react staging screen reader is identifying the role link.
Expected - Screen reader should identify the role for the mentioned links.
Additional information

@Praveen-sr
Could you please give us a little more info about this?
Doesn't VO mention the listitem role?

@RaphaelAmadeu Here the mentioned links are announced only as text. The "link" role is not announced.
Hence the user would not know that these are interactive elements.
Expected behavior: VO should announce these as links instead of only announcing as "text".

@Praveen-sr Could your team re-test this issue at: http://ibmdotcom-web-components-canary.mybluemix.net/iframe.html?id=components-link-list--vertical
Out investigation shows that the latest code has the right a11y tree and works well with Safari VoiceOver. The VoiceOver one in below screenshot is of desktop, but I see mobile Safari has the same result. Thanks!

authors: Praveen-sr RaphaelAmadeu asudoh


text:
[Masthead] React component: Autosuggest in the searchbox causes runtime error

Detailed description

Describe in detail the issue you're having.
Having problems with the Autosuggest function in the searchbox of [Masthead]. A list of suggestions displays as I type in the searchbox but upon clicking a suggestion I get a runtime error. Everything else in the masthead seems to work OK including the search itself (even with custom EventListeners).

Is this a feature request (new component, new icon), a bug, or a general
issue?
BUG

Is this issue related to a specific component?
Masthead

What did you expect to happen? What happened instead? What would you like to
see changed?
Uncaught TypeError: Cannot read property 'focus' of undefined     at Object.eval [as onClick] (Autosuggest.js?0a0f:208)     at eval (Item.js?4fd4:114)     at HTMLUnknownElement.callCallback (react-dom.development.js?61bb:3945)     at Object.invokeGuardedCallbackDev (react-dom.development.js?61bb:3994)     at invokeGuardedCallback (react-dom.development.js?61bb:4056)     at invokeGuardedCallbackAndCatchFirstError (react-dom.development.js?61bb:4070)     at executeDispatch (react-dom.development.js?61bb:8243)     at processDispatchQueueItemsInOrder (react-dom.development.js?61bb:8275)     at processDispatchQueue (react-dom.development.js?61bb:8288)     at dispatchEventsForPlugins (react-dom.development.js?61bb:8299)     at eval (react-dom.development.js?61bb:8508)     at batchedEventUpdates$1 (react-dom.development.js?61bb:22396)     at batchedEventUpdates (react-dom.development.js?61bb:3745)     at dispatchEventForPluginEventSystem (react-dom.development.js?61bb:8507)     at attemptToDispatchEvent (react-dom.development.js?61bb:6005)     at dispatchEvent (react-dom.development.js?61bb:5924)     at unstable_runWithPriority (scheduler.development.js?3069:468)     at runWithPriority$1 (react-dom.development.js?61bb:11276)     at discreteUpdates$1 (react-dom.development.js?61bb:22413)     at discreteUpdates (react-dom.development.js?61bb:3756)     at dispatchDiscreteEvent (react-dom.development.js?61bb:5889)

What browser are you working in?
Chrome, Edge

What version of Carbon for IBM.com are you using?
1.20.0

Steps to reproduce the issue
https://github.ibm.com/hysky/redbooks-nextjs-mirror

run $ npm run dev
Open localhost:3000
Click on search icon, start typing
Click on suggestion
See runtime error

Additional information
I reported the issue in #carbon-for-ibm-dotcom slack channel. Anna Wen confirmed the issue and asked me to create a bug report.

@patrikhysky  Are you running as a node application or static deploy?  Is the experience blocked or does it redirect?

@RobertaJHahn it's a node.js + react.js + next.js application, I posted a link to the repo in my original post. The experience is blocked. The suggestions do come up but upon clicking on a suggestion node throws a runtime error. Search functions normally when not using the suggestions.

authors: PatrikHysky RobertaJHahn


text:
Guidelines : layout patterns for cupcake website

LARAHANL created the following on Nov 27:
User story
As an adopter I need to see examples of good layout design so that I can create a strong user flow and page narrative.
Notes
Some work in the past are found in Box
An example of what this may look like is captured here
Acceptance criteria

[ ] Provide a set of layout options
[ ] Each option should have high level intent and usage mappings (this band is recommended for long reading)
[ ] Provide some examples of each
[ ] update 2x grid layout patterns page

Original issue: https://github.ibm.com/webstandards/digital-design/issues/339

On Nov 27, LARAHANL commented:
https://www.ibm.com/standards/web/design-guidelines/layout-patterns.html

On Jan 07, LARAHANL commented:
@chsanche here's something you might want to jump in on. There is no current milestone but this page needs some redesign love https://www.ibm.com/standards/web/design-guidelines/layout.html
Initial thoughts from @Wonil-Suh1 : how can we make this more expressive and exciting? Can we show new examples? Can we improve the layout of this page?

On Feb 01, LARAHANL commented:
Things to consider:

[ ] recommended top spacing
[ ] recommended bottom spacing
[ ] text placement options
[ ] some common layout options (4-4-4-4, 2-6-6-2, 6-6, etc)
[ ] common type hierarchy options
[ ] examples and inspirations
[ ] DOs and DON'Ts

On Apr 11, Wonil-Suh1 commented:
@LARAHANL I think we should keep this for now, until we have a good number of patterns. Then we can close this epic and open new issues per case basis. What do you think?

On Apr 10, LARAHANL commented:
@Wonil-Suh1 here's the Epic I created earlier this year for layout patterns.

We could keep this as an epic and create user stories for each task
or we remove the epic and only focus on individuals issues

On Aug 04, Wonil-Suh1 commented:
Let's make this a bit detached from use cases, and focus on layout options based on grid usage, intent (reading, transactional, level of details, placement on the page).

On Apr 18, Wonil-Suh1 commented:
An idea for interactive pattern preview component (moving from #494):

On Aug 06, Wonil-Suh1 commented:
Per discussion, changing this story to guidelines on cupcake.

Closing this epic. It is old and the guidelines for layout patterns v1 are live: https://ibm-dotcom-library.mybluemix.net/patterns

repo: carbon-design-system/ibm-dotcom-library


text:
Component: Image with Caption:- On mobile and tablet image is displayed in oval shape

Issue Description:- In image with caption component image is getting displayed in oval shape.  This fix must be included in the first patch for the May v1.7.0 regression testing.
Steps to reproduce the issue

Enter url in the mobile browser.
Select 'Image with Caption' component.
Notice the shape of image.

OS:- iOS 12, 13, Android 8,9
Devices:- Mobile and Tablet
URL:- https://ibmdotcom-react-staging.mybluemix.net/?path=/story/components-imagewithcaption--default

@RobertaJHahn @annawen1 : Checked today Image in 'Image with Caption' is getting displayed properly in mobile and tablet.
Attached screen shot.


text:
Masthead: mobile menu should be full-width and cover L0

Because we're using Carbon UI header, the [hamburger] menu doesn't behave/appear the same as ibm.com masthead specs.
Current implementation:

In the original design,mobile menu should slide over the entire screen, covering the L0. The platform name would appear at the top of the menu list. Like so:

The platform name is used as a title and navigational link.
The close-icon is used to bring the user back to the previous page view and show L0 again.
Like so:

This model allows the user to focus more on menu navigation. It prevents them from tapping on IBM logo, Search or Login which is distracting them from the main task at hand.

@kennylam @larahanlon2 I am moving this epic back into the Prioritized Epics pipeline.  During the Triage meeting, we decided to turn this original issue into an epic and use linked issues to manage the multiple tasks associated with this work.  We also agreed that the first issue would be to work with Carbon regarding the strategic solution.  I have created Issue 824 to capture this work.  I assigned it to the first sprint in 2020 as many people will begin taking holiday vacation.


text:
Storybook console warning: Each child in DatagridSimpleBody should have a unique "key" prop

What package(s) are you using?

[x] Carbon for IBM Products (or Carbon for IBM Cloud & Cognitive)

Detailed description

Describe in detail the issue you're having.

When running Storybook locally, I see console warnings across many stories.
http://localhost:3000/?path=/story/ibm-products-components-datagrid-datagrid-canary--basic-usage
Warning: Each child in a list should have a unique "key" prop.
Check the render method of `DatagridSimpleBody`...

Is this issue related to a specific component?

Yes: packages/ibm-products/src/components/Datagrid/Datagrid/DatagridSimpleBody.js

What did you expect to happen? What happened instead? What would you like to see changed?

We should not see these console warnings at all.

What browser are you working in?

Chrome, latest.

What version of the @carbon/ibm-products (or @carbon/ibm-cloud-cognitive) package are you using?

v2.12

Any pressing ship or release dates we should be aware of?

No.
Steps to reproduce the issue

Fork and clone @carbon/ibm-products to your local machine.
yarn to install packages.
yarn storybook to run Storybook.
Open the browser to each of the URLs listed above.
Open the browser's dev tools.
Select the "Console" tab to view the console warnings.

After some research, this may not be fixable.
The render function of DatagridSimpleBody is mapping through object-oriented code instead of a React/JSX/DOM element node. This is where a "key" property would normally be applied.
(Example code simplified for clarity)
const DatagridSimpleBody = () => {
  return (
    <TableBody ... >
      {rows.map((row) => {
        prepareRow(row);
        return row.RowRenderer({ row });
      })}
    </TableBody>
  );
};

I believe we just needed to add the key to fragment in DatagridRow which is the component that row.RowRenderer renders. https://github.com/carbon-design-system/ibm-products/pull/3772

authors: matthewgallo paul-balchin-ibm

repo: carbon-design-system/ibm-products


text:
Install script fails silently if shasum not present

So I went to install this on AWS Linux 2023, and the shasum command wasn't there, and the install.sh script just died after step 2.  I needed to 'dnf install perl-Digest-SHA'
I thought about a docs update, but that would add too many ifs or buts based on distributions, probably.   But I think I could add a check for the command in the install.sh

See #65

Hi, @markgalpin. Thanks for raising an issue. I'll check and review your PR #65

Hello, @markgalpin. Upon checking your PR #65, your condition could cause an issue on Windows. I have already written a fix for this issue, PR #66. Let us know if this issue occurs after the fixes.

authors: markgalpin sairen-carbonetes

repo: carbonetes/diggity


text:
Enable workflows on fork-based PRs part II

pushed on behalf of Johannes Graf graf@synyx.de
Signed-off-by: Johannes Graf graf@synyx.de
copies #17

Closed as it doesn't fix the build issue

repo: carbynestack/cli


text:
Add Carthage support

See https://github.com/card-io/card.io-iOS-SDK/pull/122 for discussion and context.
/cc @kylejm

+1, is there any update?

As carthage will build the lib as a framework, framework are only supported on iOS 8.0 and above. Current card.io lib supports iOS 6.0 and above.

Our policy is to support the current and one previous iOS release. Once iOS 9 is out (soon, right?), we can require iOS 8+.

I am able to build libCardIO.a with Xcode 7 after a little modification, however, when I try to support BitCode, it's blocked by the prebuilt opencv lib. I am wondering how can I build opencv from scratch?
ld: '/projects/card.io-iOS-source/opencv_device/lib/libopencv_core.a(system.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64

@cybertk take a look here: https://github.com/card-io/card.io-iOS-SDK/issues/119

I wonder whether switching to using opencv source rather than .a would make other things better as well, like making card.io usable as a source cocoa pod rather than a static lib.
The historical reason for an opencv .a was that it was a miserable, difficult thing to build opencv for iOS, so we wanted to reduce the steps and docs required to get up and running. That seems to have changed; I guess we should too.

I found that opencv already have CocoaPods support? Can I use that to replace the current one used in cardIO, which version should I use?
$ pod search opencv

-> OpenCV (2.4.10)
   OpenCV (Computer Vision) for iOS.
   pod 'OpenCV', '~> 2.4.10'
   - Homepage: http://opencv.org
   - Source:
   http://hivelocity.dl.sourceforge.net/project/opencvlibrary/opencv-ios/2.4.10/opencv2.framework.zip
   - Versions: 2.4.10, 2.4.9.2, 2.4.9.1, 2.4.9, 2.4.8, 2.4.7, 2.4.6, 2.4.5,
   2.4.3.2, 2.4.3 [master repo]

We don't want to take a dependency on cocoa pods. In fact, we have gone to considerable trouble to ensure that our bundled opencv is isolated. If we switch to opencv source, I think it'll have to be by vendoring the relevant opencv source code like we have done with eigen (but I am open to suggestions).

If you want to be dependency free. I think we can add all other deps as .framework. I saw OpenCV already provide framework for iOS 8.0+

That sounds fine. Before doing that, we'd want:

iOS 9 out so we can drop iOS 7 support
to make sure that the generated binary is roughly the same size. We had to aggressively shrink the version of OpenCV we built against for binary size reasons. The linker ought to take care of this, but it didn't; I don't remember why.
to make sure it works well with @dgoldman-ebay's magic linker flags so that it doesn't interfere with other OpenCV versions pulled in from elsewhere by the end developer.

iOS 9 also come with App Thinning support. That will help making lib more smaller. And currently, cardio is distributed as static library, it will be linked into the final user's App, so it's user's responsibility to optimized the lib size, such as remove all unused code with LTO. And only user can do that optimizition.
But if we distribute cardio as new dynamic library, it's our responsibility to make sure the lib is already optimized in size, as the dynamic library will keep unchanged in final App.

+1 to this, and also to supporting Cocoapods.
I would also strongly prefer having OpenCV purely as a dependency - not bundled, but I do understand there might be some issues here.

+1, we recently completely ditched CocoaPods, and would really like to be able to use CardIO with Carthage.

+1

I have merged in commits provided by @cybertk in #36 . There is now a default CardIO dynamic framework scheme/target. This should help Carthage out. You can try it in your Cartfile:
github "card-io/card.io-iOS-source" "master"

I'm sure many of you already know, but for anyone new to dynamic frameworks, note they can only be embedded in iOS 8 and above apps. Also, there seem to be some issues with dynamic frameworks with slow app launches if you have many of them (See http://mjtsai.com/blog/2015/10/26/dynamic-frameworks-and-app-launch-times/ ). The advantages of the dynamic framework are one single distribution unit (headers, resources, libraries) and also a smaller overall distribution size for everything (~45MB).
The limitation on exported symbols flag is currently disabled so you may have conflicts with other OpenCV libraries. There is an Xcode 7.1 issue in the release notes (it is for static libraries but seems to be similar).
The x86_64 and i386 slices are also now added for OpenCV static libraries (increasing their size but under 100MB). Even though they are not really used, Bitcode enablement for the framework and other warnings seemed to be an issue. Will try to eliminate that as time permits.
The static library schemes/targets also still exist (with the "-static" suffix) and the plan is still to do SDK releases based on that.
Also extracted all the existing build settings into separate Xcode config files where comments can be added to why a setting is disabled/added and can more easily see the differences between the levels of builds among different targets. You can still override the settings in the Xcode target's build setting (Xcode xcodeproj settings override any build configuration setting file at the same level). See http://www.jontolof.com/cocoa/using-xcconfig-files-for-you-xcode-project/ .
If anyone has time, please try this out and let us know if it works. Thanks. Will try to roll out a release next week for the static libraries and such.

BTW, if anyone has ways to improve the size, please feel free to issue PRs or comments. I wanted to get the commits in to at least allow more people to try it and see if the size can be reduced beyond just app slicing.

I tried to install the library with Carthage. Building the app succeeded, but received a fatal error:
dyld: Library not loaded: @rpath/CardIO.framework/CardIO
  Referenced from: /var/mobile/Containers/Bundle/Application/814F08B1-6A18-4823-8936-845AEED03A1A/***-debug.app/***-debug
  Reason: image not found

I'm very sorry, the report above was just because I didn't perform right processes of building ( no.3 & 4 of https://github.com/Carthage/Carthage#if-youre-building-for-ios )
Finally it does work!

I've added github "card-io/card.io-iOS-source" to my Cartfile but unable to build the framework. The terminal hangs at *** Checking out card.io-iOS-source at "iOS_5.4.1" and just stays there indefinitely.

authors: billinghamj bluk cybertk dgoldman-ebay ekimia josharian kballard kevinliu23 takasek


text:
CIP-130 Cardano dApp-MutlisigWallet Web Bridge

A new connector specification that will allow dApps to connect with multisig wallets. And enable defi for DAOs and security conscious users.
The structure of this CIP follows CIP-30 as close as possible, to make integration by applications already using CIP-30 easy and streamlined.
I am requesting the number 130 for this CIP to make the affiliation with CIP-30 clear and easy for dev's to remember and search for. (planning on making Plutus-powered-wallet connector under CIP-230 in the future)
Rendered Version

What is the rationale here to "replicate" the existing CIP-0030 functionality for web wallets under a new global-level namespace rather than simply creating the handful of new API calls as an extension to CIP-0030 itself? i.e.

window.cardano.broclan.enable([130])

The idea of being able to use Script/Multisig addresses to interact with dApps is a good one, I would like to see more rationale and justification surrounding how dApps are expected to behave when encountering a multisig address... Is it up to the dApp to maintain the record of unsigned/unfinished multisig transactions? Should these naturally "decay" over time? Doesn't this present an issue of requiring dApps to be centralized rather than decentralized by placing this onus on the dApp to record state rather than putting the onus on the signers? Maybe a importTransaction endpoint makes sense so that members of the multisig can pass it around amongst themselves? Or the wallet provider could have a record of pending transactions somehow passed between members of the multisig?
We do not allow for "reservation" of CIP numbers, regardless of rationale or justification with only a handful of very notable exceptions. You should move this file to an CIPXXXX directory and await assignment of a CIP number.

What is the rationale here to "replicate" the existing CIP-0030 functionality for web wallets under a new global-level namespace rather than simply creating the handful of new API calls as an extension to CIP-0030 itself? i.e.

window.cardano.broclan.enable([130])

Multisig Wallets cannot implement CIP-30 since it is impossible to implement the api.signTx() and api.signData() endpoints. Implementing it as an extension of CIP-30 will lead to broken applications that try to connect to the multisig wallets and use them as if they are regular wallets.

The idea of being able to use Script/Multisig addresses to interact with dApps is a good one, I would like to see more rationale and justification surrounding how dApps are expected to behave when encountering a multisig address... Is it up to the dApp to maintain the record of unsigned/unfinished multisig transactions? Should these naturally "decay" over time? Doesn't this present an issue of requiring dApps to be centralized rather than decentralized by placing this onus on the dApp to record state rather than putting the onus on the signers? Maybe a importTransaction endpoint makes sense so that members of the multisig can pass it around amongst themselves? Or the wallet provider could have a record of pending transactions somehow passed between members of the multisig?

The wallet is responsible for passing the transactions among the participants, gathering the signatures, composing the final transaction and submitting it on chain, dApps need to keep track of transactions only when hidden metadata is included (only the hash is provided) since in that scenario the wallet does not have all the required information to submit the transaction
The functionality you are asking is already with "importTransaction" included with "submitUnsignedTx"

We do not allow for "reservation" of CIP numbers, regardless of rationale or justification with only a handful of very notable exceptions. You should move this file to an CIPXXXX directory and await assignment of a CIP number.

Done, thank you for the clarification and sorry for the confusion.

@leo42 I look forward to reading this for content.  In the meantime https://github.com/cardano-foundation/CIPs/pull/617#issuecomment-1806847726 is right that we can't allow choosing CIP numbers in the present, let alone reserving them for the future: it would require a conflict resolution system that would be unmanageable because of several technical & human factors.
I have to rename it in the PR title in the meantime to avoid confusion, and also remove the redundant word "Cardano".  I'm also assuming based on a quick review that, while the API strongly resembles CIP-0030, that this is a completely separate API to CIP-0030, and is therefore not an extension to it... please let me know if I'm wrong about that.  cc @Ryun1

@rphair you are right, as I explained in the previous commend :

Multisig Wallets cannot implement CIP-30 since it is impossible to implement the api.signTx() and api.signData() endpoints. Implementing it as an extension of CIP-30 will lead to broken applications that try to connect to the multisig wallets and use them as if they are regular wallets.

So calling it an extension is confusing.

@leo42 I look forward to reading this in more detail for content. In the meantime #617 (comment) is right that we can't allow choosing CIP numbers in the present, let alone reserving them for the future: it would require a conflict resolution system that would be unmanageable because of several technical & human factors.
I have to rename it in the PR title in the meantime to avoid confusion, and also remove the redundant word "Cardano". I'm also assuming based on a quick review that, while the API strongly resembles CIP-0030, that this is a completely separate API to CIP-0030, and is therefore not an extension to it... please let me know if I'm wrong about that. cc @Ryun1

You are correct, implementing as an extension would would lead to problems and it is

(#617 (comment)) What is the rationale here to "replicate" the existing CIP-0030 functionality for web wallets under a new global-level namespace rather than simply creating the handful of new API calls as an extension to CIP-0030 itself? i.e.
window.cardano.broclan.enable([130])

I would first want to seriously consider this issue on both sides... on general principle (I'm not a wallet or dApp developer) I can't imagine going forward with this as written due to practically everything from CIP-0030 being duplicated & therefore prone to divergence: not only in the documentation, but even worse in behavioural inconsistencies between conventional & multisig wallets.
I agree with that I think @Crypto2099 is suggesting that the CIP call only for whatever minimum of functional differences is required by the multisigs.
If @leo42 it is a widespread problem that people are connecting with the wrong type of wallets then shouldn't we be able to settle on a definitive way of handling that though an initial query... even if some changes are necessary to CIP-0030 to support this?
I've put this on the Triage list for our upcoming CIP meeting (https://hackmd.io/@cip-editors/76) ... please @leo42 come to the meeting if you can, to help us all agree on the best footing to proceed with this 😎

@rphair I will be happy to attend if you provide a meeting link.

Discord server (CIP Editors Meetings) invitation: https://discord.gg/JtWfD4hqgz
Discord server link: https://discord.com/channels/971785110770831360
Meeting link: https://discord.com/events/971785110770831360/1164384910551818330

What is the rationale here to "replicate" the existing CIP-0030 functionality for web wallets under a new global-level namespace rather than simply creating the handful of new API calls as an extension to CIP-0030 itself? i.e.

window.cardano.broclan.enable([130])

Multisig Wallets cannot implement CIP-30 since it is impossible to implement the api.signTx() and api.signData() endpoints. Implementing it as an extension of CIP-30 will lead to broken applications that try to connect to the multisig wallets and use them as if they are regular wallets.

I disagree with the premise on principle. It would be quite trivial for a multi-sig wallet to only allow enable calls if the cip-130 (I know we've agreed to change the number but we'll use it for example here) extension is enabled and otherwise throw an error similar to not having a dApp account selected.
Either solution would require major overhauls for all existing dApps to account for and handle multisig wallets so it's not really a matter of one being "easier" for the dApp ecosystem to handle or not, but by making this a multisig-specific extension to CIP-30 we have less concern about maintaining feature parity when there are naturally extensions or modifications to CIP-30.

I agree that maintainability will be easier if it is implemented as an
extension, and I did not consider simply rejecting connections that do not
contain the extension number.
But it will still require some changes to CIP-30 since its specifications
say that all the base endpoints need to be supported and extensions only
add new endpoints.
Can I add changes to another CIP as part of a single pull request ?
p.s. I know Mlabs is supposed to do a rework of CIP-30 but they have not
come back to me yet about coordinating on that front.
On Sun, Nov 12, 2023 at 6:12 AM Adam Dean @.***> wrote:

What is the rationale here to "replicate" the existing CIP-0030
functionality for web wallets under a new global-level namespace rather
than simply creating the handful of new API calls as an extension to
CIP-0030 itself? i.e.

window.cardano.broclan.enable([130])
Multisig Wallets cannot implement CIP-30 since it is impossible to
implement the api.signTx() and api.signData() endpoints. Implementing it as
an extension of CIP-30 will lead to broken applications that try to connect
to the multisig wallets and use them as if they are regular wallets.
I disagree with the premise on principle. It would be quite trivial for a
multi-sig wallet to only allow enable calls if the cip-130 (I know we've
agreed to change the number but we'll use it for example here) extension is
enabled and otherwise throw an error similar to not having a dApp account
selected.
Either solution would require major overhauls for all existing dApps to
account for and handle multisig wallets so it's not really a matter of one
being "easier" for the dApp ecosystem to handle or not, but by making this
a multisig-specific extension to CIP-30 we have less concern about
maintaining feature parity when there are naturally extensions or
modifications to CIP-30.
—
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/617#issuecomment-1806996302,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBLGXOWBT56WKJYEBKJCVDYEBEBHAVCNFSM6AAAAAA7HAZAVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWHE4TMMZQGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

@leo42 https://github.com/cardano-foundation/CIPs/pull/617#issuecomment-1807116642 Can I add changes to another CIP as part of a single pull request ?

Yes, this is common when a CIP requires changes to data structure like the registry tables in CIP-0010 & CIP-0067.  But I don't know of any examples where one CIP PR has made fundamental changes to another prerequisite CIP ... which I think we are considering here.
Generally I think these types of problems are best dealt with through versioning: e.g. "v1 of CIP-0030 doesn't discriminate properly between conventional & multisig wallets, but v2 will according to CIP-0130" (again, naming this informally).
Regardless of exactly how CIP-0030 might be versioned or extended, I believe this PR for this proposal alone should be fully reviewed & merged first.... documenting any dependencies upon further modifications to CIP-0030 in its Path to Active but without modifying CIP-0030 itself... before any future PR to extend or version bump CIP-0030.  Otherwise I can imagine a serious delay in adopting multisig capability as described here because of uncertainty about breaking changes.

Hey @leo42
Thanks for this proposal.
I agree that such functionality should be pursued and added to a dApp-wallet connector.
Although, copying CIP30 endpoints under a new namespace I feel is a mistake.
I would be much more in favour to use the CIP-30 extension mechanism for this, this is the sort of thing the mechanism was added for.
Any potential problems of adding this as an extension I think are less consequential than trying to split this from CIP-30 which introduces unneeded fragmentation IMO.
If you strongly believe that this does not belong as a CIP-30 extension, I would implore you to check out CIP-90, which was an attempt to allow for extensions without the need to include CIP30 endpoints.
Looking forward to seeing how this proposal progresses.

But it will still require some changes to CIP-30 since its specifications say that all the base endpoints need to be supported and extensions only add new endpoints.

Having the base endpoints be supported doesn't mean that they can't naturally return an error if a specific wallet (i.e. multisig, Plutus script, whatever) cannot support them as-written. I would view this more like function overloading on the part of the wallet implementers rather than complete replication.

Yes, in most cases dApps are built using plutus and we need to make special
provisions since Native Scripts cannot provide collateral.
On Tue, Nov 14, 2023, 10:37 AM Vladimir Kalnitsky @.***>
wrote:

@.**** commented on this pull request.
In CIP-XXXX/README.md
https://github.com/cardano-foundation/CIPs/pull/617#discussion_r1392188753
:

+License: CC-BY-4.0
+---

+## Abstract
+
+This document describes a webpage-based communication bridge allowing webpages (i.e. dApps) to interface with Cardano Multisig-wallets. It follows the specification format of CIP-30 as it attempts to make implementing this connector as easy as possible for applications that have already successfully implemented CIP-30. This document is a work in progress and is not yet finalized. It is expected to be updated as the ecosystem evolves.
+
+
+## Motivation: why is this CIP necessary?
+
+In order to facilitate future dApp development, we will need a way for dApps to communicate with multisig wallets, given the unique complexities of native script based address special provisions need to be made to make the connector compatible with them.
+
+Specifically apps building transactions need to be able to get the following information from the wallet:
+- Script descriptor
+- Script Requirements list
+- Collateral donator (since native script based addresses cannot provide collateral for transactions)
Is this for the case when there are plutus scripts as well as native
scripts present? Because native scripts don't require collateral.
—
Reply to this email directly, view it on GitHub
https://github.com/cardano-foundation/CIPs/pull/617#pullrequestreview-1729172598,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBLGXMNNPWLW3CZSGFMXBDYEMUSXAVCNFSM6AAAAAA7HAZAVKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTOMRZGE3TENJZHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

If you create a transaction without knowing the exact signers you will not
be able to calculate the fees correctly.
Also including the correct "required signers" brings UX improvements, and
you need to know if the script has any before-after requirements to set the
correct validBefore and TTL values.
Transactions consuming inputs from a native script address need to attach
the script.

thanks @leo42, that definitely reflects the intentions of the CIP Editors' meeting today... @Ryun1 @Crypto2099 if you can confirm this is now properly integrated as an CIP-0030 extension, then I think it would be good to have on the agenda again next CIP meeting (# 77) to confirm the scope & keep it moving forward.

Hi Leo, Adriano from GameChanger Wallet here. Sorry for the delays on the feedback, i've been offline and working on some deadlines!

If you create a transaction without knowing the exact signers you will not be able to calculate the fees correctly. Also including the correct "required signers" brings UX improvements, and you need to know if the script has any before-after requirements to set the correct validBefore and TTL values. Transactions consuming inputs from a native script address need to attach the script.

Regarding fees and required signers, I've created the concept of Optional Signers on GameChanger Wallet multisig dapp connector to be able to reserve the greatest (worst) fee (possible or expected) as way to minimize the use of required signers feature because how I see it it harms UX when "signature aggregator entity" cannot not know the final outcome, the final set of witnesses that will be provided. Specially on "N of M signers" use cases. This happends a lot, specially from dapps pov, as far as I can tell from our experience connecting Shared Treasuries with dapps.
It would be nice to talk to coordinate the development of a tiny lib to help us auto-calculate the outcomes more accurately for BroClan and GameChanger Wallet, currently I have a solution for this but with help we can extend it.

FYI @zxpectre haven't noticed you in the latest Discord discussion of these issues so wanted to alert you to Monday's wallet connectors workshop: https://discord.com/events/971785110770831360/1176916387046887535 (invite:https://discord.gg/UGcJSKzDfA )

Thanks @rphair, i didn't know about these meetings, I will try to assist but not sure if i'm going to make it on time.
Can you please record it?
Btw @leo42 here is one example use case of the Optional Signers feature on the transaction builder of our dapp connector. There are other ways you can deal with this.

@zxpectre you can join the Discord to find out about future meetings, with all the ideas that came before / during / after this meeting.  Here are the presentation slides with @Ryun1's notes from last hour's meeting taken on top of them: https://docs.google.com/presentation/d/1lXw1yMf-Hyp1eVfaFnbTV9897r6pZEd6zpvLNMqT3cI/

@siegfried I just found from your https://github.com/cardano-foundation/CIPs/pull/611#issuecomment-1828550747 that you've produced a multisig wallet, so your feedback and/or review would be welcome here & and at any of the Discord links above.

@leo42 @Crypto2099 @Ryun1 @siegfried @zxpectre, while you are all here in one place: Have any of you produced, or do you know the production of, a multisig wallet which works according to CIP-1854? (re: https://github.com/cardano-foundation/CIPs/pull/727)

@leo42 @Crypto2099 @Ryun1 @siegfried @zxpectre, while you are all here in one place: Have any of you produced, or do you know the production of, a multisig wallet which works according to CIP-1854? (re: #727)

Not me, BroClan is a single address wallet.

@leo42 @Crypto2099 @Ryun1 @siegfried @zxpectre, while you are all here in one place: Have any of you produced, or do you know the production of, a multisig wallet which works according to CIP-1854? (re: #727)

RoundTable supported CIP-1854 since V2. You can try it for yourself. https://round-table.vercel.app

@leo42 an article from @Hornan7 that illustrates multisig features for dReps... perhaps these functions would also influence the design of a multisig wallet API? (cc @Ryun1 @Crypto2099) https://github.com/cardano-foundation/CIPs/pull/617

@leo42 an article from @Hornan7 that illustrates multisig configuration for dReps... perhaps these requirements would also influence the design of a multisig wallet API? (cc @Ryun1 @Crypto2099) https://forum.cardano.org/t/how-to-create-a-multi-sig-drep/130159

@leo42 an article from @Hornan7 that illustrates multisig configuration for dReps... perhaps these requirements would also influence the design of a multisig wallet API? (cc @Ryun1 @Crypto2099) https://forum.cardano.org/t/how-to-create-a-multi-sig-drep/130159

Yes we are fully compatible with this. I will build a dRrep management and registration portal using the connector so all users of BroCllan(and other providers that implement it) the ability to participate in governance .(when I find some time )

repo: cardano-foundation/CIPs


text:
Ability to edit puzzle links after creation

In case a puzzle's URL was inputted incorrectly or the Google Sheets or Slack URLs are incorrect or need to be updated, it would be useful to be able to update them. Currently, this is only possible from the /admin view.

Resolving as duplicate of #30.

repo: cardinalitypuzzles/smallboard


text:
Support Python 3.11

Please add Python 3.11 to the versions.

Thanks, I'll check it

I've updated the package to version 1.5.6, and added 3.11 there, please have a look

authors: JacomienSU daimor

repo: caretdev/dbt-iris


text:
cargo-generate doesn't work with repos in 'detached HEAD' status

Repro:

Create dummy directory
git init
Add a dummy file
git add dummy
git commit -m "Initial commit"
Edit dummy
git add -u
git commit -m "Commit 2"
git checkout HEAD^
cargo generate --name dummy --git .\

cargo generate --name dummy --git .\
Creating project called `dummy`...
Error:  Git Error: A repo has no Head

This is a common state to be in during PR CI scenarios.
Treating a checked out template as a folder, as opposed to a repo, would help a lot (https://github.com/cargo-generate/cargo-generate/issues/387) but not sure we'll fall into this check https://github.com/cargo-generate/cargo-generate/commit/d2211d28e8ad4d51856323e9ba7e7879dabae163. Ideally, a --directory or --folder parameter would be added instead of this fall-through behavior.
See also:
https://github.com/actions/checkout/issues/6

I agree on this - also useful when developing the templates as cargo-generate wouldn't try to do a git clone of the template, which leads to the issues you describe.
I would suggest to use --path though. Solely based on preference, and becase e.g. cargo install uses --path for this type of specification. Oh... and looking at git --help or basically any other CLI tool... path seems to be the word here 😃

The "path" to go 😁

authors: riverar sassman taurr

repo: cargo-generate/cargo-generate


text:
'World' object has no attribute 'get_actor' (Carla 0.9.5)

I tried to get an actor by using its id using World.get_actor(id), as described in the PythonAPI documentation. It turns out that this method does not exist.
To be sure, I've printed out dir(world) and get_actors is there, but no get_actor can be found.
code:
client = carla.Client('localhost', 2000)
client.set_timeout(5.0)
actor_list = []
world = client.get_world()
some_id = 123
vehicle = world.get_actor(some_id)

same there. Did you figure it out?

It turns out to be a feature only available with 0.9.6

As a workaround I am getting the actor by using the following code, which works in the version 0.9.5:
vehicle = next((x for x in world.get_actors() if x.id == vehicle_id), None)

authors: FelippeRoza ppjtzjb

repo: carla-simulator/carla


text:
Token became writable after getting error in readable on RST answer.

In the folowing example:
extern crate mio;
use std::net;

struct Hnd {
    stream: Option<mio::tcp::TcpStream>
}

impl Hnd {
    fn new() -> Hnd {
        Hnd {
            stream: None
        }
    }
}

impl mio::Handler for Hnd {
    type Timeout = u32;
    type Message = ();

    fn timeout(&mut self, event_loop: &mut mio::EventLoop<Self>, timeout: u32) {
        println!("Timeout.");
        if timeout == 0 {
            event_loop.timeout_ms(0, 1000).unwrap();
        }
        if !self.stream.is_some() {
            let google = net::Ipv4Addr::new(49, 94, 146, 13);
            //let google = net::Ipv4Addr::new(173, 194, 122, 224);
            let stream = mio::tcp::TcpStream::connect(&net::SocketAddr::V4(net::SocketAddrV4::new(google, 80))).unwrap();
            event_loop.register_opt(&stream, mio::Token(0), mio::Interest::writable(), mio::PollOpt::edge()).unwrap();
            self.stream = Some(stream);
        }
    }

    fn writable(&mut self, _: &mut mio::EventLoop<Self>, token: mio::Token) {
        println!("Writable token {}.", token.as_usize());
    }
    fn readable(&mut self, _: &mut mio::EventLoop<Self>, token: mio::Token, rh: mio::ReadHint)
    {
        println!("Readable token {} with read hint {:?}, {:?}", token.as_usize(), rh.is_data(), rh.is_error());
    }
}

fn main() {
    let mut h = Hnd::new();
    let mut event_loop: mio::EventLoop<Hnd> = mio::EventLoop::new().unwrap();
    event_loop.timeout_ms(0, 1000).unwrap();
    event_loop.run(&mut h).unwrap();
}

You'll have:
~/devel/miotest [master] ⚡ ./target/debug/miotest
Timeout.
Readable token 0 with read hint false, true
Writable token 0.
Timeout.

So after getting error in readable stream is writable, which I think is wrong.

It happens even if I deregister token in readable callback:
    fn readable(&mut self, event_loop: &mut mio::EventLoop<Self>, token: mio::Token, rh: mio::ReadHint)
    {
        println!("Readable token {} with read hint {:?}, {:?}", token.as_usize(), rh.is_data(), rh.is_error());
        let stream = match self.stream {
            Some(ref s) => s,
            None => {
                println!("Error! No stream found.");
                return;
            }
        };
        match event_loop.deregister(stream) {
            Err(e) => {
                println!("Error deregistering stream. {:?}", e);
                return;
            }
            _ => (),
        };
    }

Result:
~/devel/miotest [master] ⚡ ./target/debug/miotest
Timeout.
Readable token 0 with read hint false, true
Writable token 0.
Timeout.

I assume you are testing this on Linux?  This is the standard behavior for epoll.  If you connect() with a non-blocking socket and register it with epoll.  Epoll will send back whatever events you registered along with POLLERR.  In your case, you registered POLLIN (readable) and POLLOUT (writable), then it also provides the error hint indicating that your connect failed.   If you think about it, this is the correct behavior, as how else is the kernel going to notify you that your connection failed?
After polling, mio checks the readable event, then calls Handler::readable, then it checks the writable event then calls Handler::writable.  https://github.com/carllerche/mio/blob/master/src/event_loop.rs#L296-L306
Since since you registered for both events, you got both events.
@carllerche :  This is the 2nd time in a week that this behavior has tripped somebody up.  I recommend one of two options (I'm leaning towards the first, but the 2nd could be slightly more efficient):

Pass the ReadHint to the writable event as well so people can check for error/hup. (and change the name to EventHint or something)

Use some standard event callback chaining logic which proceeds to the next event iff a person says proceed.  Maybe a binary result from readable and writable would be good enough, if the handler returns true, you proceed to writable, if the handler returns false, you stop for that file descriptor.

@rrichardson Yes, I'm using Linux and situation not quite normal - on normal epoll loop you got epoll_event and manually checks EPOLLERR, EPOLLIN, or whatever. In most cases you reacts only once, than continues to another epoll_event, or event breaks the loop. In case of mio - on error you have no options - readable and writable will be called one after another. And there is no built in mechanisms to check was the error already handled, or not. I think user should have ability not to pass error further. More over - I think error shouldn't pass further if it was handled by writable or readable.
Maybe add another callback - error?

Closing in favor of #184

authors: carllerche hoxnox rrichardson

repo: carllerche/mio


text:
Fix signature of linux clone function

In fact function returns pid of new process (or tid of new thread)
The signature of the function change, but it's only return value changed from returning nothing to pid_t so I believe that I believe that the amount of code it may break is low.
On the other hand I don't even understand how to use clone that does not return id of newly created process (may be useful for threads?)

@carllerche, any issues with this? The patch is quite trivial.

Sorry, been trying to keep up w/ mio. Looking at this now.

seeeems good.

No problem. Thanks!

authors: carllerche tailhook

repo: carllerche/nix-rust


text:
Add a Dockerfile

Hi!
This PR adds a Dockerfile to stream_exporter.

Looks good, thanks!

authors: carlpett cldmnky


text:
The value of coordinate in .json file

I used 640×480 UnityEyes image data, and  check the size of output data is 55×35.
Next, I want to correct the value of coordinate in .json files.
I read gaze_data.py, but I only checked correction of coordinate point in crop part.
Will .json file be modified to 55x35 when the output image is refined?

@KentaroOtomo
Hi,
Did you figure this out? Would you please give me an example of your json files?

What should I have as "*_cropped.png" self.synthetic_data_paths. These are cropped versions of the synthetic images?

authors: KentaroOtomo noushinha


text:
🛑 Workbench is down

In 4480e2d, Workbench (https://workbench.caryrx.com) was down:

HTTP code: 403
Response time: 83 ms

Resolved: Workbench is back up in 66f1c71 after 12 minutes.

repo: caryrx/Upptime


text:
Bug: WebAuthn Login

When you try to login with WebAuthn, it will jump to the user panel instead of the original login application.

@ComradeProgrammer

Please reopen this issue, the bug is not fixed.
The redirect link is incorrect after login.
Use Password:
https://example.com/redirect_uri?code=1e9dfec8*******c7216&state=qn1pKXYYuprPQigN1PrQsegLf309pXLa

Use WebAuthn:
https://example.com/redirect_uri?code=Auth/yaott&state=UsXE80uTt8oMGQ7vu731HpxLNp5FtZK7

authors: hsluoyz yaotthaha

repo: casdoor/casdoor


text:
Use recipe parameter to construct default value for another parameter

I wanted to setup a recipe where I specify an input and optionally an output.
If no output is given, I automatically construct an output by changing the extension of the input.
Here is the recipe I tried:
recipe input output=(without_extension(input) + '.svg'):
  @echo "{{input}} - {{output}}"

However, this gave me the error: "Variable 'input' not defined".
Did I miss something in the documentation or is this indeed not possible ?
My interim solution was to enter a empty string as default output and handle the default value in bash, but I would prefer to use the without_extension function provided by just.

It seems that we can only use variables in the default parameter values, but this means the command is not as clean to use and requires me to enter a default variable value for input.
The usage scenario I would like to obtain is the following:
# Requested behavior
> just file.png
file.png - file.svg

> just file.png other.svg
file.png - other.svg

Yah, this is unfortunately not possible. Recipe parameters are evaluated in the outer scope, so they don't have access to other parameters.

repo: casey/just


text:
Recipe grouping

Implements recipe grouping feature, see https://github.com/casey/just/issues/1776

I'm currently using the -g flag (for --groups) in this draft PR. This issue: https://github.com/casey/just/issues/1648 asks for a global feature, for which it would also be convenient to use the -g flag. I'm not sure which item should get the -g flag, and if so what would be a better alternate flag letter for either.

Nice!
You might want to rebase, I just merged a PR which allows overriding the confirm prompt using [confirm("prompt")], so there's some churn in attribute stuff.
I think [group: foo], as you have it, is definitely the nicest syntax. If we have it though, we should also have [confirm: "prompt"] too otherwise users will likely get confused.

I think probably the global flag should get -g, since I think it might be more commonly used. The easiest thing to do is probably to not assign short flags to either and wait for someone to complain that one should have a short flag.

Nice!
You might want to rebase, I just merged a PR which allows overriding the confirm prompt using [confirm("prompt")], so there's some churn in attribute stuff.
I think [group: foo], as you have it, is definitely the nicest syntax. If we have it though, we should also have [confirm: "prompt"] too otherwise users will likely get confused.

Solid, I was debating whether [attr: argument] or [attr(argument)] was a better syntax - if there's another attr now that uses () function-like syntax, that seems like the one to go with then.

I think probably the global flag should get -g, since I think it might be more commonly used. The easiest thing to do is probably to not assign short flags to either and wait for someone to complain that one should have a short flag.

Makes sense. This is a feature that I personally want and expect to use reasonably frequently, so I'd want to add a short flag. Maybe -r?

Nice!
You might want to rebase, I just merged a PR which allows overriding the confirm prompt using [confirm("prompt")], so there's some churn in attribute stuff.
I think [group: foo], as you have it, is definitely the nicest syntax. If we have it though, we should also have [confirm: "prompt"] too otherwise users will likely get confused.

Do we want to keep the [confirm(prompt)] syntax around and allow both, or get rid of it?

Makes sense. This is a feature that I personally want and expect to use reasonably frequently, so I'd want to add a short flag. Maybe -r?

Oh, hmmm, I see. --groups will list groups and organize by group when used with --list. So the two uses are just --groups and just --list --groups. What if we made --list organize by group by default? If there are groups in the justfile, I assume that people will want to see them.
Then you wouldn't have to do just --list --groups, which is a super long and annoying invocation. And maybe just --groups is less common, so it doesn't need a short flag?

Do we want to keep the [confirm(prompt)] syntax around and allow both, or get rid of it?

It made it into a release, so we should keep it. But I think the other reason for keeping it is that we might want to have attributes that take multiple arguments. So [attr: arg] is a convenient shorthand when there's a single argument, and [attr(arg)] can be use with one or more arguments.

Makes sense. This is a feature that I personally want and expect to use reasonably frequently, so I'd want to add a short flag. Maybe -r?

Oh, hmmm, I see. --groups will list groups and organize by group when used with --list. So the two uses are just --groups and just --list --groups. What if we made --list organize by group by default? If there are groups in the justfile, I assume that people will want to see them.
Then you wouldn't have to do just --list --groups, which is a super long and annoying invocation. And maybe just --groups is less common, so it doesn't need a short flag?

Do we want to keep the [confirm(prompt)] syntax around and allow both, or get rid of it?

It made it into a release, so we should keep it. But I think the other reason for keeping it is that we might want to have attributes that take multiple arguments. So [attr: arg] is a convenient shorthand when there's a single argument, and [attr(arg)] can be use with one or more arguments.

I like the idea of listing by groups by default. A justfile without any recipes with a [group] will have the same listing behavior as now so it won't break existing behavior. I agree that listing the group names themselves is uncommon and doesn't need a short option. And yeah I think the convention where [attribute: single-arg] is shorthand for [attribute(single-arg)] that doesn't apply to hypothetical multi-argument attributes is fine.

Alright, got this working like so:
justfile:
# Comment
[group: alpha]
a:

[group(alpha)]
[group(beta)]
b:

c:

[group:"multi word group"]
d:

[group("alpha")]
e:

[group: "beta"]
[group(alpha)]
f:

just --list output:
Available recipes:
(no group)
    c
[group: alpha]
    a # Comment
    b
    e
    f
[group: beta]
    b
    f
[group: multi word group]
    d

https://github.com/casey/just/issues/1344 is also probably taken care of by this PR

@casey this is ready for review

when merge?

I'm super busy with another project, so just is sadly being neglected right now. Honestly it'll probably take at least a month before I can start grinding down my GitHub notification backlog, which is insanely large at this point.

@neunenak,
In reading the docs that were added, I'm wondering if you would consider the following output. It's a little more readable to me and is based off of how Django does it.
$ just --list

Available recipes:

[no group]
    email-everyone

[lint]
    cpp-lint
    js-lint
    rust-lint

[rust jobs]
    rust-lint

Instead of:
$ just --list
Available recipes:
(no group)
    email-everyone # Not in a group
[group: lint]
    cpp-lint
    js-lint
    rust-lint
[group: rust jobs]
    rust-lint

@neunenak,
Thank you for the update! I'm really looking forward to this new feature getting added!

@neunenak,
Thank you for the update! I'm really looking forward to this new feature getting added!

Thanks! I'm gonna ping @casey about this PR again, hopefully this can get merged pretty quickly.

I started looking at this, and to be honest I don't really like the refactor into multiple functions. I don't really mind long functions, and generally don't like functions which are defined and only used once. I think I prefer being able to read a long linear function, and not indirect through other functions. Also, it makes the review harder, because it's hard to tell what changed and what didn't. Can you inline it back into a single function in Subcommand::list?

authors: casey epicserve jermatic neunenak


text:
When INSTANT is skipped it burns a row version on the shadow table

Hi,
This is more of a nit that will not affect majority of cases but raising for awareness. In MySQL 8 there is a limit on the max number of row versions you can have on a table.[1] For each instant ddl operation the TOTAL_ROW_VERSIONS value in INFORMATION_SCHEMA.INNODB_TABLES will increment. [2]
When TOTAL_ROW_VERSIONS is 64, INSTANT will not be possible on the next DDL. As expected, Spirit handles this ERROR 4080 gracefully and creates a ghost table where the column is added. The nit here is that on the ghost table, Spirit executes the following which 'burns' a row version on the new table needlessly, since the shadow table is empty it should be possible to use non-instant DDL and 'save' a row version.
CREATE TABLE _stock_old like stock;
ALTER TABLE ADD COLUMN ...; # uses instant by default

Changing this behavior may add needless complexity to optimize for the very small number of cases, (so feel free to close out :) ) but if a user is already hitting this 64 column limit on an existing table, it suggests this may be a frequent operation for them.
Thanks!
Marc
[1] https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#:~:text=reset to 0.-,The maximum number of row versions permitted is 64%2C as each,columns can be added or dropped instantly. Please use COPY/INPLACE.,-The following INFORMATION_SCHEMA
[2] Note that these are tracked differently pre/post mysql 8.0.29. INSTANT_COLS vs TOTAL_ROW_VERSIONS
https://dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-tables-table.html

Come to think of it, this is probably something that can be optimized in innodb. I will open a MySQL feature request to skip instant on an empty table.

Thank you for the feature request. This is something that we can consider in future. I believe there is an easy workaround is to change the ALTER TABLE on the empty table (_stock_new) to use the COPY algorithm. If that doesn't work, this will:
CREATE TABLE _stock_tmp LIKE stock;
ALTER TABLE _stock_tmp ADD COLUMN # uses instant
CREATE TABLE _stock_new LIKE _stock_tmp;
DROP TABLE _stock_tmp;

I am not surprised that Spirit handles the maximum number of instant operations reached correctly. By design it is agnostic as to what is instant/not-instant. The intention is that it can cater to future improvements where more operations may be instant and that trying to determine if an operation will use instant is impossible.
Having said that, we do have tests where we assert that certain known operations are instant or not. I think we should add some tests to assert that after 64 instants, it's not instant, and that the TOTAL_ROW_VERSIONS increases as expected. This will help us detect if MySQL semantics change too, since we test against multiple mysql versions.

authors: morgo reillski

repo: cashapp/spirit


text:
OpenZFS out-of-date

OpenZFS updated to 1.7.0.
Changelog:

ABD support (OpenZFS)
File pool import bug fix (Jorgen Lundman)
ABD move enhancement (Sean Doran)
7968 multi-threaded spa_sync (OpenZFS)
Native Encryption (Tom Caputi)
zpool scrub pause/resume (OpenZFS)
zfs recv of compressed streams fix (OpenZFS)
OS X High Sierra support (Jorgen Lundman)

See: https://openzfsonosx.org/wiki/Downloads#1.7.0

1.7.0 is a separate download for High Sierra only, it doesn't package the uninstall scripts that we use to correctly uninstall this Cask.
I'd suggest installing manually for now until upstream does a full 1.7.0 release.

Is this still the case? 1.7.0 has been working fine for me,  https://openzfsonosx.org/wiki/Changelog#OpenZFS_on_OS_X_1.7.0 says it's includes HS support, don't see it as HS only.

https://openzfsonosx.org/forum/viewtopic.php?f=20&t=3082

Cask has been updated to 1.7.1
https://github.com/caskroom/homebrew-cask/pull/44793

authors: OranguTech commitay tomvanderlee

repo: caskroom/homebrew-cask


text:
virtualbox update

Changes to a cask
Editing an existing cask

[x] Commit message includes cask’s name (and new version, if applicable).
[ ] brew cask audit --download {{cask_file}} is error-free.
[ ] brew cask style --fix {{cask_file}} left no offenses.

Hello, I would like to check brew cask audit | style but I don't know how to change remote to my PR or my fork, from logs I can see that it is using master branch from origin

Hi @Morgaroth, thank you for contributing.
Since you already have set up your branch, the following should do it:
cd "$(brew --repository)"/Library/Taps/caskroom/homebrew-cask
git checkout Morgaroth-virtualbox-update

You can then double-check with brew cask cat virtualbox, this should confirm you are on the correct version. Then proceed to do audit and style.
You should normally not need to worry about remotes while you do that.

authors: Morgaroth claui


text:
Add ChronosPlayer.app v1.2

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if adding a new cask:

[x] Named the cask according to the token reference.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.
[x] Checked there are no open pull requests for the same cask.
[x] Checked the cask was not already refused in closed issues.
[x] Checked the cask is submitted to the correct repo.

Seems to be broken on 10.13

As this is your own app I'd suggest creating your own tap for now.
Thanks for the PR nonetheless!

authors: commitay nisar-med