Default workdir

Description of your problem
What steps will reproduce the problem?

Open the terminal

What is the expected output? What do you see instead?
As I am working on a project, I would expect to see the terminal opened on the project folder, not on the home directory.
Please provide any additional information below
It would be nice to change the default, or add an option so that the users can decide which folder should be opened by default.
Versions and main components

Terminal Version: 1.1.0
Spyder Version: 5.1.3
Python Version: 3.9.4
Operating system: Fedora 34 x86_64

Hi @frafra,
The current working directory when you open the terminal is different from your project? We could also add that option to our preferences page for our next release.

Hi @steff456,
that is correct. I tried to open spyder with spyder -p . and spyder -p $PWD, but the working directory is always set to $HOME. It would be a nice addition to have it set to the project folder in my opinion, as most of the commands would be executed on the files belonging to the project.

In your workflow, there's a way that you have the working directory in a different place than your project?
If so, I'm thinking that currently there's an option to open the terminal in the project directory in the hamburger menu. So maybe I can also add a shortcut to that action.

In my workflow, the working directory is always the project main folder. If I really need to browse around, I can use cd. Having a different default folder would be like showing the home folder in the directory view (left bar) instead of the project directory, in my opinion; it would look like a suboptimal default to me.
I think that just changing the default would be great, as it would be more consistent with Spyder tools. I see little use case for using a different working directory.

I think it's an interesting idea to open new terminals in the current project directory when a project is active. I mean, it's perhaps the most intuitive behavior.


License no longer BSD

Each license header include the following sentence that wasn't in the previous release.

If you have received this file from a source other than Adobe, then your use, modification, or distribution of it requires the prior written permission of Adobe.

This mean that redistribution of the source code is restricted, therefor this is no longer BSD 3-clause licensed source code, and other open source package that include that code are no longer allowed to do so.
The README is therefor misleading.

This came with #6

The license file has been updated in pr #17 to not have this clause like in the previous releases
But it is still in the various file headers which give the impression that the source code can't be redistributed, contrary to the BSD 3-clause

but the link to the license file in the Readme file is broken.
So where do we find it spelled out authoritatively?

@pawankishorsingh Please check this

This isn't part of the just release v2021.1 and this is really disappointing.

Hi @tester0077
The "link to the license file in the Readme file" has been fixed now. Please have a look again.

Hi @hfiguiere
In May-2021 when you had reported this issue, I had a discussion with Adobe Licensing Team and they instructed me that lets not change the terms in so many header files in existing code because that would be too much of an effort. But, in the new code that we write, we should use the new terms.
Considering that advise, I had not modified "all" instances where old language was used.
But since you explicitly mentioned the names of 6 files in this PR , I specifically made changes in these 6 files.
Hence, as of today, you are not seeing the new license text in "all" the places, but you'll find it well in place in these 6 files because you explicitly asked for those.
So, please don't be disappointed since we appreciate your contribution very much. We are considering your advise very well but we are taking a prudent/middle path.

All the headers include :

If you have received this file from a source other than Adobe,
then your use, modification, or distribution of it requires the prior
written permission of Adobe.

This goes against the BSD 3-clause because it prohibit redistribution, at least to my understanding as I am not a lawyer. In short the headers are incompatible with the license it claims it is under.
As I said in the original report this was added with PR #6. Nothing has changed since June 24 2020.
Previous version of the SDK like release CC 2016.07 didn't include that restriction.
It is not a "detail". This basically prohibit using XMP SDK in any piece of FLOSS software as it wouldn't pass the review of most of the license review in Linux distribution that care about license (Debian, Fedora, etc)
As the maintainer of "exempi" I can't update the base code to the XMP SDK because of this. So I'm stuck with CC 2016.07.
It was thrilled to see that the XMP SDK was now in a public git repository, but this is clearly a show stopper.
Now you say it is too much of an effort, so if I do the work and submit a PR to remove this clause will you merge it?

Hi @hfiguiere
I got your point.
There is another SDK release happening in Auguts-2021. I'll get the language updated in the headers. Please stay tuned for next release.

I have to agree with Hubert; as I received the original code from adobe, I
could use the old code, but will never be able to use any
'improvement/updates from git
On Sun, Jul 25, 2021 at 11:00 AM Pawan Kishor Singh <
@.***> wrote:

Hi @hfiguiere https://github.com/hfiguiere
I got your point.
There is another SDK release happening in Auguts-2021. I'll get the
language updated in the headers. Please stay tuned for next release.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adobe/XMP-Toolkit-SDK/issues/16#issuecomment-886237252,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACFCLPGVAFCHDC7JBUI2O53TZRGLNANCNFSM4OGVTTPQ
.

Any progress? It would be awesome if you can publish the commits which fix this issue prior the August's release. So the non-fixed release v2021.1 does not repeat. I will be glad to verify and review these commits.
Without this issue being resolved we cannot include this project in future versions of RHEL/CentOS. :(

Hi @xsuchy
Here is the commit having this change- https://github.com/adobe/XMP-Toolkit-SDK/commit/f24b96f
Please verify & tell me if its fine?

Hi @xsuchy
Here is the commit having this change- f24b96f
Please verify & tell me if its fine?

Yes, this is great, thank you. Can we expect a new release soon?

Thanks. In coming 2 weeks you can expect new release.


Update auxlib, javalib, nativelib, nscplugin, ... to 0.4.2

Updates

org.scala-native:auxlib
org.scala-native:javalib
org.scala-native:nativelib
org.scala-native:nscplugin
org.scala-native:sbt-scala-native
org.scala-native:scalalib
org.scala-native:test-interface

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

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-native" } ]

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

Superseded by #9.


TabStructure

Hi there,
does anyone of you know how the TabStructe is build? I have tried alot to find it out by myself but I dont get it right. I already found the address of chat name "Local Chat" and "Server Log", however I cannot read the lines of the chat. Any help woud be nice.
I also tried to understand the written code of Tibialyzer but I did not help much much.
Thx.
Edit: I got it by now. If anyone else is intersted in knowing, just send me a msg :)
Thx anyway.

@Faceman8787 how did u do it? did u do it on tibia 11?

I looked up the file Tibialyzer/blob/master/Tibialyzer/Managers/MemoryReader.cs and read the code. Before the update there was a method which was reading thourgh the tabs. Now I just had a quick look over it and could not find it.
So no, I did not do it on tibia 11. Currently out of prem and time, thus I doubt I will do it in the next time.


Expose documentserver on threefold.tech [1]

Documentserver is now used from office.jimber.org. Office.threefold.tech should have its own documentserver on documentserver.threefold.tech.

[x] expose documentserver on documents.threefold.tech
[x] link communityserver to documents.threefold.tech

When using the opensource installation script https://download.onlyoffice.com/install/opensource-install.sh it is not possible to use the installed document server. When deleting and manually installing the documentserver it is possible to use it when hosted on a different subdomain.


[BUG] v2.11.0 crashes at first launch

Describe the bug
Fritter v2.11.0 crashes at first launch (never used the app before).
I tested the F-Droid version and it works fine.
To Reproduce
Steps to reproduce the behavior:

Launch the app for the first time

Screenshots

Device
Samsung A51, Android 11, Fritter v2.11.0

This also happens after updating from v2.10.0

Hmm, I can't replicate this but it looks like it's something different in SQLite between our devices: https://stackoverflow.com/questions/6268064/alter-table-drop-column-syntax-error-using-sqlite
I'll see if there's another way to fix this and push a fix ASAP

Same here!

Device: Redmi Note 4 (MIUI 11 - Android 7.0)

I've pushed what could be a fix, but as I'm unable to reproduce it, I can't test it 😢
Would someone on this thread please be able to download the APK, try it out, and report back here? You can download it here: https://github.com/jonjomckay/fritter/runs/2861680516
Thank you!

Would someone on this thread please be able to download the APK, try it out, and report back here? You can download it here: https://github.com/jonjomckay/fritter/runs/2861680516

Tried it. Bug fixed on my side. Everything works like a charm !

Would someone on this thread please be able to download the APK, try it out, and report back here? You can download it here: https://github.com/jonjomckay/fritter/runs/2861680516

Works fine for me as well!

I tested the hotfix but didn't work for me. This time the error was a bit different though. I will post the screenshot as soon as I can.
I have cleanly installed the app on my Sony Z3 Compact, LineageOS 17.1.

Sadly it didn't worked for me as well. But before trying the hotfix I tried to install back v2.10.0 and it was not possible, then I installed back v2.11.0. Maybe those actions interfered.

@Fs00 @desertproject  I think I fixed your secondary issues in 80332186be26fc55a1924547a2b98fb7dbd9926d - I noticed a couple more slightly different bug reports come in so hopped on that one too (thanks to those who reported!). I've tagged v2.11.1 so I'll close this for now, but please re-open if the fix doesn't work for you! Thanks all for your patience and understanding - open source rules 😄

@Fs00 I've just opened an issue to make the error text selectable - #166

I just tested the v2.11.1 and the bug has been fixed, thank you!

@Fs00 @desertproject I think I fixed your secondary issues in 8033218 - I noticed a couple more slightly different bug reports come in so hopped on that one too (thanks to those who reported!). I've tagged v2.11.1 so I'll close this for now, but please re-open if the fix doesn't work for you! Thanks all for your patience and understanding - open source rules smile

Thanks! That worked! I just needed to reload the subscription list.

Thank you! Can confirm that 2.11.1 fixed this issue on my end :D


provide a way for the user to securely enter the secret text when importing a wallet

Description
in wallets -> import wallet screen, the text entered by the user in the secret input box should be obscured so that it cannot be read by anyone near for the purpose of privacy.
this should apply also to any similar screen when entering a wallet secret or any sensitive information.
Implementaion
the HTML input element with type password can be used with an appended icon and callback to control the visibility.

Please verify and close

Verified
Branch: development
commit: d183ed697ec0e8aaf3209aa5e586419e82502c1f


Invalid number for a long hexadecimal number

I'm using "big-integer" as a way to polyfill BigInt for react-native (with expo). And everything seems fine except from when a library (I guess libp2p) tries to convert the following number:
let number = BigInt(0x7ae96a2b657c07106e64479eac3434e99cf0497512f58995c1396c28719501ee);

I get the following error:
Error: Invalid integer: 0x7ae96a2b657c07106e64479eac3434e99cf0497512f58995c1396c28719501ee

For information I have a shim.js file with the following:
if (typeof BigInt === "undefined") global.BigInt = require("big-integer");

The hexadecimal literal is converted to js number and this may cause precision loss, so you need to put it into quotes. Native BigInt does check that although.

The correct way to convert that number is like this:
bigInt("7ae96a2b657c07106e64479eac3434e99cf0497512f58995c1396c28719501ee", 16)

using a string and an argument telling what base the number is in, without the 0x at the beginning.

@peterolson However, looking at the BigInt Mozilla documentation: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt
The radius is not needed. If big-integer can act as a polyfill then shouldn't it provide the same API?

This library is acta as a thin wrapper over the native BigInt if the browser supports it, but it doesn't reproduce the same API. The API  is as described in the README of this project.


Add mumble registration related commands

Adds user-register, get-registered-user, and user-rename-registered commands. Registration deletion is handled by sending a rename command with an undefined name. I think filtering get-registered-user has to pull down the whole user list. Maybe it's better to just have a get-registered-list function instead or something.

Adds userId as synced property. This stores the registration id.
Instead of being a normal syncProperty, a variant syncPropertyWithMapper is used.
This is a hack I'm using for now, because the murmur server will return -1<PHONE_NUMBER>) on successful registration deletion. -1 values are mapped into undefined before syncing. I also ended up having to @ts-ignore to make this work. There should be a better way to do this.

For userRenameRegistered I'm not sure which packet to wait for. Currently I wait for a UserState packet but that might not work if the renamed user is offline.

Add register, deregister, renameRegistered methods on user. deregister and renameRegistered are registration dependent, so the user doesn't even need to be online. It might be better to include them somewhere else.

Don't merge yet, as tests are missing. Will fix after any changes. The linter is also broken on my machine.

Nice work! These are some useful commands :)

What kind of tests am I missing? I'm not sure what I can test in the .spec files other than the getter/setter for userid.

Can you rebase to master or resolve merge conflicts?

I took the liberty of taking parts of your code and making #732. Thanks for your contribution! <3 I'm closing this PR.


Update Settings “general”

Automatically generated by Netlify CMS

👷 Deploy Preview for koytak processing.

Name
Link

🔨 Latest commit
453e0eb257111528483072dc169c9bc25422a2f6

🔍 Latest deploy log
https://app.netlify.com/sites/koytak/deploys/65164a2c96ab2c00087ef951


bug: using set_theme is causing "low resolution" on some modules

Hi, thank you for this project!
I've noticed that after using the set_theme function, some of the modules become "low resolution".
Before

After

I've created a project to demo this.
Would you please let me know if there is a way to fix this?
> rustup --version
rustup 1.27.1 (54dd3d00f 2024-04-24)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.82.0 (f6e511eec 2024-10-15)`

Hi, thanks for reporting this issue! As far as I can tell, this is because catppuccin-egui defines a border color while the default theme does not, and the border isn't antialiased for some reason. This also came up in #23. Would you mind testing it with the changes in #76 applied (the no-border branch) to see if the bug persists?

@Stonks3141 Thanks for looking into this, I built the no-border branch and used the todo example to check against my demo project.
The result proves that removing the bg_stroke is the right thing to do. It is seemingly an anti-alias issue in egui


fix smartlock

In the current version the raw DeviceLockState property was not converted properly (would be true/false instead of 3, 4, 5. This leads to the Lock always reported as Unlocked here.
Also if the lock is manually locked/unlocked the DeviceLocked property was not updated correctly.

Function convertRawPropertyValue was removed from class Lock in branch develop.

I see. This just leaves the update to PropertyName.DeviceLocked when lock is changed manually.

Please look into comments above. (review)

I'm not sure that I am following you here. The only comment I am seeing is that convertRawPropertyValueis removed, since the method of Device is essentially doing the same. But that still leaves the updates to PropertyName.DeviceLocked - am I not right?

There are 4 more comments before the last one under the review...

I don't see any review tab or similar...
But since I can read your comment in the screenshot:
I will test again...

I removed also some unneeded emitting of "locked" events. Please try the latest develop branch and let me know.
Thanks!

@bropat I think you forgot to submit the review, since the screnshots show it as "Pending" :D (thx Github!)

I removed also some unneeded emitting of "locked" events. Please try the latest develop branch and let me know.
Thanks!

Hi @bropat
if these emitted events were needed, depends somehow on the way you want it to work I guess. I'll use our homebridge plugin as example:
If the user changed the state of the lock, we'll send the appropriate command to the client. Homebridge sets the target state of the log (e.g. "Locked" as Target; CurrentState will remain as "Unlocked").
The Plugin then waits for the state change... By now this is handled via the event "locked" from the device. Since this would just be emitted when the lock is truly locked (not just the command).
Now that the event is no longer emitted we'd have to fall back on the emitted property change (What we'll probably do anyway, since the "locked" event didn't support the "MECHANICAL FAILURE/JAMMED" state.)
So in short, I'd favour to get the "locked" event back, and if just for backwards compatibility and a little more clearer states. But really 'needed' are they not.
As for the updates to PropertyName.DeviceLocked: you're right. We tested and these seem to work, without the extra update.

Closed, since nothing to merge.


Naming conventions

Hey everybody!
About some renaming performed in preview 7. By https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members - DisableHealthChecks, DisableMetrics, DisableRetry, DisableTracing should be given noun phrase or adjective names as is mentioned. So the previous naming of these was the right one i think. Wasn't it? Disable as a word, is a verb. They should be transformed into methods, as DisableHealthChecks() whit internal business logic. Or transformed into non verbal word or phrase.
Greetings,
Petar

@sebastienros  could you share why in API review we decided to change these to negative sense (eg Tracing to DisableTracing)? Negative sense can be harder to grok (ie DisableTracing=true is little harder to read than Tracing=false)
It seems to me though that if they are negative sense then indeed according to the API guidelines they should be something like TracingDisabled.
@eerhardt

This tracks with my understanding of the conversation. The change was very deliberate

Sounds good.
Given we can not really change this now (last build complete) I'm going to close this. @pmdot, appreciate the call out though.


Update dependencies

github.com/fluxcd/pkg/apis/kustomize v0.7.0
github.com/fluxcd/pkg/apis/meta v0.18.0
k8s.io/apiextensions-apiserver v0.25.4
k8s.io/apimachinery v0.25.4
github.com/fluxcd/pkg/apis/event v0.2.0
github.com/fluxcd/pkg/runtime v0.24.0
github.com/fluxcd/source-controller/api v0.32.1
github.com/onsi/gomega v1.24.1
helm.sh/helm/v3 v3.10.2
k8s.io/cli-runtime v0.25.4

We can ignore the fuzz errors as it broke due to changes upstream, I will pick that up separately.


using bounds on the map

please how can i use coordinatinates such as { latitudeHi: 6.574999999999989, longitudeHi: 3.4000000000000057,  longitudeLo: 3.3874999999999886,  latitudeLo: 6.5625 } to dispaly an area on the map ?

@rayjadore check out setMapBoundaries in the react-native-maps documentation under "methods." I haven't used it myself yet, but it seems to fit your use case. Allows you to set northEast and southWest LatLng points.
If you simply want the map to be focused on a specific area when it loads, you should set the initialRegion, which requires, latitude, longitude, latitudeDelta, and longitudeDelta (delta is zoom level I believe.

@jamiesonbates How can we force the zoom in-out only focus to the center of the screen ?
Example: you gonna zoom in or out on the other edge of the screen but the map it's zoom focus only the center of the map.

When we zoom, The lat and long not change but only change the lat-delta and long-delta only.

Very old issue, closing. Please re-open if you still have it.


chore: upgrade to vite 3

For some reason, the docs build breaks (serving works fine), even though Vitepress still uses Vite 2. No idea, really...


Should OpenTracing be defined as layered architecture?

... continued from https://github.com/opentracing/opentracing.io/issues/111
cc: @yurishkuro @bensigelman @adriancole @rfonseca @maxwindiff

"tracing plane" slides


Agent on OpenTelemetry distribution is started with collector

Describe the bug
The Jaeger Agent in the OpenTelemetry distribution is currently embedding a collector
To Reproduce
Steps to reproduce the behavior:
$ go run ./cmd/agent --reporter.grpc.host-port=localhost:14250
2020-10-15T15:15:56.395+0200	INFO	service/service.go:396	Starting Jaeger OpenTelemetry Agent...	{"Version": "", "GitHash": "", "NumCPU": 12}
2020-10-15T15:15:56.396+0200	INFO	service/service.go:240	Setting up own telemetry...
2020-10-15T15:15:56.409+0200	INFO	service/telemetry.go:110	Serving Prometheus metrics	{"address": "localhost:8888", "legacy_metrics": false, "new_metrics": true, "level": 0, "service.instance.id": "3c7d822b-7b28-4e72-83a0-375ba143f468"}
2020-10-15T15:15:56.445+0200	INFO	service/service.go:277	Loading configuration...
2020-10-15T15:15:56.457+0200	INFO	service/service.go:288	Applying configuration...
2020-10-15T15:15:56.457+0200	INFO	service/service.go:309	Starting extensions...
2020-10-15T15:15:56.457+0200	INFO	builder/extensions_builder.go:53	Extension is starting...	{"component_kind": "extension", "component_type": "health_check", "component_name": "health_check"}
2020-10-15T15:15:56.457+0200	INFO	healthcheckextension/healthcheckextension.go:40	Starting health_check extension	{"component_kind": "extension", "component_type": "health_check", "component_name": "health_check", "config": {"TypeVal":"health_check","NameVal":"health_check","Port":13133}}
2020-10-15T15:15:56.457+0200	INFO	builder/extensions_builder.go:59	Extension started.	{"component_kind": "extension", "component_type": "health_check", "component_name": "health_check"}
2020-10-15T15:15:56.457+0200	INFO	builder/exporters_builder.go:308	Exporter is enabled.	{"component_kind": "exporter", "exporter": "jaeger"}
2020-10-15T15:15:56.457+0200	INFO	service/service.go:324	Starting exporters...
2020-10-15T15:15:56.457+0200	INFO	builder/exporters_builder.go:90	Exporter is starting...	{"component_kind": "exporter", "component_type": "jaeger", "component_name": "jaeger"}
2020-10-15T15:15:56.457+0200	INFO	builder/exporters_builder.go:95	Exporter started.	{"component_kind": "exporter", "component_type": "jaeger", "component_name": "jaeger"}
2020-10-15T15:15:56.457+0200	INFO	builder/pipelines_builder.go:207	Pipeline is enabled.	{"pipeline_name": "", "pipeline_datatype": "traces"}
2020-10-15T15:15:56.457+0200	INFO	service/service.go:337	Starting processors...
2020-10-15T15:15:56.457+0200	INFO	builder/pipelines_builder.go:51	Pipeline is starting...	{"pipeline_name": "", "pipeline_datatype": "traces"}
2020-10-15T15:15:56.457+0200	INFO	builder/pipelines_builder.go:61	Pipeline is started.	{"pipeline_name": "", "pipeline_datatype": "traces"}
2020-10-15T15:15:56.457+0200	INFO	builder/receivers_builder.go:235	Receiver is enabled.	{"component_kind": "receiver", "component_type": "jaeger", "component_name": "jaeger", "datatype": "traces"}
2020-10-15T15:15:56.457+0200	INFO	builder/receivers_builder.go:235	Receiver is enabled.	{"component_kind": "receiver", "component_type": "otlp", "component_name": "otlp", "datatype": "traces"}
2020-10-15T15:15:56.457+0200	INFO	service/service.go:349	Starting receivers...
2020-10-15T15:15:56.458+0200	INFO	builder/receivers_builder.go:70	Receiver is starting...	{"component_kind": "receiver", "component_type": "jaeger", "component_name": "jaeger"}
2020-10-15T15:15:56.458+0200	INFO	static/strategy_store.go:203	No sampling strategies provided or URL is unavailable, using defaults	{"component_kind": "receiver", "component_type": "jaeger", "component_name": "jaeger"}
2020-10-15T15:15:56.458+0200	INFO	builder/receivers_builder.go:75	Receiver started.	{"component_kind": "receiver", "component_type": "jaeger", "component_name": "jaeger"}
2020-10-15T15:15:56.458+0200	INFO	builder/receivers_builder.go:70	Receiver is starting...	{"component_kind": "receiver", "component_type": "otlp", "component_name": "otlp"}
2020-10-15T15:15:56.458+0200	INFO	builder/receivers_builder.go:75	Receiver started.	{"component_kind": "receiver", "component_type": "otlp", "component_name": "otlp"}
2020-10-15T15:15:56.458+0200	INFO	healthcheck/handler.go:128	Health Check state change	{"component_kind": "extension", "component_type": "health_check", "component_name": "health_check", "status": "ready"}
2020-10-15T15:15:56.458+0200	INFO	service/service.go:252	Everything is ready. Begin running and processing data.

Expected behavior
Only the UDP receivers should be enabled, and only the Jaeger exporter would be enabled. At most, the OTLP exporter would be enabled as well.

Closing as it's not relevant anymore.


Android version compatibility

Hi Chris,
Thanks for sharing this great plugin. Using it to track availability of voluntary firemen.
I am trying to make my app run on old Android devices (testing with a version 2.3.5, API lvl 10) and I noticed a dependency on API version 11 due to the use of Notification.Builder. The service crashes because of this. For reference, the crash message is:
java.lang.NoClassDefFoundError: android.app.Notification$Builder
at com.tenforwardconsulting.cordova.bgloc.LocationUpdateService.onStartCommand(LocationUpdateService.java:188)

I suggest indicating the minimum API level in the documentation. Is there a similar minimal iOS version?
Maybe you have some tips to avoid a crash on unsupported versions.
Thanks,
Cor

Hi, pinging this closed thread to let you know I've refactored Android and released it as a Premium Version:

Significantly improved battery performance.
No more in-plugin HTTP -- plugin now executes your javascript callback, just like iOS.

http://christocracy.github.io/cordova-background-geolocation/


Ubuntu 24.04

There is a dev container image for GitHub Actions, and it includes ubuntu-24.04 image if you wish, and also it reproduces this issue. Our (fluxcd/community) repo has already been upgraded from ubuntu-latest of 22.04 to 24.04, but the fork I tested my fix on did not get it yet!
That's why we had an issue testing #426 #425 #424 #428 which all failed 🏃 👟 💨
I will fix it in this PR, and do the upgrade explicitly so we know which image we are on while the phased rollout is underway.

Ref:

https://github.com/actions/runner-images/issues/10636
#428

I think now I've found out for sure that invoking python like #!/usr/bin/python is what's causing the problem.
We can upgrade all the way to Python 3.13 if we want now
Confirmed here:

https://github.com/actions/runner-images/issues/10636

Verified again that the changes in this branch are working, here:

https://github.com/kingdonb/community/actions/runs/12436540645

(I am going to remove the dev container because it did not turn out to be as helpful as I thought)

It was actually helpful, the dev container let me see what version of Python is the default in a new Ubuntu 24.04 with Python - but the actions-runner extra wasn't for testing github actions locally, it was for invoking github actions runners (with GitHub) on your deployed dev container. So I assume if we wanted arm64 self-hosted runners it would be useful, but for debugging a GitHub Actions in VSCode it was not so useful.
Still, a win for 👍 dev containers even if it's a loss for GHA debugging 👎 maybe there is some more intuitive way to use it that I did not see documented anywhere.

🏁 ✅

https://github.com/fluxcd/community/actions/runs/12436901473

It worked!


Status of inline keyword support in C

The page has the text:
The inline keyword is available only in C++. The __inline and __forceinline keywords are available in both C and C++.
However, the compiler appears to accept inline as a keyword when compiling C (not C++) code, as well.
Is inline supported (with standard semantics, assuming /std:c11 / /std:c17 are used)? It would be nice to state that in the documentation if so.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 09138391-a316-0222-7db1-3cd461316773
Version Independent ID: 2cd32c3f-d4c0-69b5-d09c-f8a2638f79e0
Content: Inline Functions (C++)
Content Source: docs/cpp/inline-functions-cpp.md
Product: visual-cpp
Technology: cpp-language
GitHub Login: @corob-msft
Microsoft Alias: corob

@shuffle2
GitHub ate my comment, the upshot of which was that, yes, the doc is out of date, and inline is supported in C in all modes since at least VS 2015.

Updates to the C++ article and the equivalent C language documentation for Inline functions are now available.


Mutually exclusive features in DataQualityPreset

When a dataquality report is calculated for a dataframe in which there are columns that are mutually exclusive (A is 'None/Null' when B is filled and vice-versa), the cramer_v correlation coefficient crashes. This can somwhat be circumvented in multiple ways (not using the preset and editing your data for the tests that calculate correlation coefficients: filling the None-values, omitting certain columns, etc.) but this is non-optimal and negate the power of how easily presets can be used right now, especially because it becomes impossible to include missingvalue-tests together with correlation-tests in one report.
I think this is relevant part of the traceback after calling report.save_html(...):
File "....venv\lib\site-packages\evidently\metrics\data_quality\dataset_correlations_metric.py", line 171, in _get_correlations
correlations_calculate = calculate_correlations(dataset, data_definition, sum(add_text_columns, []))
File "....venv\lib\site-packages\evidently\calculations\data_quality.py", line 404, in calculate_correlations
correlations[kind] = _calculate_correlations(dataset, num_for_corr, cat_for_corr, kind)
File "....venv\lib\site-packages\evidently\calculations\data_quality.py", line 392, in _calculate_correlations
return get_pairwise_correlation(df[cat_for_corr], _cramer_v)
File "....venv\lib\site-packages\evidently\calculations\data_quality.py", line 365, in get_pairwise_correlation
c = func(df[columns[i]], df[columns[j]])
File "....venv\lib\site-packages\evidently\calculations\data_quality.py", line 335, in _cramer_v
chi2_stat = chi2_contingency(arr, correction=False)
File "....venv\lib\site-packages\scipy\stats\contingency.py", line 333, in chi2_contingency
raise ValueError("No data; observed has size 0.")
ValueError: No data; observed has size 0.

I'm seeing the same error with evidently 0.4.15.


Add split mode to orcv2 support

Need to make this a better interface for forward...

Codecov Report
Base: 76.14% // Head: 76.01% // Decreases project coverage by -0.13% :warning:

Coverage data is based on head (a5dfec5) compared to base (ef61be2).
Patch coverage: 79.56% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #534      +/-   ##
==========================================
- Coverage   76.14%   76.01%   -0.13%
==========================================
  Files          18       18
  Lines        6749     6801      +52
==========================================
+ Hits         5139     5170      +31
- Misses       1610     1631      +21

Impacted Files
Coverage Δ

src/compiler.jl
76.83% <75.00%> (-0.09%)
:arrow_down:

src/compiler/orcv1.jl
72.50% <76.19%> (-4.43%)
:arrow_down:

src/compiler/orcv2.jl
63.93% <81.81%> (+1.07%)
:arrow_up:

src/Enzyme.jl
83.62% <100.00%> (+0.11%)
:arrow_up:

src/compiler/validation.jl
69.36% <0.00%> (-0.31%)
:arrow_down:

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


NIFI-4989 Made PutMongo able to use nested lookup keys, a query param…

… and multiple lookup keys.
Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x] Is your initial contribution a single, squashed commit?

For code changes:

[ ] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[ ] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

@pvillard31 Thoughts on merging this?

@MikeThomsen - can you have a look at this commit: https://github.com/pvillard31/nifi/commit/5a67aa152bf2844de6a9192bfb75a073e80a595b
I reworked a bit the tests to avoid "removing" a property while executing the tests. Basically, instead of having a shared instance of the TestRunner for all the test suite, I initialize one eache time (to be sure there is no conflict between the tests and to avoid issues in cases tests are not executed in the same order each time). Regarding your comment about the validation failing, it's because we're providing a default value "_id". Because of that the property will always return true to isSet(). Since we're adding a new property and the user needs to use one of the two, I suggest removing the default value: it does not break anything, and it "forces" the user to understand the choice the user is doing. Does that make sense?

I think that works. I'll try to find some time tonight to get that done.

@pvillard31 Can you merge your change so we can close this out?

Done, merged to master, thanks @MikeThomsen @zenfenan


[Doc] loading s3 using broker and files table function

Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[x] Doc
[ ] Tool

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

Please do not merge

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

Feedback from RD: Simplify the CREATE TABLE statements, several of the properties are not necessary, probably only the replica count is needed.

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

@Mergifyio backport branch-3.1


Failing to deserialize API response when translating audio with SRT output

Hi,
I'm attempting to translate audio directly into English (API).
When I set the response_format to Json, everything works correctly. However, when setting the response_format to Srt I encounter the following error:
Error: failed to deserialize api response: invalid type: integer `1`, expected struct CreateTranslationResponse at line 1 column 1

Am I doing something wrong?
Thanks!

Hello,
This sounds like new changes need to be synced for translations APIs as well from the spec. Recently similar was done for transcription APIs in #202

I think this may not be an issue any longer with recent release, can you verify please?

@64bit  I'm afraid it's not fixed yet.
When running client.audio().translate(request).await? I get this error
Error: failed to deserialize api response: invalid type: integer `1`, expected struct CreateTranslationResponseJson at line 1 column 1

whereas, when running client.audio().translate_verbose_json(request).await? I get this one
Error: failed to deserialize api response: invalid type: integer `1`, expected struct CreateTranslationResponseVerboseJson at line 1 column 1

Thank you for checking it again.
SRT response doesn't fit into any predefined types in OpenAI spec, aparently this was solved for transcribe too, same feature is now added for translate API via Audio::translate_raw when you need SRT reponse format
Please see https://github.com/64bit/async-openai/blob/main/examples/audio-translate/src/main.rs#L7
This is included in v0.23.1, hence safe to close this issue now.

Perfect, thanks!


jax.local_devices('cpu') raises strange error

In [2]: jax.local_devices('cpu')
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-a8d6c4ce9f8f> in <module>
----> 1 jax.local_devices('cpu')

~/packages/jax/jax/_src/lib/xla_bridge.py in local_devices(process_index, backend, host_id)
    401   if process_index is None:
    402     process_index = get_backend(backend).process_index()
--> 403   if not (0 <= process_index < process_count()):
    404     raise ValueError(f"Unknown process_index {process_index}")
    405   return [d for d in devices(backend) if d.process_index == process_index]

TypeError: '<=' not supported between instances of 'int' and 'str'

Ah actually the second argument is meant to be the backend...

Should we change it to raise a more informative error?

We could put a type check when we enter the function. I was just surprised at the signature.


Fix variant track labels

Before

After [no hover]

After [hover]

Modify overflow and positioning so variant labels show up.

Can one of the admins verify this patch?

This looks awesome! Does this apply to all the tracks or just variants?
Is there anyway we could do text overflow to be ellipsis so the user knows there is more extension?
(i.e. ALL_chr75000...)

Updated!

These changes should go in the hammerlab pileup


WIP: Feature/remove os ssh keys

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "feature/remove-os-ssh-keys" git@github.com:kubermatic/machine.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842356634208
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.


merge from arlac77/template-github,arlac77/template-kronos-module

package.json

fix(engines): add >=13.12.0 remove >=13.11.0 (engines.node)

.travis.yml

chore(travis): (jobs.include)
chore(travis): add 13.12.0 remove 13.11.0 (jobs.include.node_js)

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


fix README

fastify.register(httpsAlwaysPlugin, httpsAlwaysOpts);

for typescript instruction.
Thanks for your plugin!

Thanks for your report. What is your question though? The instructions are correct. Are you seeing an error? Please add to this report if so.

Sorry, I didn't describe clearly. It's a minor typo, I thought.
In README.md, you provide instruction for typescript
import Fastify from "fastify"
import httpsAlwaysPlugin, {HttpsAlwaysOptions} from "fastify-https-always"

const fastify = Fastify({
    trustProxy: true
})

// leave out options whose default is suitable
const httpsAlwaysOpts: HttpsAlwaysOptions = {
  productionOnly: false,
  redirect: false,
  httpsPort: 8443
}

fastify.register(allowPlugin, httpsAlwaysOpts)

We see the last line:
fastify.register(allowPlugin, httpsAlwaysOpts)
There is no allowPlugin, but httpsAlwaysPlugin, so I change it to fastify.register(httpsAlwaysPlugin, httpsAlwaysOpts); and it works.
I'm not sure if it is fastify-version dependent though. Thanks!

Oooh, right. Thanks for clarifying! I cloned another fastify plugin I wrote called fastify-allow but didn't update the references completely.


Main content

contains cards in a grid

Component: Image Card -> Opens to description and title.
Component Writing Card -> Title / time / date / excerpt
Organized into 2 horizontal scroll bars whole page.


[GradlePluginPortal] add gradle plugin portal

Closes #1125

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @anatawa12!

  Generated by :no_entry_sign: dangerJS against 7ba795b50639af870a31adc37f6f6d5c52665490

I don't think I understand the nuances of the java ecosystem well enough to have much of an opinion on this so I'll defer to your judgement @PyvesB  but a couple of things that occur to me:

If this is essentially a subset of maven (I'm assuming this given you say we could also solve this with documentation), could we implement this as a redirect route to the maven badge?
If we want to include grade plugin as a different implementation, we could at least pull out the schema and the logic in handle() into shared helpers which both gradle and maven share which would make the implementation pretty thin

If we want to include grade plugin as a different implementation, we could at least pull out the schema and the logic in handle() into shared helpers which both gradle and maven share which would make the implementation pretty thin

In my opinion, This solution is better because maven-central and gradle plugin portal are same except for url syntax and label. It may also good to put logic for maven-metadata into shared helpers. Both maven-metadata and maven-central have same schema for xml. I don't know why not currently but maven-metadata should also have version prefix so It's good to mix into single logic.

In my opinion, having gradle logo by default is good. However, by the CONTRIBUTING.md, It looks not allowed. What do you think to have gradle logo by default? Is it allowed to have gradle logo in example?

@PyvesB I'm sorry long time no response. I made gradle-plugin-portal as a redirector. Could you check my code? and Should I rewite maven-central with redirector?

Quite a lot of my plate at the moment, but I'll try to review this as soon as possible. If you want to refactor maven-central as well, I would suggest doing that in a follow up pull request. 😉


needFullyMet is emptystring in all records

Is this an error with the parser, or is it truly emptystring in all samples?

May be an error.

On Mar 30, 2015, at 6:32 PM, Charlie DeTar<EMAIL_ADDRESS>wrote:
Is this an error with the parser, or is it truly emptystring in all samples?
—
Reply to this email directly or view it on GitHub.


1.3.0 release

Tracking here. Goal to do this tomorrow. Order of business is:

[x] Delete augment from decorator-refactor
[x] Merge distributed_prototype (@skrawcz)  (https://github.com/stitchfix/hamilton/pull/47)
[x] Rebase, merge decorator-refactor (@elijahbenizzy) (https://github.com/stitchfix/hamilton/pull/28)
[x] Rebase, merge fix-inputs (https://github.com/stitchfix/hamilton/pull/56)
[x] Rebase, merge stefan/refactor_visualization (@skrawcz) (https://github.com/stitchfix/hamilton/pull/58)
[x] Create a candidate release
[x] Run some tests in internal tooling
[ ] Add any documentation required (@stefan)
[x] Announce on discord
[x] Add 1.3.0 commit
[x] Publish library

Just need to work on documentation now!


Nx Generate (Ui): use current folder

If I start the Nx Generate (Ui) [@nrwl/nest:service] from a subfolder in my app, eg. app/user-backend/src/app/user the files are generated to app/user-backend/src/<name>/<name>.service(.spec).ts.
Is it possible to autofill the directory field according the the context from which the  Nx Generate (Ui) was started?
In this case app/user would be the right value with flat checked.

I auto fill path and project fields according to the context from which the Nx Generate (Ui)

it's the same behaviour that we have for the vscode extension.

Do you have an empty path?
why the app/user is the right value and not apps/api/src/app/user?

I auto fill path and project fields according to the context from which the Nx Generate (Ui)

it's the same behaviour that we have for the vscode extension.

Do you have an empty path?
why the app/user is the right value and not apps/api/src/app/user?


I have found that the postinstall should be "npm run build"

React Boilerplate
Thank you for contributing! Please take a moment to review our contributing guidelines
to make the process easy and effective for everyone involved.
Please open an issue before embarking on any significant pull request, especially those that
add a new library or change existing tests, otherwise you risk spending a lot of time working
on something that might not end up being merged into the project.
Before opening a pull request, please ensure:

[ ] You have followed our contributing guidelines
[ ] Pull request has tests (we are going for 100% coverage!)
[ ] Code is well-commented, linted and follows project conventions
[ ] Documentation is updated (if necessary)
[ ] Internal code generators and templates are updated (if necessary)
[ ] Description explains the issue/use-case resolved and auto-closes related issues

Be kind to code reviewers, please try to keep pull requests as small and focused as possible :)
IMPORTANT: By submitting a patch, you agree to allow the project
owners to license your work under the terms of the MIT License.
"npm run build:clean" resulted in there not being a build.

Coverage remained the same at 98.947% when pulling 1ace72b49f15398f5c9c3fa77f58ef09044033c8 on mikeodell77:patch-1 into 4487d298980ed002a7423c46bebe880ad4de81a2 on mxstbr:master.

Updated to go against dev branch

This isn't quite the right solution. What we really want is to use the heroku specific heroku-postbuild step, which we have an open PR for... somewhere. Will be updated soon! 😉

Fair enough. However, it would be nice to note that the current documentation is wrong and no longer in line with the actual package.json file. I spent a fair bit of time trying to get my project deployed to heroku.
Thanks for the good work. I do like the project!


resource/nifcloud_dhcp_config: Add resource

Description

Add nifcloud_dhcp_config resource.
Close #8

How Has This Been Tested?

[x]  Buld with make install command, and Apply example.

make install
cd examples/dhcp_config
terraform init
terraform plan
terraform apply

Types of Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Refactoring (improves code quality but has no user-facing effect)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation

lgtm

lgtm


added logging

this is a cosmetic fix (doesn't change outputs, except for log files)
the logs printing were screen were an eyesore for some time, so went through and tried to add logs to any rules that were doing this

I ran a test on real data to confirm earlier so should be good


Android Basics: Lunch Tray app

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-training-project-lunch-tray?authuser=1&continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-kotlin-unit-3-pathway-4%3Fauthuser%3D1%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-training-project-lunch-tray#2
In which task and step of the codelab can this issue be found?
I just need help in fragment_entree_menu_xml
Describe the problem
android:checked="@{viewModel.entree.equals(viewModel.menuItems["cauliflower"].name)}"
android:onClick="@{() -> viewModel.setEntree(viewModel.menuItems["cauliflower"].name'
This is how I tried to set checked and onClick attribut for this view but it didn't work. Please, I need help.
Thanks in advance for your helps.

Hi esperantgada,
I had the same problem and I did this:
android:onClick='@{() -> viewModel.setEntree("cauliflower")}' android:checked='@{viewModel.entree.name.equals(viewModel.menuItems["cauliflower"].name)}'
I hope it was useful for you.

Thank you very much. It works.

Hello sir, I hope you're doing great.
Thank you so much for your help. It works. I'm really glad.
See you soon!!
Le mer. 29 déc. 2021 à 14:11, Aaron Socas Gaspar @.***>
a écrit :

Hi esperantgada,
I had the same problem and I did this:
android:onClick='@{() -> viewModel.setEntree("cauliflower")}'
android:checked='@{viewModel.entree.name.equals(viewModel.menuItems["cauliflower"].name)}'
I hope it was useful for you.
—
Reply to this email directly, view it on GitHub
https://github.com/google-developer-training/android-basics-kotlin-lunch-tray-app/issues/11#issuecomment-1002587498,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUQXLZHJLODD4MJXRYJPW4DUTMCG7ANCNFSM5KZEYEXA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
<google-developer-training/android-basics-kotlin-lunch-tray-app/issues/11/1002587498
@github.com>

Hey @alu0100207385, I don't think we actually need android:checked parameter. Since they are in a radio group they are bound to only have 1 radio button checked at once. android:onClick works fine in that case too.

I don't think we actually need android:checked parameter.

Not setting android:checked introduces a small bug where if you go back to the start page via the back button instead of the cancel button, previously selected items aren't pre-selected when you come back to the radio groups. Otherwise, if you don't go back to the start page it seems to work fine.

@esperantgada i believe you should change the outer double quotes to single.
android:checked='@{viewModel.entree.equals(viewModel.menuItems["cauliflower"].name)}'


🐞 [Bug]: Farmerbot Go, failed to read message

What happened?
When running the farmerbot go on a full vm (playground, ubuntu 22.04 and wireguard), with .env and config.yml files set, I get this message error:
3:44PM ERR failed to read message error="read tcp <IP_ADDRESS>:47130-><IP_ADDRESS>:443: use of closed network connection"
3:59PM ERR failed to read message error="read tcp <IP_ADDRESS>:58268-><IP_ADDRESS>:443: use of closed network connection"
It might be worth investigating, or not.
which network/s did you face the problem on?
Main
Relevant log output
3:44PM ERR failed to read message error="read tcp <IP_ADDRESS>:47130-><IP_ADDRESS>:443: use of closed network connection"

I see a lot of the same error message when running farmerbot. Seems to happen basically every five minutes when the farmerbot does it's cycle and attempts to connect to the relay.


Assign project LIFE RIPARIAS

Once we have a LIFE RIPARIAS project on GBIF, remember to assign it to this dataset as well.

See https://github.com/riparias/vmm-rattenapp-occurrences/issues/11

Done. Thanks, @LienReyserhove: see https://www.gbif.org/dataset/4ba6a4ac-bf1c-4631-a6d5-4f2d29d22e40/project


database-backed Queue Worker does not enforce its minimum resolution of 1s

Laravel Version: 5.2, 5.3
PHP Version: 5.5
Database Driver & Version: PostgreSQL

Description:
The queue worker has an implicit limit on its queue sleep variable in that it can't be specified in non-integer seconds.
getSeconds() calls getTimestamp(), which returns an integer, and the database table column is an integer:
https://github.com/laravel/framework/blob/5.3/src/Illuminate/Queue/Queue.php#L144
http://php.net/manual/en/datetime.gettimestamp.php
https://github.com/illuminate/queue/blob/5.3/Console/stubs/jobs.stub
This is not documented at https://laravel.com/docs/5.2/queues "Specifying Queue Sleep Duration" - that section should say you can't go below 1.0 in this case.
Confusingly enough, that whole section is missing from https://laravel.com/docs/5.3/queues
Furthermore, there's another bug in 5.2 caused by this: in case the worker throws an exception, the loop code doesn't actually handle that, it just runs the generic exception handler's report method and continues with the next iteration immediately.
This bug was fixed in 5.3 by adding the configured sleep inside the method that processes a job in daemons, cf.
https://github.com/laravel/framework/blob/5.2/src/Illuminate/Queue/Worker.php#L108
https://github.com/laravel/framework/blob/5.3/src/Illuminate/Queue/Worker.php#L139
It would be good if this was fixed in 5.2 or at least documented in 5.2 docs, because the consequences can be serious.
Steps To Reproduce:
For example, start a queue worker with sleep 0.5 and see how it doesn't actually process jobs problem.  Or break the worker's connection to the database server, and watch storage/logs/ disk quickly fill up with an endless stream of error messages (that by default have long stack traces).
Please fix this. TIA.

5.2 is not supported anymore and I don't seem to be able to replicate the problem on a 5.3 instance.
Please upgrade to 5.3 and report back if you have any problems.

I have already linked to specific code points from the 5.3 branch that say in no uncertain terms how the minimum resolution still exists in 5.3...
I see https://github.com/laravel/framework/blob/5.3/src/Illuminate/Queue/Console/WorkCommand.php has changed from 5.2, but I don't quite see any rule that would prevent one from specifying a float as sleep.
When you run artisan queue:work --queue=something --sleep=0.75, do you get an error?


Error when running php artisan migrate:fresh for PostgreSQL in Laravel 8.10.0

When trying to migrate freshly using a DB schema dump from Laravel 8.10.0 you will get an error while using PostgreSQL.
I have pinned the error back to a fix that was introduced in here in this PR: https://github.com/laravel/framework/pull/34711#discussion_r513763811_
The error output in the example case is:
The command "PGPASSWORD=$LARAVEL_LOAD_PASSWORD psql --file=$LARAVEL_LOAD_PATH --host=$LARAVEL_LOAD_HOST --port=$LARAVEL_LOAD_PORT --username=$LARAVEL_LOAD_USER --dbname=$LARAVEL_LOAD_DATABASE" failed.

  Exit Code: 1(General error)

  Working directory: /var/www/html

  Output:
  ================
  The input is a PostgreSQL custom-format dump.
  Use the pg_restore command-line client to restore this dump to a database.

No recreation steps are listed in your issue...

Also have you updated to the latest 8.x release. There was a bug related to this fixed recently.

Sorry, this was fixed in a patch that hasn't released yet. It will release tomorrow.


Streaming from camera is not supported in background for iOS

After giving permissions of background modes like - voice for IP , background fetch, audio (I tried all single and together as well). But as soon as app goes in background mode streaming stops automatically.
is there a way to handle streaming in background for iOS applications ?

Yes there is, please use the createAppBackgroundImageSource API. Apple does not allow GPU access in the background, which means it is not possible to continue to encode live video. This API lets you work around this limitation by continuing to broadcast live audio while looping pre-encoded video.


move_and_slide returns (0, 0) vector when pushing another kinematic body in 2D

Godot version:
v3.1.1.stable.official
OS/device including version:
Windows 10 Pro
Issue description:
When moving a KinematicBody2D (pusher) that programatically moves another KinematicBody2D (pushee), move_and_slide (of pusher) returns a (0, 0) vector even though its position is moving.
Steps to reproduce:

Create a KinematicBody2D for the pusher and add input movement.
Create a KinematicBody2D for the pushee and add a push function to move_and_slide itself when collided.
Print result velocity from pusher colliding with and moving pushee.

Minimal reproduction project:
bug.zip

First, as an easy fix for your issue, did you try to use a RigidBody2D for the pushee instead of a KinematicBody2D so you don't have to detect the collision and push it by script?
It's going to be difficult to fix this issue without a hack because what's happening is the expected behavior. During the same frame, the pushee and the pusher are moved by the same velocity using move_and_slide. But their position in the internal physics simulation is not instantly updated, which causes the pusher to always detect a collision with the pushee during the same frame and return a velocity of 0,0.

First, as an easy fix for your issue, did you try to use a RigidBody2D for the pushee instead of a KinematicBody2D so you don't have to detect the collision and push it by script?

Yes, I actually started with a RigidBody2D as the pushee but found that the pushee moves too freely. I'm creating a top-down RPG and wanted a very simple push mechanic where the pusher and pushee move at the same pace and only in cardinal directions (except when pushed diagonally from corners). I don't really need the physics engine in my game so I didn't want to over complicate things by configuring it and RigidBody2Ds for a very simple push mechanic.

It's going to be difficult to fix this issue without a hack because what's happening is the expected behavior. During the same frame, the pushee and the pusher are moved by the same velocity using move_and_slide. But their position in the internal physics simulation is not instantly updated, which causes the pusher to always detect a collision with the pushee during the same frame and return a velocity of 0,0.

I figured as much. The velocity of 0,0 (even though the pusher was moving position) did trip me up while I was debugging a completely separate issue that I was able to resolve.
I created a bug report for the 0,0 velocity since, without knowing the internal details of the engine, I assumed KinematicBody2D's move_and_slide would always return a velocity if it moved position in a frame and I couldn't find any external indicators of why it was returning velocity 0,0. Feel free to do what you wish with this bug report if the engine is working as expected.

Thanks for sharing more details, it helps understanding what you're trying to achieve.
Can you try to set the pushee as a RigidBody2D again with these parameters?
Mode: Character (can't be rotated)
Gravity Scale: 0 (not affected by gravity)
Linear Damp: 128 (stops immediately when not pushed)
The result looks very similar to what you had and you'll get the correct velocity from move_and_slide for the pusher. Let me know what you think!

Yes, that does make make the pusher and pushee behave the same way, thank you.
Although, the setup I have now (with only KinematicBody2Ds and StaticBody2Ds) has it so that the pushee is prevented from moving through collisions with other KinematicBody2Ds and StaticBody2Ds. Is there a setting to prevent the pushee as a RigidBody2D from moving through collisions with other RigidBody2Ds and StaticBody2Ds while still being collided with by the pusher?

@afable: Physics layers should do the trick, although I'm not sure where to look for them in 2D (I only used them in 3D)

@afable: Physics layers should do the trick, although I'm not sure where to look for them in 2D (I only used them in 3D)

Thank you! Setting them all in the same collision layer and mask do help with RigidBody2Ds colliding with other RigidBody2Ds. Unfortunately, they still seem to move through StaticBody2Ds and KinematicBody2Ds.
I suspect I would have to programmatically detect collisions in pushees and turn off KinematicBody2D's move_and_slide's infinite_inertia flag when there are multiple collisions happening for one cardinal direction (but still allow another cardinal direction such as pushing a pushee diagonally against a wall). I don't want my pusher to be able to push objects into walls.
My current setup with only KinematicBody2Ds and StaticBody2Ds behaves as desired although if I could make RigidBody2Ds behave the same with simply configuring its settings I would go that route (I really dislike my Scene List having both my Player and pushable objects listed with the same KinematicBody2D icon).

Closing, because move_and_slide() returning Vector(0, 0) is the expected behaviour when colliding perpendicularly with another KinematicBody or StaticBody.

I figured out how to avoid zero-velocity when calling move_and_slide after the KinematicBody2D has been pushed by another KinematicBody2D!
Before you call move_and_slide, call move_and_collide(Vector2.Zero). I don't know exactly how, but it works! Be careful, there may be side effects!


Failed to find libhdf5.h during instalation

Hi!
I've tried to build your client on my local computer inside clear virtualenv. On the ubuntu 16.04 it failed with following error:
In file included from /tmp/easy_install-bwpD2f/h5py-2.7.0rc2/h5py/defs.c:470:0:
/tmp/easy_install-bwpD2f/h5py-2.7.0rc2/h5py/api_compat.h:27:18: fatal error: hdf5.h: No such file or directory
compilation terminated.
error: Setup script exited with error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

After few tries I've fixed this error by manually installing h5py package with pip. And it seems something strange - h5py exist inside setup.py install_requires list, but was not installed correct way.
Maybe this info will be helpful for you for future development.

Oh weird. So you have install via pip install hdf5 and then  pip install aetros did work?

No, it related to Installation development version.
Steps to reproduce(i've just checked again)
$ git clone https://github.com/aetros/aetros-cli.git
$ cd aetros-cli
$ virtualenv -p python .env
$ source .evn/bin/activate
$ python setup.py install
...
# exception raised

If previous to python setup.py install install h2py manually all works fine:
$ pip install h5py
$ python setup.py install
...
# installation completed successfully

I have no idea why this happen.
Also I've noted that during h5py installation numpy also was installed. So prior setup.py h5py and numpy already exist. Maybe it can be related somehow.

That is really weird. python setup.py install should actually install anything we have declared as dependency. We have no special building routine, just a few regular python libraries as dependency. If they don't get installed automatically I guess it's an issue with pip.

Okay, we added make dev-install which should now install correctly all dependencies.


How to order inserts?

I have seen https://github.com/vuex-orm/vuex-orm/issues/308
Is there a better way to manually enter data?
I am pulling from an API and it is a bunch of nested data already sorted how I want it, sorted relative to each level.
So, the default orderBy is not sufficient for what I need it to do.
I want to be able to insert data at a certain level in my nested structure and have it be pushed to the top.
Also,
inserts like
        Model.insert({
            data: {
                children: [obj1, obj2],
            },
        });

doesn't add any items to children when I do Model.find/query. children is hasMany.
I believe this is also related to https://github.com/vuex-orm/vuex-orm/issues/430
Do you happen to have any complex examples with deeply nested relationships? I have gone through the docs and test cases and multiples variations to get this working properly and it always seems I keep having issues getting it to work.

@cdrandin You can't keep the orders from the API at the moment. You need to preserve the order somehow by your self.
I think it would be nice to have such a feature, where we can preserve original orders somehow and retrieve back from the store. Need to come up with good API though.

doesn't add any items to children when I do Model.find/query. children is hasMany.

Do you have self-relationship too? I need code to look into more on this one.

Do you happen to have any complex examples with deeply nested relationships?

Not at the moment. I would really love to have that though!

@kiaking Here is some code https://codesandbox.io/s/vue-template-evb69
SO, I have 2 issues.
Issue inserting an item into a hasMany field
Could you help me find a way of inserting newComment into an existing item?
The source is at src/App.vue under methods as ormclick().
The current codesandbox has the issue in modifying an existing comment's children.
Issue removing an item from hasMany field (different model)
An oddity when dealing with hasMany but a different model. (NOT IN THE codesandbox)

class Community extends Model {
    static entity = "communities";

    static fields() {
        return {
            id: this.attr(null),
            user_id: this.attr(null),
            member_ids: this.attr(null),
            moderator_ids: this.attr(null),
            name: this.attr(""),
            is_private: this.attr(true),
            about: this.attr(""),
            thumbnail: this.attr(""),
            cover: this.attr(""),
            created: this.attr(""),
            created_by: this.belongsTo(User, "user_id"),
            members: this.hasManyBy(User, "member_ids"),
            moderators: this.hasManyBy(User, "moderator_ids"),
            privacy: this.attr(""),
            isMember: this.attr(false),
        };
    }
}

In my current project, I have a similar situation where I had to change members in a group, which I used hasMany as well, but for some reason, comment's parent_id (hasMany's FKs) is always null. I was only able to modify the member list in the group by modifying the foreign key list.
I had to do something like

  Community.update({
      where: this.community.id,
      data: {
          member_ids: this.community.member_ids.filter(
              (id) => id !== memberId
          ),
      },
  });

  // This doesn't work
  const members = this.community.members.filter((member) => member.id !== memberId)
  Community.update({
      where: this.community.id,
      data: {
          members: members, // list of users excluding the selected one
      },
  });

just to remove a user from the member list.

OK, I'm bit confused here. In the code, there is a comment saying "does not remove children from this comment". Is that what you want? Nither insert or update method will remove existing comment. You must delete existing comment yourself by the delete method.

@kiaking
Let me try to clarify.
In regards to the codebox, using the delete method will remove the item from children, however, this might not always be desired.
Using the above Community model. Lets say there are a few users in both moderators and members. UserA is in both moderators and members list. I want to remove UserA from moderators; using the delete method will also remove it from the members' list, which is not what I want.
Ultimately, I want to be able to modify items from the array, but currently, the only way I have been able to do that has been modifying the foreign keys, which feels working against vuex-orm.
From the sounds of things, this is not intended usage for vuex-orm?
Pseudocode for how I was expecting it to work
Community.create(data); // data filling all necessary fields in the model

// moderators and members each have the same # of users, however `UserA` is in both

// How I was expecting it to work
// 1) I want to remove all members from a model
Community.update({
    where: this.community.id,
    data: {
        members:[], // an empty array should translate to emptying the array
    },
});

// 2) I want to replace the current member list with 1 user
Community.update({
    where: this.community.id,
    data: {
        members:[{id: '1', username: 'UserA'}], // UserA is the only member
    },
});

// 3) Remove a user from the member list
Community.update({
    where: this.community.id,
    data: {
        members: this.community.members.filter((member) => member.username !== 'UserA'), // Only removing UserA
    },
});

Hopefully, this makes sense. If there is any confusion on what I am trying to ask specifically let me know.
It could very well be the case of usability.

@cdrandin Oh OK, thank you so much for the clarification!

Ultimately, I want to be able to modify items from the array, but currently, the only way I have been able to do that has been modifying the foreign keys, which feels working against vuex-orm.

I think this is the way to go in this case. I understand that you might feel this awkward but changing the relationship is to change the foreign key. We should have a better way, perhaps a method to do this, but Vuex ORM doesn't have it yet.

I'll be closing this issue due to inactivity. Please feel free to open another issue there's anything!


Add a logo design for HelpingHand

I will make the logo using Adobe XD and Adobe Illustrator :)
I will add the logo for HelpingHand in the navbar
Kindly assign me this issue under LGMSOC'21   :)

I will make the logo using Adobe XD and Adobe Illustrator :)
I will add the logo for HelpingHand in the navbar
Kindly assign me this issue under LGMSOC'21 :)

Sure

I will show you once the logo
Then I will implement it :)

@soumita1234
I will show you once the logo
Then I will implement it :)
Yea sure. This would be good !!

This is the logo :D
PNG File :

This is the logo :D
PNG File :

Its really awesome.

Thanks :)
Can I implement it now

Thanks✨


Razor syntax updates

Fixes #13465
No giant rush on this (Friday :tada:). It can wait until next week.
Internal Review Topic (Razor syntax)
Internal Review Topic (Components)

Hopefully not as stinky as that steaming pile 'o 🐄💩 that I turned in last time. :smile:

Need feedback where the scenario only applies to Razor components, but I don't say so. 🙈
Need feedback where the scenario applies to both RP/views and Razor components but I say it only applies to Razor components. 🙉

Get away from #section-{x} bookmarks by escaping the @ symbol in section headings. Now, we can cross-link properly. For example, the section heading ### \@using can be cross-linked as <xref:mvc/views/razor#using>. Much better than ### @using (unescaped @) where we would end up with something like <xref:mvc/views/razor#section-7> and then we can't reorganize or insert new sections without breaking the numbered-by-DocFX section link.
Alphabetize the directives.
Adds a new Directive attributes section.
Engineering guidance (Ryan): @functions/@code aren't "code blocks." That language should be reserved for @{...} constructs.

Thanks for reviewing this so quickly ...

... the Razor syntax reference doc should remain a syntax reference, not an entry point for learning the language. You come to this doc to look up specific nuances of the language. It should be more syntactical in nature, and less expository.

I didn't edit the whole topic with that goal in mind. I was mostly concerned about our duplication of content and missing Razor syntax content. Now that I've made some headway with those problems, I'll turn my attention broadly to the coverage with your feedback in mind. Let's see if I can improve it on the 2nd draft of updates.

I'm concerned that some of the content we've moved into this doc is probably better left where it was.

When I moved things here, I thought that what I moved applied to both view/RP and component scenarios, and I tried to make the text and examples agnostic to that distinction. When I get into your feedback, I'll see which parts look like they should return to the Components topic.

I agree with @NTaylorMullen that we need to make it super clear in this doc which Razor language features are supported in .cshtml vs .razor.
This scenario only applies to Razor components (.razor).
This scenario only applies to MVC views and Razor Pages (.cshtml).

 Tomorrow (Sunday), I'll step out and address the broader feedback on tightening up the language throughout the Razor syntax topic.
I'll ping ya when it's ready for another :eye:.

@NTaylorMullen @danroth27 Ready for another :eye: ... I'll number these points to make it easy to respond ...

I think that I have the bits split better now between the Razor syntax and Components.

The call-outs for 'this is MVC/RP only' and 'this is for RC only' are here. No flourishes (graphics), but we can ask docs team management if you would like to pursue it.

Directive attribute content (e.g., @bind) has been reviewed in the Components topic, so I think we're ok there.

Didn't link the VB topic for loop directly in a lambda expression. Can't find a C# equivalent. Left that as-is for the time being.

"blocks" ... how shall I proceed? ...

... 'in the @( ... ) expression' 👍
... 'in the @{ ... } code block' 👍
... 'in the @functions directive' or 'in the @functions code block' (or drop 'code')?
... 'in the @code directive' or 'in the @code block'?

For ...

the intent is that the Razor syntax reference doc should remain a syntax reference, not an entry point for learning the language.

I read the whole topic, it seems ok. If you see something that you want to 🔪, I'll get to hack'in it out. :ear:

@danroth27 No giant rush, but this is blocking a couple of Blazor issues. I'm going to rebase the staging branch after we merge this and pick up with localization and globalization Blazor issues.
... going for a no-:boom: no-:cry: experience for Scott when he merges the staging branch later.

Thanks @danroth27 ... I'll go through now and revert the "block" changes.
If we manage to get this merged later this evening, then it will unblock my next round of work.

@danroth27 Ok ... I think that licked 😋 'um.

Thanks @danroth27 ... after I address anything that Rick turns up, I'll be moving on to globalization/localization issues this weekend. I hope to have that up by Monday morning.

Will some or all of these new Razor Components Razor syntax scenarios (perhaps just the directive attributes) be coming to a Razor Pages page or MVC view near you?!

Yes, it's certainly possible that this might happen.
The Razor Syntax doc is referential, where the individual section will often be referenced directly from other documents. For this reason I think it's better that each section to carry the note whether it applies generally or just to .cshtml/.razor.

Cool ... I recommend that we stick with the current layout.

I'll make the final round of updates this afternoon.


2.0 stable support

2.0 version of our API is now available on the production registry:
https://groups.google.com/forum/#!msg/orcid-api-users/s7jT29-fqRI/9d3Eos4MCgAJ

Hi!
Great to hear that, I'll try to find some time to implement the changes.
Cheers!

Hi, thank you for your package. I second this request. It would be great to see this update.
Here is the documentation of the 2.0 endpoints:

2.0 API Guide at ORCID Source
ORCiD update to xsd 2.0

@rcpeters @kaplun
Hi! The work in progress is available in https://github.com/ORCID/python-orcid/tree/2.0update
I do not have much time available, and it would great if sb could take care of updating the testsuite.
I believe the new version could have the number 1.0.0, but before releasing everything has to be properly tested. There is a change without back compability, the SearchAPI class has been removed, as after moving to 2.0 institution credentials are needed in order to get the token. Thus, SearchAPI functionalities are integrated into PublicAPI.

The 1.0.0 version is now available on PyPI


lithuanian translation

Why the hell have you opened another PR for the same thing ?! Closing, we need to continue in the previous PR.


markdown extension does not open relative links in remote env

I can reproduce it in Gitpod and VS Online. Relative links are not handled but passed through because scheme is http: https://github.com/microsoft/vscode/blob/db597dff739d46d487499c93fb765f6d98447ef4/extensions/markdown-language-features/preview-src/index.ts#L147

Please share steps to reproduce so that someone can try investigating this and potentially submit a PR

Unfortunately my free VS Online subscription run out 😬 But I could reproduce it by previewing any markdown file with a relative link to another file.

Can you please share repo steps for that? Also, what version of VS Code are you using?

Based on the description, I believe this is the same issue as #101203


More GUI elements for framework

Hello,
A fantastic framework you have here, very impressed!
I see that in the Banshee Engine itself you have standard GUI widgets like Tabs, Radio buttons etc. Any chance you can port those over to bsf as well? If the GUI widget library is complete, this will make it a lot more usable for 3D application development.
Thanks!

Radio buttons are present in bsf (GUIToggle with a toggle group assigned). I do wish to port the docking/tabbing system to bsf eventually, but I don't have a timeline for it yet.

@MartinMuzatko and I will be trying this weekend to embed bsf into Electron by passing a native handle to bsf. If all goes well and this can be used, it would entirely eradicate the need to tinker a UI system yourself. Regards, Fohlen


Refactor ESP32xx folder structure

This PR aims to refactor Espressif soc folders for all architectures, in order to match current Zephyrs standards and to better reflect ESP32 product line SoC and SiP.

Added some comments to previous (above) threads.

PTAL

Main issues:

CONFIG_SOC -> CONFIG_SOC_SERIES needs to be done with west.yml update to have it in sync with changes in HAL

Yes, part of the changes are in hal_espressif, and a manual run of west update is needed. As with any other PR, which depends on hal changes. The manifest change commit reflects that.

some devicetree changes are made twice (to one SiP variant, then to another)

See particular comments below.

SOC_ESP32C3 -> SOC_SERIES_ESP32C3 is not atomic

Commits for Xtensa and RISCV architectures were separated deliberately. If you wish so I can squash the 2 commits.

introduction of CONFIG_SOC_PART_NUMBER is not justified and this symbol seems not to be used anywhere

It is used to provide the SOC name string, which is intended for future use.

SOC_ESP32C3 -> SOC_SERIES_ESP32C3 is not atomic

Commits for Xtensa and RISCV architectures were separated deliberately. If you wish so I can squash the 2 commits.

Ideally there should be a separate (and only one) commit with s/CONFIG_SOC/CONFIG_SOC_SERIES/ change, for all the ESP32 boards (both xtensa and riscv) in the tree AND west.yml (since it assumes that change).  They just cannot be in separate commits, as that would break bisectability (and this is a single logical change anyway).

introduction of CONFIG_SOC_PART_NUMBER is not justified and this symbol seems not to be used anywhere

It is used to provide the SOC name string, which is intended for future use.

So no reason to keep that in single commit with all the other changes. One thing that is suspicious with the commits you created is that you mention several things in a list. Sometimes they need to go together, but in that case I think that stuff like 1) s/CONFIG_SOC/CONFIG_SOC_SERIES/, 2) CONFIG_SOC_PART_NUMBER introduction, 3) other stuff should all go separately.
Please also provide the reasoning behing CONFIG_SOC_PART_NUMBER introduction in the commit message. There needs to be a WHY provided. It might happen in the end that plans change and that you won't be using it. In that case it would be good to know WHY it was introduced in the first place and whether it is subject for removal (as part of refactoring / cleaning up). Another thing is that this probably should be part of separate PR, since introduction of new symbol (which is not even used) is not part of "Refactor ESP32xx folder structure" which this PR is mainly about. The smaller the PRs, the better.

Have you considered adding the renamed boards to the boards/deprecated.cmake file?
It would allow to build under the old name while getting a warning that the board was renamed.

Have you considered adding the renamed boards to the boards/deprecated.cmake file? It would allow to build under the old name while getting a warning that the board was renamed.

Thank you @str4t0m for pointing that out! I've updated the PR accordingly.

Two last comments:

there is still not a good rationale why CONFIG_SOC_PART_NUMBER is introduced, so please remove it for now and introduce it once there will be a use case for it

it will make commit diff a bit smaller, since it is not directly related to "refactoring folder structure"
this "part number" (which seems to be SoC or SiP name) should probably come from devicetree (e.g. derived from compatible string) instead of being set by Kconfig explicitly (it will make it easier to introduce new boards, since such hardware information will be put only in one place)

We decided to use the SOC_PART_NUMBER symbol in our port because of the following reasons:

the symbol has been introduced a long time ago and it is mentioned in the SOC contributing guideline in the examples
many other vendors are having it even without referencing it - check the soc/arm/atmel_* | nxp_* | cypress | silabs_* | infineon* | ti_*
it is handy for users as they can use the SOC string for runtime identification of their devices
it is not producing any code overhead

Two last comments:

there is still not a good rationale why CONFIG_SOC_PART_NUMBER is introduced, so please remove it for now and introduce it once there will be a use case for it

it will make commit diff a bit smaller, since it is not directly related to "refactoring folder structure"
this "part number" (which seems to be SoC or SiP name) should probably come from devicetree (e.g. derived from compatible string) instead of being set by Kconfig explicitly (it will make it easier to introduce new boards, since such hardware information will be put only in one place)

We decided to use the SOC_PART_NUMBER symbol in our port because of the following reasons:

the symbol has been introduced a long time ago and it is mentioned in the SOC contributing guideline in the examples

In ESP-IDF / HAL?

many other vendors are having it even without referencing it - check the soc/arm/atmel_* | nxp_* | cypress | silabs_* | infineon* | ti_*

Atmel - those symbols are used to select header files.
Cypress, NXP, Infineon - uses it for selecting files in HAL, so there is some use case for it.
In case of Atmel and NXP those symbols started to be used before devicetree was so widespread. I guess that now it would be better to generate those (even if at Kconfig level, but at least automatically/implicitly) from devicetree.

it is handy for users as they can use the SOC string for runtime identification of their devices

There are /model and /compatible in root devicetree node, based on which such message can be generated. Let's not introduce another place (Kconfig) which describes hardware model.

it is not producing any code overhead

If you mean flash footprint - agree. But it takes code in terms of Kconfig lines, which adds maintenance. As I said previously, this unnecessary adds another step in adding support for custom ESP32-based boards. It should be devicetree where SoC/SiP information is provided. If this information will be useful at Kconfig level, then a glue code based on Kconfig functions could be developed to set that automatically for each board (based on devicetree).
I am not convinced by above reasoning. And once again... introduction of CONFIG_SOC_PART_NUMBER has nothing to do with "refactor folder structure" commit.

In ESP-IDF / HAL?

In Zephyr board contribution guideline.

If you mean flash footprint - agree. But it takes code in terms of Kconfig lines, which adds maintenance. As I said previously, this unnecessary adds another step in adding support for custom ESP32-based boards. It should be devicetree where SoC/SiP information is provided. If this information will be useful at Kconfig level, then a glue code based on Kconfig functions could be developed to set that automatically for each board (based on devicetree).

That is actually not true as custom boards could use plain SOC_ESP33xx and specify their memories anywhere in the dts.

I am not convinced by above reasoning. And once again... introduction of CONFIG_SOC_PART_NUMBER has nothing to do with "refactor folder structure" commit.

I'm thankful for your in-depth review, but I'll let the TSC decide whether this should be removed or not. I already addressed all your valid change requests, and this one doesn't seem to be justified enough.

@henrikbrixandersen @nashif Hi, would you be able to take a look at this?

In ESP-IDF / HAL?

In Zephyr board contribution guideline.

I agree with @marekmatej, this is directly in our doc @mniestroj:
https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html#write-kconfig-files
config BOARD_PLANK
   bool "Plank board"
   depends on SOC_SERIES_YOUR_SOC_SERIES_HERE
   select SOC_PART_NUMBER_ABCDEFGH

I agree with @marekmatej, this is directly in our doc @mniestroj:
https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html#write-kconfig-files
config BOARD_PLANK
   bool "Plank board"
   depends on SOC_SERIES_YOUR_SOC_SERIES_HERE
   select SOC_PART_NUMBER_ABCDEFGH

I agree as well. I see no issue with introducing SOC_PART_NUMBER_* Kconfigs for ESP32xx, even if they are unused in upstream Zephyr/HAL.
We use SOC_PART_NUMBER_* for conditional compilation in our downstream applications for other SoCs.

@marekmatej FYI: This needs rebasing.

In ESP-IDF / HAL?

In Zephyr board contribution guideline.

I agree with @marekmatej, this is directly in our doc @mniestroj:
https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html#write-kconfig-files
config BOARD_PLANK
   bool "Plank board"
   depends on SOC_SERIES_YOUR_SOC_SERIES_HERE
   select SOC_PART_NUMBER_ABCDEFGH

I think the question is: where is this Kconfig option used? If not used please, just drop it regardless of what porting guidelines say. Guidelines contain examples that may not always apply.

In ESP-IDF / HAL?

In Zephyr board contribution guideline.

I agree with @marekmatej, this is directly in our doc @mniestroj:
https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html#write-kconfig-files
config BOARD_PLANK
   bool "Plank board"
   depends on SOC_SERIES_YOUR_SOC_SERIES_HERE
   select SOC_PART_NUMBER_ABCDEFGH

I think the question is: where is this Kconfig option used? If not used please, just drop it regardless of what porting guidelines say. Guidelines contain examples that may not always apply.

But what if downstream users want to make use of it? I think it's legitimate for a vendor to provide users with a string representation of the part number for downstream use.

I think the question is: where is this Kconfig option used? If not used please, just drop it regardless of what porting guidelines say. Guidelines contain examples that may not always apply.

We are talking about config SOC_PART_NUMBER right? The string one. If there's no solid use case we may as well drop it everywhere, one less thing to care about when porting. The boolean CONFIG_SOC_PART_NUMBER_... ones seems to be used and makes more sense.

For string representations, we already have CONFIG_SOC_SERIES (e.g. stm32f4), CONFIG_SOC (e.g. stm32f401xc) and some CONFIG_SOC_FAMILY, so I'm not convinced why we need yet another symbol. As I said, the question is why do we need those symbols.

These are used in soc.cmake to build up SOC_PATH, maybe SOC_PART_NUMBER was added as a logical extension of that but if it's not needed it's not needed.

We are talking about config SOC_PART_NUMBER right? The string one. If there's no solid use case we may as well drop it everywhere, one less thing to care about when porting. The boolean CONFIG_SOC_PART_NUMBER_... ones seems to be used and makes more sense.

Thank you for clearing that up. I was under the impression we were discussing the boolean CONFIG_SOC_PART_NUMBER_..., which I do find useful - and which are used in our downstream.
I agree that the string representation seem unused and superfluous.

I agree that the string representation seem unused and superfluous.

Yeah it's all a bit confusing, best as I can tell config SOC_PART_NUMBER is also not defined at top level but only by individual archs, won't go through the code archeology maybe it was used for something specific historically and now it's not anymore? There's a reference in modules/hal_infineon/mtb-pdl-cat1/CMakeLists.txt and that's it.

Ok, so those CONFIG_SOC_PART_NUMBER strings were added for downstream users so they can be used to identify the underlying hw. There is no other meaningful usage, except maybe creating the sample to code to use those strings as @carlescufi noted, but that would be very artificial justification.
So I'll remove those strings from the PR. Thank you all for your clarification.

Ok, so those CONFIG_SOC_PART_NUMBER strings were added for downstream users so they can be used to identify the underlying hw. There is no other meaningful usage, except maybe creating the sample to code to use those strings as @carlescufi noted, but that would be very artificial justification. So I'll remove those strings from the PR. Thank you all for your clarification.

I introduced CONFIG_SOC_PART_NUMBER many years ago to help integrate the Kinetis SDK, now called MCUXpresso SDK, into Zephyr. See commit<PHONE_NUMBER>87bab84224272815844a9f14dda60c. The pattern has since been copy-pasted to other SoC families.

@mniestroj, at the end I think we were mixing two different things - SOC_PART_NUMBER strings and bool flags. I was advocating for both! From your messages, I got the impression you wanted to remove both strings and flags. However, I must admit that having those strings for future use is not vindicated enough, so I apologize for the misunderstanding from my side.

This PR looks fine to me. I just have issues with SOC_PART_NUMBER (not critical though). Since others are good with it (based on the comments above) and overall this PR is bringing lots of net profit (thanks @marekmatej), then I will not stay in the way.

Just to be clear @mniestroj, SOC_PART_NUMBER has now been removed from this PR.

This PR looks fine to me. I just have issues with SOC_PART_NUMBER (not critical though). Since others are good with it (based on the comments above) and overall this PR is bringing lots of net profit (thanks @marekmatej), then I will not stay in the way.

Just to be clear @mniestroj, SOC_PART_NUMBER has now been removed from this PR.

Now we got confused... in this context I meant choice SOC_PART_NUMBER with bool SOC_PART_NUMBER_*.
string SOC_PART_NUMBER was removed, indeed. @carlescufi

This PR looks fine to me. I just have issues with SOC_PART_NUMBER (not critical though). Since others are good with it (based on the comments above) and overall this PR is bringing lots of net profit (thanks @marekmatej), then I will not stay in the way.

Just to be clear @mniestroj, SOC_PART_NUMBER has now been removed from this PR.

Now we got confused... in this context I meant choice SOC_PART_NUMBER with bool SOC_PART_NUMBER_*.
string SOC_PART_NUMBER was removed, indeed. @carlescufi

Aah, of course. The choice vs the string Kconfig :) But as you say others chimed in in favor of keeping the choice, so thanks for unblocking. Merging this now.