Vulkan: Add MoltenVK and portability to MacOS library names

Related issues, Discord discussions, or proposals
https://github.com/dotnet/Silk.NET/pull/1197#discussion_r1168295230
Further Comments
MoltenVK is (obviously) above portability, and while gfx-rs/portability is dead development wise, there are maybe people who want to package it with their app and use it for whatever reason, or end users who want to use it with some app, so lets shove it at the end of the libnames to check, since we are able to, and it shouldnt hurt anything, given the loader and Molten VK are prioritized

Can we not add libportability, I’d rather just only have MoltenVK and have it be for legacy reasons. Really we should be using the loader on all platforms but we (I) backed ourselves into a corner by Not Doing That.


Update fiori-tools-cap-modify-object-page

Updated fiori-tools-cap-modify-object-page to reflect new procedure for enabling flexible column layout

Hi tutorials team, it looks like this PR also copied over a failed commit from last week: https://github.com/sap-tutorials/Tutorials/pull/20851/commits/37443c1e858e1455f18ec0d8095ed83b505d72ec
This was actually handled already via this PR: https://github.com/sap-tutorials/Tutorials/pull/20847#event-8178753060
Please let me know if you need anything from my side. Otherwise, if it simply duplicates the changes and is harmless, please feel free to merge.

You could check in "Files changes" if you can see the changes from that commit. If they are part of this pull request, simply revert them and push again.

Sorry Michael, I'm not as familiar with GitHub PRs and reversion as some of my developer colleagues. From the VSC extension, I can revert the last change -- which reverted the change to fiori-tools-cap-modify-object-page. This is the change I'd actually like to make, but I understand why that occurred. This can easily be recommitted.
 Is there a more visual way to do this? I don't see options for commit reversion in the browser version of GitHub.

You can simply undo the changes locally within the respective files and push again. If you want to apply these changes at a later point, make a backup.

Thanks @MichaelCzcz. Here's the curious part, though -- those are changes I wanted but already made (and live) so I don't necessarily want to revert them. I'm not sure how they ended up in this PR. For example, here's the production tutorial: https://developers.sap.com/tutorials/fiori-tools-generate-project.html
Search for list report page. You'll find that it already reads list report page as in the changes, rather than the old list report object page .
Any tips? Or still revert them?

If you have already applied those changes earlier, you should do a fetch + pull (for both tutorials and Tutorials-Contribution) and push again and they should be automatically removed from your pull request.

Thanks @MichaelCzcz. I have done as instructed: fetch + pull and push for both tutorials and tutorials-contribution. Everything is shown as up-to-date. Can you safely merge here or do I need to open a new PR?


Migrate stdlib jsonutils module to module-ballerina-jsonutils repo

Purpose

$Subject

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.14 out of 15 committers have signed the CLA.:white_check_mark: ldclakmal:white_check_mark: gimantha:white_check_mark: wggihan:white_check_mark: pramodya1994:white_check_mark: ThisaruGuruge:white_check_mark: kalaiyarasiganeshalingam:white_check_mark: aashikam:white_check_mark: rasika:white_check_mark: rdhananjaya:white_check_mark: MadhukaHarith92:white_check_mark: daneshk:white_check_mark: riyafa:white_check_mark: mohanvive:white_check_mark: warunalakshitha:x: DimalChandrasiriYou have signed the CLA already but the status is still pending? Let us recheck it.


Multiple boundaries GIF image has incorrect final boundary

I hate to criticize this otherwise amazing GIF, but in the final frame, the red shape for the final searched area extends below the southern end of the bounding box (green). It has the effect of suggesting that we would ignore the bounding box in this case, which is of course false.

I see what you're saying. Good eye. The stuff in the red box shouldn't be included because it's out of the green stripe.

Ooops! My bad. I'll try to fix it tomorrow.
On Mon, Sep 28, 2015 at 9:46 PM Rhonda Glennon<EMAIL_ADDRESS>wrote:

I see what you're saying. Good eye. The stuff in the red box shouldn't be
included because it's out of the green stripe.
[image: image]
https://cloud.githubusercontent.com/assets/4380498/10155456/404f7916-662a-11e5-8cbd-6099fdb890d6.png
—
Reply to this email directly or view it on GitHub
https://github.com/pelias/pelias-doc/issues/11#issuecomment-143943251.

Fixed in PR #27


uncomment permission class

important hotfix to master branch to uncomment out the permission class for ExportProviderTask api endpoint permissions.

Coverage increased (+0.003%) to 80.684% when pulling 11f418bf37884e340b0013343578472f1f848586 on permissions-hotfix into 033d663f2cd87dcf6e03e6d1aea9198d87cf8517 on master.

Coverage remained the same at 80.733% when pulling caba3d82617336af39773b7b325d049906081756 on permissions-hotfix into 92aa0cbfceddd5786c33601eca8c3d7b10e3794a on master.

This has been merged in a different request.


Encoding API improvements

Some possible improvements for Encoding API (TextEncoder, TextDecoder) from pull review and discussion.
Documentation:

[ ] Note that Encoding API is a living standard, note the snapshot date in Guide

Testcases:

[ ] Basic encode/decode perf tests for ASCII and non-ASCII
[ ] ASCII encode/decode, all UTF-8 codepoint lengths
[ ] Exhaustive encode/decode test for all valid UTF-8 codepoints
[ ] Invalid UTF-8: initial bytes, non-shortest encodings
[ ] Extended UTF-8 codepoints above UTF-8
[ ] Random data for encode/decode
[ ] Exhaustive argument types
[ ] Stress test: 16 megabytes of random bytes, fed 1 byte at a time, random sections at a time
[ ] Property attributes; difference between IDL-based and core Ecmascript
[ ] Maximum expansion for encode/decode
[ ] More comprehensive BOM tests

Features:

[ ] Check 'label' argument of TextDecoder constructor, throw if not UTF-8 (or any of its variants)
[ ] Ensure label handling matches specification, e.g. strip whitespace, compare case insensitively (or just normalize before comparison)
[ ] Remove DUK_USE_ENCODING_BUILTINS from lowmemory config
[ ] Check 'encoding-api' tag in tags.yaml
[ ] Property attributes recheck; due to genbuiltins.py RAM init data limitations property attributes don't currently match e.g. Firefox (documented in original pull)
[ ] Size optimization improvement for DUK_USE_PREFER_SIZE
[ ] Performance: table driven decoding
[ ] Performance: encode/decode fast path for ASCII
[ ] builtins.yaml property attributes for global TextEncoder and TextDecoder
[ ] duk_bi_textdecoder_prototype_decode() behavior for arg 2 null/undefined?
[ ] Should decoder accept e.g. Float64Array as it now does? If so, what should that do?
[ ] Encoder uses duk_decode_string() now, maybe explicit (stricter) CESU-8 decoding?
[ ] Use a shared internal property name (_Value is already used for example) for context?

Misc internal helpers and such:

[ ] Ability to reject non-constructor calls automatically based on a function object flag would be nice (also for public API)
[ ] duk_get_prop_string_toboolean()
[ ] duk_get_this_string()

duk_bi_textdecoder_prototype_decode() behavior for arg 2 null/undefined

I actually checked IDL for this one - it's essentially treated as an empty dictionary (use defaults for all members).

Should decoder accept e.g. Float64Array as it now does? If so, what should that do?

Admittedly that doesn't make much sense.  However the Encoding standard specifies the argument as BufferSource - meaning any typed array or ArrayBuffer.
Does it work in Firefox and/or Chrome too?  I'm not home now so I can't check.

So correct behavior is to check for null/undefined, but accept strings, numbers, etc?
In particular, setting String.prototype.stream = true and calling decoder.decode(u8array, 'dummy') should work in streaming mode?

Firefox:
new TextDecoder().decode(new Uint16Array([ 0x4142, 0x4344 ]))
"BADC"

So yes, it seems the underlying bytes are used (in platform order).
Quite odd :)

Firefox doesn't accept e.g. a plain string as the decode options argument:
dec = new TextDecoder(); dec.decode(new Uint8Array([ 0xec, 0xab ])).charCodeAt(0);
65533
dec = new TextDecoder(); dec.decode(new Uint8Array([ 0xec, 0xab ]), {stream:true}).charCodeAt(0);
NaN
dec = new TextDecoder(); dec.decode(new Uint8Array([ 0xec, 0xab ]), 'dummy').charCodeAt(0);
TypeError: Argument 2 of TextDecoder.decode can't be converted to a dictionary.

It does accept a String object and .stream can be inherited from String.prototype:
dec = new TextDecoder(); dec.decode(new Uint8Array([ 0xec, 0xab ]), new String('dummy')).charCodeAt(0);
65533
String.prototype.stream = true;
true
dec = new TextDecoder(); dec.decode(new Uint8Array([ 0xec, 0xab ]), new String('dummy')).charCodeAt(0);
NaN

So I'd guess it accepts null/undefined as "no options" (tested this) and otherwise requires an object. So, other plain types are rejected - not sure if that's correct w.r.t. IDL/WHATWG specifications.

Here's a nice test case :-):
new TextDecoder().decode(new Float64Array([ 5.386703426890001e+228 ]))
"o/ Hello"

Works in Firefox and Duktape at least, when the host is little endian :)

I think any value is acceptable for decode() arg 2 as long as its object coercible.  I'll double-check that later though.

That effectively means that every (standard) type is accepted because undefined/null are not object coercible (but are explicitly accepted) and all other types are object coercible.
In any case Firefox seems to disagree with this interpretation. Just checked with Chrome and it seems to agree with rejecting e.g. plain strings:
new TextDecoder().decode(new Uint8Array([ 0xec, 0xab ]), 'dummy').charCodeAt(0)
VM9140:2 Uncaught TypeError: Failed to execute 'decode' on 'TextDecoder': parameter 2 ('options') is not an object.(…)

Btw, the only thing I'm really after here is documenting the current behavior as a testcase to protect against accidental changes. Writing the test also forces one to figure out the expected behavior at least at that point in time. But it's really not all that important in practice of course :)

I assume this is the relevant clause:

If Type(V) is not Object, then throw a TypeError.
https://www.w3.org/TR/WebIDL/#es-dictionary

I gather that Type(PlainString) != Object. ;)

There's a memory safety / side effect issue in TextDecoder .decode() right now:

duk_require_buffer_data() obtains an input buffer pointer and length.
After that the decoding options are checked which involves a property lookup (potential getter side effect) and ToBoolean (potential side effect). Either side effect can resize the argument buffer invalidating the data pointer.

I'll fix this in a separate pull shortly.

@fatcerberus Re: replacement character behavior, this case is interesting:
duk> new TextDecoder().decode(new Uint8Array([ 0xed, 0xa0, 0x80 ]))
= "\ufffd\ufffd\ufffd"

The byte sequence in question is a CESU-8 encoded surrogate pair (= invalid UTF-8). Instead of producing a single replacement character this case generates one for each byte.
I guess this is correct because 0xed is not a valid initial byte so that generates a replacement. After that 0xa0 is also not an initial byte, etc.
I would intuitively expect this to generate just one replacement character though, but that's just from having used CESU-8. One might also assume that a UTF-8 decoder would be able to decode a three-byte sequence and then figure out it's in an invalid range - and then emit a single replacement for the whole 3-byte sequence. I know it's not well-formed UTF-8 but it's close enough in practical terms so that it could plausibly work this way.
Firefox agrees with the current behavior in any case which is good:
new TextDecoder().decode(new Uint8Array([ 0xed, 0xa0, 0x80 ])).length
3

If the TextDecoder implementation is following the WHATWG spec, then no other behavior is allowed.  The spec is very clear on that point.  Chrome/V8 behavior is most likely a bug.
Best I can tell the algorithm is designed to reject invalid byte sequences as early as possible.  Since UTF-8 can't legally encode surrogates and 0xED can't begin anything other than a surrogate, it's rejected as soon as the first byte.  The decoder then continues with the next byte, rejects that, etc.  Sometimes that generates more replacement characters than one would intuitively expect. :)

Chrome 53 also seems to agree with the above test result:
> new TextDecoder().decode(new Uint8Array([ 0xed, 0xa0, 0x80])).length
3
> new TextDecoder().decode(new Uint8Array([ 0xed, 0xa0, 0x80]))
"���"

As does Node.js 6.8.1:
> var out = new Buffer([ 0xed, 0xa0, 0x80]).toString();
undefined
> out
'���'
> out.length
3
> out.charCodeAt(0)
65533
> out.charCodeAt(1)
65533
> out.charCodeAt(2)
65533
>

So we won't surprise any developers with this, at least. :)
Interestingly, the only time Chrome/V8/Node.js seems to differ so far is for truncated sequences.  I suspect that is a V8 bug--or perhaps a misreading of the spec (backtracking too much, e.g.).

Yep, buf.toString() ultimately calls the V8 API String::NewFromUtf8() to decode the buffer.  This took a bit of digging to find:
https://github.com/nodejs/node/blob/master/src/string_bytes.cc#L632-L635

Found something interesting (Chrome 53):
> new TextDecoder().decode(undefined)
""
> new TextDecoder().decode(undefined, {})
VM571:1 Uncaught TypeError: Failed to execute 'decode' on 'TextDecoder': The provided value is not of type '(ArrayBuffer or ArrayBufferView)'(…)

That's quite puzzling behavior.

@fatcerberus I was under the impression that WHATWG didn't specify the exact replacement character algorithm because there are multiple allowed alternatives for a UTF-8 decoder. Is this correct?

I think the intent of the specification is similar to the very strict requirements for JSON - in other words, to ensure encoded text (invalid or not) is treated identically across all clients.
But yes, that bit you quoted is what I was referring to when I said the spec was very clear on the permitted behavior. :)
The HTML5 specification is similar from what I understand, laying out exactly what browsers must do when encountering invalid HTML (unclosed/broken tags, etc.), effectively standardizing quirks-mode.

I like that WHATWG approach here and it's not really standardizing quirks but removing unnecessary variance in actually needed functionality. Good :)
Re: HTML5 IMO they should really have gone the XHTML way (= refuse to make the quirks official)... But I probably don't see the whole picture from a browser maker's perspective.

Feature idea: Class numbers for TextEncoder and TextDecoder so they are differentiable in the debugger.  I would have implemented this but couldn't figure out how.

ES6 provides @@toStringTag which takes the role of the class name in Object.prototype.toString() so I think that might be a more appropriate direction than adding class numbers for objects that don't really need one internally. In fact with @@toStringTag only very few classes would need their internal class number as far as internal behavior is concerned. The rest could just rely on @@toStringTag for Object.prototype.toString() behavior.
The debugger protocol exposes the class number now though so it won't easily get help from this. There are various approaches like magicking the @@toStringTag (without side effects) in addition or instead of the class number. Though I would strongly prefer just to keep things minimal and orthogonal, and let the debug client obtain e.g. @@toStringTag via heap object inspection.

I guess the debugger protocol will need some versioning-friendly way to get at symbols.

If symbols are implemented like internal properties, existing property inspection will work as is.

That'd be fine with me, as long as the layout of the string used to make the symbol unique is part of semantic versioning guarantees.  In that way a debug client could parse the string to extract the description, unique identifier, etc.

The debugger protocol doesn't follow semantic versioning guarantees the same way as the API because it exposes internals (like class numbers) which change relatively often. So that's not a versioning issue as such - though annoying if they changed many times (not likely).


Issue for item 3.9 to 3.14 on v1.3.5

Hi,
I have configured my daemon.json as per below snippet.
 "tlscacert": "/var/lib/docker/certs/ca.pem",
 "tlscert": "/var/lib/docker/certs/server-cert.pem",
 "tlskey": "/var/lib/docker/certs/server-key.pem",

When I run a scan on the base host, my log shows the below.
{"id": "3.9", "desc": "Ensure that TLS CA certificate file ownership is set to root:root", "result": "INFO", "details": "No TLS CA certificate found"},
{"id": "3.10", "desc": "Ensure that TLS CA certificate file permissions are set to 444 or more restrictive", "result": "INFO", "details": "No TLS CA certificate found"},
{"id": "3.11", "desc": "Ensure that Docker server certificate file ownership is set to root:root", "result": "INFO", "details": "No TLS Server certificate found"},
{"id": "3.12", "desc": "Ensure that Docker server certificate file permissions are set to 444 or more restrictive", "result": "INFO", "details": "No TLS Server certificate found"},
{"id": "3.13", "desc": "Ensure that Docker server certificate key file ownership is set to root:root", "result": "INFO", "details": "No TLS Key found"},
{"id": "3.14", "desc": "Ensure that Docker server certificate key file permissions are set to 400", "result": "INFO", "details": "No TLS Key found"},

I did an echo of $tlscacert and got the below.
# echo $tlscacert
tlscacert:/var/lib/docker/certs/ca.pem

In 3_docker_daemon_configuration_files.sh, line 263 if [ -f "$tlscacert" ]; then will definitely fail since it is checking for the full string of tlscacert:/var/lib/docker/certs/ca.pem instead of just /var/lib/docker/certs/ca.pem.
Thanks.

Thanks for reporting this @zshrine, I'll have a look as soon as possible.

Thank you! I modified the script as per below to only get the json value.
tlscacert=$(get_docker_configuration_file_args 'tlscacert' | cut -d ":" -f 2)

I'm not getting the same results as you, sorry to say.
Did the following modification:
diff --git a/tests/3_docker_daemon_configuration_files.sh b/tests/3_docker_daemon_configuration_files.sh
index ed9d418..04cacc6 100644
--- a/tests/3_docker_daemon_configuration_files.sh
+++ b/tests/3_docker_daemon_configuration_files.sh
@@ -257,8 +257,10 @@ check_3_9() {
   totalChecks=$((totalChecks + 1))
   if [ -n "$(get_docker_configuration_file_args 'tlscacert')" ]; then
     tlscacert=$(get_docker_configuration_file_args 'tlscacert')
+    echo "*** get_docker_configuration_file_args $tlscacert"
   else
     tlscacert=$(get_docker_effective_command_line_args '--tlscacert' | sed -n 's/.*tlscacert=\([^s]\)/\1/p' | sed 's/--/ --/g' | cut -d " " -f 1)
+    echo "*** command_line_args $tlscacert"
   fi
   if [ -f "$tlscacert" ]; then
     if [ "$(stat -c %u%g "$tlscacert")" -eq 00 ]; then
@@ -289,8 +291,10 @@ check_3_10() {
   totalChecks=$((totalChecks + 1))
   if [ -n "$(get_docker_configuration_file_args 'tlscacert')" ]; then
     tlscacert=$(get_docker_configuration_file_args 'tlscacert')
+    echo "*** get_docker_configuration_file_args $tlscacert"
   else
     tlscacert=$(get_docker_effective_command_line_args '--tlscacert' | sed -n 's/.*tlscacert=\([^s]\)/\1/p' | sed 's/--/ --/g' | cut -d " " -f 1)
+    echo "*** command_line_args $tlscacert"
   fi
   if [ -f "$tlscacert" ]; then
     if [ "$(stat -c %a $tlscacert)" -eq 444 ] || [ "$(stat -c %a $tlscacert)" -eq 400 ]; then

and the result was correct:
[INFO] 3 - Docker daemon configuration files
[PASS] 3.1  - Ensure that docker.service file ownership is set to root:root
[...]
[PASS] 3.8  - Ensure that registry certificate file permissions are set to 444 or more restrictive
*** get_docker_configuration_file_args /etc/docker/certs.d/ca-centos.pem
[PASS] 3.9  - Ensure that TLS CA certificate file ownership is set to root:root
*** get_docker_configuration_file_args /etc/docker/certs.d/ca-centos.pem
[PASS] 3.10  - Ensure that TLS CA certificate file permissions are set to 444 or more restrictive
[...]

$ sudo cat /etc/docker/daemon.json
{
"icc": false,
"tls": true,
"tlscacert": "/etc/docker/certs.d/ca-centos.pem",
"tlscert": "/etc/docker/certs.d/server-centos-cert.pem",
"tlskey": "/etc/docker/certs.d/server-centos-key.pem",
"tlsverify": true
}

My apologies. The daemon.json i provided was wrong.
The actual daemon.json is as below:
"tlscacert":"/var/lib/docker/certs/ca.pem",

I have tested according to your sample above and it is parsing the value correctly. Seems like the space missing between json key and value is what causes the values to be parsed wrongly in my environment. In my daemon.json, there was no space between the key and value.

Could you test #409?

I tested. It is working as per expected. Thanks.
# grep tls /etc/docker/daemon.json
"tls": true,
"tlsverify": true,
"tlscacert":"/var/lib/docker/certs/ca.pem",
"tlscert":"/var/lib/docker/certs/server-cert.pem",
"tlskey":"/var/lib/docker/certs/server-key.pem",

The json results for 3.9 to 3.14
{"id": "3.9", "desc": "Ensure that TLS CA certificate file ownership is set to root:root", "result": "PASS"},
{"id": "3.10", "desc": "Ensure that TLS CA certificate file permissions are set to 444 or more restrictive", "result": "PASS"},
{"id": "3.11", "desc": "Ensure that Docker server certificate file ownership is set to root:root", "result": "PASS"},
{"id": "3.12", "desc": "Ensure that Docker server certificate file permissions are set to 444 or more restrictive", "result": "PASS"},
{"id": "3.13", "desc": "Ensure that Docker server certificate key file ownership is set to root:root", "result": "PASS"},
{"id": "3.14", "desc": "Ensure that Docker server certificate key file permissions are set to 400", "result": "PASS"},

Merged.

Closing since it seems to work after merge.


[FEATURE REQUEST] Font Size smaller than 1.0 on Scale slider?

I'm not sure if it is a limitation of the core, but if the Scale slide had the option to go down to '0.5', it would allow less screen clutter.

Man, you have really good eyesight 😆. I used 1.0 as the lower limit because (for me) it was unreadable with a value lower than 1.0

Ultrawidescreen monitor. I don't know if I'd set it that small, but I think it could go smaller and still be legibile.

I do wonder if going below 1.0 may present rendering issues. The VTTA Party Overview tooltip, fo instance, appears to have smaller fonts than yours and it has a slightly fuzzy quality to it. That's why I said what I said about it being a limitation in core FVTT. I know that Atropos has some "hard" limits baked in to the code because he feels strongly about how things should look.


[zh] Sync zh text in community files

Mainly sync with en #45872
modified:   content/zh-cn/community/_index.html
modified:   content/zh-cn/community/code-of-conduct.md
deleted:    content/zh-cn/community/static/community-values.md

/lgtm


Changing message type.

Changes the imaging sonar message type to be from the APL imaging_sonar_msgs package.
Instead of using a message definition copied over, let's use the original message definition in-place.  This adds a dependency, but avoids maintaining two very similar message definitions.

@woensug-choi If this is accepted, we should probably also remove the SonarImage.msg file from the frl_sensor_msg package: https://github.com/Field-Robotics-Lab/frl_msgs

Edited to use the original message definition from UW APL. SonarImage.msg at frl_msgs also removed.


Persist TARGET value in the image

Hi @messense, many thanks for the useful images!
I think it would be useful to persist the image's TARGET in the image itself, so there's no need to use some ugly workarounds (path parsing, reading from config files, etc.) to get the TARGET value.
The reason for picking a different variable name (RUST_MUSL_CROSS_TARGET) is to avoid possible collisions and unwanted side-effects.

Thanks!


Error: failed to add '*' to safe.directory

Hey, we've been using the action for months with no issues, but starting today we run into this error message:
Run DeNA/unity-meta-check@v3
  with:
    target_path: Survivor
    log_level: INFO
    target_type: auto-detect
    ignore_dangling: false
    ignore_case: false
    ignore_submodules_and_nested: false
    enable_autofix: false
    autofix_globs: *
    enable_junit: false
    enable_pr_comment: false
    pr_comment_lang: en
    pr_comment_pull_number: 0
    pr_comment_send_success: false

/usr/bin/docker run --name ghcriodenaunitymetacheckunitymetacheckghaction3[2](https://github.com/ivan-coder/survivor/actions/runs/8463559811/job/23192218534#step:4:2)1_216dd6 --label 1c4c[3](https://github.com/ivan-coder/survivor/actions/runs/8463559811/job/23192218534#step:4:3)a --workdir /github/workspace --rm -e "INPUT_TARGET_PATH" -e "INPUT_LOG_LEVEL" -e "INPUT_TARGET_TYPE" -e "INPUT_IGNORE_DANGLING" -e "INPUT_IGNORE_CASE" -e "INPUT_IGNORE_SUBMODULES_AND_NESTED" -e "INPUT_IGNORED_FILE_PATH" -e "INPUT_ENABLE_AUTOFIX" -e "INPUT_AUTOFIX_GLOBS" -e "INPUT_ENABLE_JUNIT" -e "INPUT_JUNIT_XML_PATH" -e "INPUT_ENABLE_PR_COMMENT" -e "INPUT_PR_COMMENT_LANG" -e "INPUT_PR_COMMENT_TMPL_FILE" -e "INPUT_PR_COMMENT_PULL_NUMBER" -e "INPUT_PR_COMMENT_SEND_SUCCESS" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL"
WARNING: The requested image's platform (linux/arm6[4](https://github.com/ivan-coder/survivor/actions/runs/8463559811/job/23192218534#step:4:4)/v8) does not match the detected host platform (linux/amd[6](https://github.com/ivan-coder/survivor/actions/runs/8463559811/job/23192218534#step:4:6)4/v3) and no specific platform was requested
error: failed to add '*' to safe.directory

Our github action looks like this
name: Meta Check
on: push

jobs:
  meta-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: DeNA/unity-meta-check@v3
        with:
          target_path: Survivor

I saw the version bump a few hours ago, and figured it must be related. Any idea what can be happening?
Thanks!

For anyone running into this issue, the previous version keeps running just fine:
- uses<EMAIL_ADDRESS>

We are aware of the issue. We have just made a release on Apple Silicon Macs. Until now, we have been using Intel Macs, so the environment for the image has changed. We are currently working on this issue.

@ivan-coder This problem was fixed at v3.2.2. Please try it!

Just to let you guys know, it fixed it indeed 👍


Increment ordernumber only after validating order

The order validation might fail but we already got a ordernumber.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/PT-10676
Please use this issue to track the state of your pull request.

thanks for your contribution @pascalheidmann-bedarf  👍🎉💙


Feature Request: Process newest/latest job in queue

Any way to tell Sidekiq to always process the newest/latest job in a specific queue? -- I have a specific queue which needs to always do the newest job and catch up on older ones later in the day. Any way to achieve that?

Your question is not related to sidekiq-fetch-limit but relative to sidekiq : https://github.com/mperham/sidekiq
You should better close this issue and repost in the right place if you want an answer.
But at my knowledge sidekiq is Last in, Last out per queue.
However you can play with the queue name and create priority for some queue.
You can see other extensions here (and maybe find something that fit you) :
https://github.com/mperham/sidekiq/wiki/Delayed-extensions

Yes, I'm trying to find a way to make a specific queue Last in, First out. For example:
item1 -> queue1
item2 -> queue1
item3 -> queue1
sidekiq <- item3
item4 -> queue1
item5 -> queue1
sidekiq <- item5
sidekiq <- item4
sidekiq <- item2
sidekiq <- item1

Not quite sure how playing with queue names/priorities will help achieve that, delayed extensions don't seem relevant either. I'll try asking on the sidekiq project issues.


Fix user permissions in docker

Was trying out main but running into UID issues.
This PR makes a few changes:

create a separate enduser user, which uses the UID passed in at runtime
create an app group, which both opendevin and enduser belong to
change UID_MIN to something compatible with OS X
chmod everything so that it's group-readable

I've verified that:

App starts in docker
Browser starts up OK
Files created by agent have the end-user's UID

I don't see the permission issues, on Mac, but that's probably just me working on outdated builds for a bit.
While I can't confirm that the changes are needed, I can confirm what you're seeing now, such as, it works, files have user uid.


Cannot find translation at bank deposit/withdraw page

Hello @fansyfs
Sprockets has cached dumped translations JS. Just clear assets cache.
If you have still issue with this you may reopen ticket. Thanks.


death mode

What:
Added death mode, which can be enabled via -d flag. When the death mode is enabled, the round will be finished as soon as the user will type an incorrect symbol

Why:
If you want to become a good typist, you need to learn to type with no mistakes. This mode will enforce you to think twice on each key press and strongly decrease amount of typing mistakes. This will lead to better typing speed

How:
There is a has_finished function at game related file, which validates if the round is completed. At this PR I've additionally added a check to the function to validate it there are any mistakes in the input field

Checklist:

[x] Allow edits from maintainers option checked
[x] Branch name is prefixed with [your_username]/ (ex. thatvegandev/featureX)
[x] Documentation added
[ ] Tests added N/A
[x] No failing actions
[x] Merge ready

this looks awesome! I made a few minor tweaks in a branch of mine that I'll add here! One thing I'd love you opinion on:
What do you think about not showing stats if the user fails in death mode? We could just throw a skull icon in the center of the terminal if they fail maybe. I kinda like the idea of making the seeing stats a rewarding experience if you're in death mode.

@jrnxf Your idea sounds great! I've also reviewed changes at your branch, and all of them make sense to me. I'll add it to the PR along with your proposition 👌

I've just realized that it will be better to show the word and the exact place where you made a typo, along with skull at the bottom line after loosing in the death mode. Will try to implement it


[WIP] Fix ci pipeline.

Signed-off-by: Pan Li<EMAIL_ADDRESS>

Close this PR as it is already out of date.


Add structured data markup for itemtype="http://schema.org/Person" in author-profile.html

Adds schema.org properties for the itemtype="http://schema.org/Person"  in the file '_includes/author-profile.html'. The following properties were added:

image for author.avatar
name for author.name
description for author.bio
homeLocation (adds a itemtype="http://schema.org/Place" with itemprop="name" for author.location )
url for author.uri
email for author.email
sameAs for all the social media links

As the schema.org attributes added made the lines of text longer, I also modified some of the indentation so the html source is a bit easier to understand.
This lets Google's Crawler see all the structured data (this can be tested at using Google's Structured Data Testing Tool. )

Thanks for this @aloisklink


[WIP] Docx support

docx document support using Apache POI (via the opensagres converter)

Coverage decreased (-0.06%) to 37.238% when pulling cacc48beb90706ce05805be98539a03a1cf66c54 on docx-support into 4a7e4f3b93e46caa81e7507e659631551d8e7dd8 on master.

I need to add some tests :/

I've added examples under grobid/grobid-core/src/test/resources/docx.
Out of 14 different docx article templates, the conversion of 3 are currently failing (IJSRP-paper-submission-format-double-column.docx, IJSRP-paper-submission-format-single-column.docx and Journal-Manuscript-Format-MS-Office-2007.docx) :(

Given the poor results with Apache POI, we would need to try docx4j as alternative.

Is there a quick way -- or would it make sense to add the ALTO XML as an input format for the service, as well? In this manner, someone could run that pipeline separately (pdfalto included) and from there just submit the XML.
This is of course not as nice as getting inline converters working, but it does sort of shift the problem.

Adding web services taking as input ALTO XML instead of PDF is easy (we just shortcut the pdf conversion), but the problem is that there are a certain number of ALTO flavors and so far the only one well tested and supported is the pdfalto output. This is probably quite a lot of effort to test and support comprehensively ALTO variants.
The best option regarding docx would be certainly a docx to ALTO XML conversion (same ALTO as pdfalto), and just take also ALTO as input, but it looks complicated, which is why I am adding, first, this docx support via Apache POI or docx4j.

Should I add ALTO XML input as a feature request / pull request?
The embedded PDF ALTO support makes containerization a bit more of a challenge and does have an impact in the way ingestion can be managed- as you could imagine, running the PDF ALTO process on a separate server gives the GROBID server more capacity for running WAIPI and such.

noting another contributor has posted a pdfalto service PR (WIP): https://github.com/kermitt2/grobid/pull/552


(GH-1408) Update puppetdb plugin to use target_mapping field

This updates the puppetdb inventory plugin to accept a
target_mapping field that is used to populate target configuration
values with facts loaded from PuppetDB. This is to match the behavior of
other inventory plugins that use the Ruby plugin helper.

Do not merge until other inventory plugins have been updated to use the Ruby plugin helper

CLA signed by all contributors.

Updated.

Updated.

Updated.


travis: fix arm64 build

After PR #11740, a complete build is run on Travis CI. This currently
breaks the ARM64 build which is missing some dependencies.
Fixes: a6ca5d539168 ("travis: run build checks and complete build")
Reported-by: Paul Chaignon<EMAIL_ADDRESS>Signed-off-by: Tobias Klauser<EMAIL_ADDRESS>

Should be good to merge once Travis CI passes on ARM64.

Coverage increased (+0.02%) to 36.856% when pulling e615246676c155d22d0445629f630a5435ba5c3a on pr/tklauser/travis-fix-arm64-build into 05daeef1c29a48928391cb1820c77752675d6bcd on master.


Lychee treats srcSet attribute as single URL

lychee incorrectly parses srcSet into a single URL which fails to resolve to any filename.
Errors in platforms/apple/guides/macos/enriching-events/context/index.html
✗ file:///home/markus/projects/sentry-docs/public/static/1bd990e15ff62d8c08f68a249fa0face/5a46d/additional_data.png%20300w,/static/1bd990e15ff62d8c08f68a249fa0face/0a47e/additional_data.png%20600w,/static/1bd990e15ff62d8c08f68a249fa0face/7321b/additional_data.png%201184w (Cannot find file file:///home/markus/projects/sentry-docs/public/static/1bd990e15ff62d8c08f68a249fa0face/5a46d/additional_data.png%20300w,/static/1bd990e15ff62d8c08f68a249fa0face/0a47e/additional_data.png%20600w,/static/1bd990e15ff62d8c08f68a249fa0face/7321b/additional_data.png%201184w)

the corresponding HTML:
  <img class="gatsby-resp-image-image" alt="Custom contexts as viewed on the Additional Data section of an event" title="Custom contexts as viewed on the Additional Data section of an event" src="/static/1bd990e15ff62d8c08f68a249fa0face/7321b/additional_data.png" srcSet="/static/1bd990e15ff62d8c08f68a249fa0face/5a46d/additional_data.png 300w,/static/1bd990e15ff62d8c08f68a249fa0face/0a47e/additional_data.png 600w,/static/1bd990e15ff62d8c08f68a249fa0face/7321b/additional_data.png 1184w" sizes="(max-width: 1184px) 100vw, 1184px" style="width:100%;height:100%;margin:0;vertical-align:middle;position:absolute;top:0;left:0" loading="lazy"/>

We use linkify for the parsing part. If you have the time, can you check if the error also happens over there?

I actually believe that you treat some attributes as if they contain verbatim URLs (using linkify for the rest), and srcset is on that list.


Port Motion 4 examples from processing, moving on curves, linear, morph and bounce [moz sprint]

Hi,
Participating in MozSprint by porting these.
I added three examples from the processing.org/examples "Motion" section (They are called moving on curves, linear and bounce).

thank you!


Johnson’s Algorithm

Issue will be closed if:

You mention more than one algorithm. You can create a separate issue for each algorithm once the current one is completed.
You propose an algorithm that is already present or has been mentioned in a previous issue.
You create a new issue without completing your previous issue.

Note: These actions will be taken seriously. Failure to follow the guidelines may result in the immediate closure of your issue.

Name:
[NEW ALGORITHM]
Johnson’s Algorithm
About:
Propose a new algorithm to be added to the repository
Johnson's Algorithm is a graph algorithm used to find the shortest paths between all pairs of vertices in a weighted, directed graph, even when some of the edges have negative weights (but without negative weight cycles).

Labels:
new algorithm, gssoc-ext, hacktoberfest, level1

Assignees:

[x] Contributor in GSSoC-ext
[x] Want to work on it

#561


Fix leak of CoreFoundation objects during calls to vkUseIOSurfaceMVK()

A small leak occurs if no existing IOSurface is provided to vkUseIOSurfaceMVK() because CoreFoundation objects returned from functions with Create in their name must be released with CFRelease()

Thanks for finding this, and submitting the fix!


detect file encoding with chardet before parsing the .py file

PR Checklist

[x] A description of the changes is added to the description of this PR.
[x] If there is a related issue, make sure it is linked to this PR.
[x] If you've fixed a bug or added code that should be tested, add tests!
[ ] Documentation in docs is updated

Description of changes

Codecov Report

Merging #103 (a73602b) into main (d9aef9c) will decrease coverage by 1.9%.
The diff coverage is 100.0%.

@@           Coverage Diff           @@
##            main    #103     +/-   ##
=======================================
- Coverage   94.6%   92.6%   -2.0%
=======================================
  Files         30      30
  Lines       1097    1120     +23
=======================================
  Hits        1038    1038
- Misses        59      82     +23

Impacted Files
Coverage Δ

deptry/import_parser.py
73.7% <100.0%> (-22.3%)
:arrow_down:

tests/test_import_parser.py
89.7% <100.0%> (-10.3%)
:arrow_down:

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


Tdlib 1.7.9 output too many updates of users and chats at login

I'm switching to 1.7.9 from 1.6.6. There is a performance penalty as the new lib outputs tons of users and chat updates at login despite any API call returns.  This behaviour is new as compared to 1.6.6. Is there any option to limit the update output to make sure the API call is returned in nature of realtime way?
@levlam
Many thanks.

No, All sent updates are required and are needed for something.


libvirt: Add podvm instance size/type support for libvirt

AKS, AWS? and IBM Cloud providers have options in their kustomization.yaml overlay (which goes to the entrypoint) which allows a user to specific the size of podvm they want to create.
Currently libvirt doesn't have this option and I think that the vm size created is hard-coded in https://github.com/confidential-containers/cloud-api-adaptor/blob/main/pkg/adaptor/cloud/libvirt/libvirt.go#L532-L533 as shown in:
# kcli info vm podvm-simple-test-530932ec
name: podvm-simple-test-530932ec
id: 8af3bdff-ce2e-423a-851c-19a8d9422cf1
status: up
autostart: False
plan:
cpus: 2
memory: 8192
net interface: eth0 mac: 52:54:00:88:83:c6 net: default type: routed
ip: <IP_ADDRESS>
diskname: sda disksize: 6GB diskformat: sata type: qcow2 path: /var/lib/libvirt/images/podvm-simple-test-530932ec-root.qcow2
iso: /var/lib/libvirt/images/podvm-simple-test-530932ec-cloudinit.iso

This is a bit of an issue as a) it's not very flexible for workloads b) for dev scenarios it's a bit of a problem as two kcli cluster nodes take 4 vCPU and 6GB vRAM, so to run the most basic single peer pods test you need 10 vCPU and 20GB RAM. If we can add support for specifying instance size of the libvirt peer pod vms that will allow the flexiiblity that you get with the other cloud providers.

Is there a VM profile or flavour concept in libvirt like the cloud providers?
If not we should probably look at supporting the vcpu and memory annotations for libvirt provider to specify a non-default pod VM size

Is there a VM profile or flavour concept in libvirt like the cloud providers?
If not we should probably look at supporting the vcpu and memory annotations for libvirt provider to specify a non-default pod VM size

I'm not an expert, but I didn't see a profile/flavour concept when looking around, so I'll update the issue to be clearer about using annotations.

Is there a VM profile or flavour concept in libvirt like the cloud providers?
If not we should probably look at supporting the vcpu and memory annotations for libvirt provider to specify a non-default pod VM size

I'm not an expert, but I didn't see a profile/flavour concept when looking around, so I'll update the issue to be clearer about using annotations.

Hmm.. I will check as well. Nonetheless it'll be good to update the description and mention about the annotations as well. At least the current limitation of fixed pod VM size will be get fixed


Added Followbot (and other improvements)

Added simple Followbot (#266)
Properly fixed #269
Maybe fixed #272
Reduced playerlist flickering
Moved the vote logger to ChatInfo and created an enum for the various flags
A lot of refactoring and code cleanup
Added g_EntityCache.IsFriend(entIdx) to easily check if a player is a steam friend
Added Vec3.Dist2D() which returns the 2D distance (if z doesn't matter)

Good stuff


pb in pip install -e

hello,
you rename README in README.md but in the setup.py  you have
long_description=open('README').read(),
can you  change this tanks...
toogaz

Good catch, thanks!


bump kubernetes-sigs tags for 1.31

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


Add displayName and description to PluginDeclaration and use it in plugin-publish plugin

By specifying displayName and description in PluginDeclaration, users can avoid configuring plugins in the pluginsBundle block except if they want to use different tags or a different version for some plugins.

Reopening because plugin-publish part is still missing.


Feat: Added function for tweeting

fix linting error

Okayy

fix linting error

Okayy

I am working on it currenlty. so you may not do it.


made a translation Dutch/nl

Hi,
I've made a translation for you. Wanted to create a pull but it was not possbile.
So i'll just paste it here.
[sidebarToc]
    other = "Inhoud"

[sidebarPages]
    other = "Pagina's"

[sidebarTags]
    other = "Tags"

[sidebarLinks]
    other = "Links"

[sidebarBangumiChart]
    other = "Bangumi"

[footerPoweredFront]
    other = "Powered by "

[footerPoweredEnd]
    other = " "

[postMetaNoTag]
    other = "Geen Tags"

[postMetaWordCount]
    other = " woorden"

[postCopyrightFront]
    other = "Tenzij anders vermeld is de inhoud van deze site eigendom van "

[postCopyrightEnd]
    other = "."

[postCommentLoading]
    other = "Commentaren worden geladen..."

[postCommentLoadingFailed]
    other = "Commentaren konden niet geladen worden."

[archivesTotalPages]
    other = "Totaal aantal posts: "

[tagsCurrentTag]
    other = "Alle posts met de tag {{ .Title }}: "

[webpCheckerFront]
    other = "Uw huidige browser ondersteund deze pagina niet "

[webpCheckerEnd]
    other = " afbeeldingen"

Thanks for your help.
I've merged it in https://github.com/amzrk2/hugo-theme-fuji/pull/13


Improve url arbiter response handling

https://trello.com/c/8zCaPXNh
publishing-api fails to handle HTML error responses from Rails causing errors. it fails because it tries to parse HTML response as JSON.
this causes publishing-api to return JSON decoding errors to clients who're expecting to know what exactly went wrong with their requests. by setting an appropriate 'Accept' header we're ensuring Rails returns errors as a JSON document instead of HTML.
also, updating content-store client with the same change and passing the response content-type back to clients as-is.
hat-tip: @alext

A couple of small points, otherwise looks good to me.

@alext: fair points, rebased. thanks!


Fix file saving in editor, merge common code into utils.ts

Fixes #14
Collect common code into util.ts from provider files
Merge dispose.ts into util.ts

Excellent! And thanks for the clean-up 😄


ipyplot fails to install

Thank you for creating the ticket over here!
I've reviewed a bit more and it seems that the python paths are different, meaning that ipyplot is being installed in one location but the python interpreter being run for python is another one -- hence, it cannot find the installed packages:


Add support for right-to-left messages

Add support for correct viewing of right-to-left messages.

Finished my work on this PR. Some screenshots:

Looking at other apps, it seems that we are missing some RTL-ing.
In the message list, we should have the avatar to the right too, and the user's name aligned to the right, and I guess the time of the message aligned to the left?

@borisyankov In this PR, I'm only aiming to implement RTL support for the messages, not the whole application. Nearly all messenger applications have the same behavior (just switch the message content, not the user name or picture or anything else). This helps keeping consistency between lines of messages. Also, The same behavior is merged to Zulip's web version.
This is a screenshot showing Flock doing the same behavior (Slack does not support RTL):

@borisyankov Do we need to discuss things further?

I did investigate the way the RTL support is done in the web app and I agree with you that we don't need to do the full RTL that I suggested. We should leave it as-is for now.

What's the status of this issue? Why isn't it getting merged? Is there something I can help with?

@mosajjal We are still very interested in merging this.
I think @Shayan-To is planning to work again a bit on the PR soon.

this is going to fix a very big issue for RTL users. The web version is fixed (in 1.9) and I'm looking forward to this one as well. Zulip rules :+1:

Thanks @mosajjal for checking in on this!
See #2755 for the issue; that's the best place to track the issue as a whole (as opposed to this PR for it.)
As Boris says, we'd love to have this issue fixed. It looks like this PR's author has been busy, and they haven't had time to return to the PR and finish it.
So I think the current status is: if you're up for trying this issue, please do! I'd recommend looking at this PR (and the comments on it) for reference for some of the pieces you'll want in your solution.
I'm going to close this PR, to help make it clear that anyone is welcome to claim the issue and take it from here.


The URL is not correctly linked

As shown in the image, it seems that "?" Is not correctly encoded, or it is a URL, but the subsequent character string is not correctly recognized as a URL.
I will paste the email of Amazon.co.jp for reference.

Env:

Windows 10 Pro 1709
Nylas Mail 2.2.1

Maybe, it’s because the regex finds the “=“ before the ? And ends the match.  I will look into it.

This will be v2.2.2 in the first week of November. Going to test the master branch to ensure #145 fixed this and other links werent broken


add a simple example of how to start the script to the readme file

Add a section in the readme file that describes how to run the script

Thanks @bwasilewski !

Happy to help @Subzero-ftspdev!


How to consume render callbacks with multiple arguments?

From reading the code, it looks like epitath only passes the first render prop argument to the generator - how can a render prop component that calls the render function with multiple arguments be consumed? Is this an oversight sorry for wording or is it by design?

It's by design! We recommend people creating their own wrappers https://github.com/Astrocoders/epitath/issues/1#issuecomment-418912767 to avoid bloating to much the API
const MutationWrapper = ({children, ...props}) =>
  <Mutation {...props}>{(mutate, result) => props.children({ mutate, result })}<Mutation/>

...
const { mutate, result } = yield <MutationWrapper any props />

Cool! That's exactly how I solved it. Feel free to close this issue, I'll leave it open

@williamboman how about adding this information in the README? Can you create a PR? 🚀

Closed by #21


CRYPTO_atomic_read

Add a CRYPTO_atomic_read call which allows an int variable to be read in an atomic fashion.

[x] documentation is added or updated
[x] tests are added or updated

Looks like there are already some existing use cases for CRYPTO_atomic_read(), which should be replaced:
~/src/openssl$ grep -r -nH 'CRYPTO_atomic_add.*, 0'  *
crypto/lhash/lh_stats.c:75:    CRYPTO_atomic_add(&lh_mut->num_hash_calls, 0, &ret,
crypto/lhash/lh_stats.c:78:    CRYPTO_atomic_add(&lh_mut->num_comp_calls, 0, &ret,
crypto/lhash/lh_stats.c:85:    CRYPTO_atomic_add(&lh_mut->num_retrieve, 0, &ret, lh->retrieve_stats_lock);
crypto/lhash/lh_stats.c:87:    CRYPTO_atomic_add(&lh_mut->num_retrieve_miss, 0, &ret,
crypto/lhash/lh_stats.c:90:    CRYPTO_atomic_add(&lh_mut->num_hash_comps, 0, &ret,

As was discussed already [internally], you can't make any sensible decision without modifying an atomic variable. Or in other words how atomic read is different from just read? Indeed, consider
    if (!CRYPTO_THREAD_write_lock(lock))
        return 0;

    *ret  = *val;

    if (!CRYPTO_THREAD_unlock(lock))
        return 0;

If there is contention for *val, then it can be different by the time caller gains execution control after CRYPTO_THREAD_unlock. So what does locking give you? Well, one can still argue that suggested atomic read would prevent compiler from moving it as result of optimization, but so would cast to volatile. As for use of atomic add with 0 increment in lh_stats.c it's terrible and is not right. If coherent view in stats is absolute requirement, then one shouldn't use atomic_add on structure fields elsewhere, but lock the whole structure. Currently view is incoherent and not atomic add with 0 increment would fix that.

Well, there is a chance that I've let "practitioner" in myself take over "theoretician". I mean is it possible that notion of atomic load is meaningful on platforms where load has to performed with multiple instructions? And "practitioner" says there are no such platforms? Is this it? Yet, we do make assumption about platform, for example that it's [[I]L]P(32|64), two's complement, so we don't actually aim for pure abstract platform. So is it reasonable to assume that conventional load is actually atomic?

I, for one, am not confident enough to assert that we can assume that conventional load is atomic on all platforms we are used on.  (Note that I say "platforms we are used on", not "supported platforms", because there are no doubt people pushing the envelope.)
And if I understand correctly, here "platform" includes not just processor but also memory model and potential for unaligned accesses.

This came out of #4402 I don't think that an atomic read is required there.  The most likely outcome of a race is an extra reseeding (or possibly a delayed reseed).
I have seen processors where int loads took several instructions.  Some small micros do this, MIPS does for constant loads (which aren't directly relevant).  However, on systems where loads are atomic, I'd expect them to be replaced by a plain load/store sequence.  This happens on x86/64.  There is still a cost -- the memory write, the function call and return.
If people don't think this PR is worthwhile, speak up.  I'm happy for it to not go in.  The current use case doesn't need it and the other places in lhash where it could be used should be done differently.
Locking is the solution for the lhash cases.  In a new PR.

I've dealt with the lhash concerns in #4418

"platform" includes not just processor but also memory model and potential for unaligned accesses.

Trick question. There is ambiguity in "memory model" when it's used in same sentence with "platform" and "processor". In sense that processor itself upholds certain discipline referred to as "memory model", but on the other hand there is language "memory model" or how compiler schedules loads and stores :-) Anyway, I'd say that we can take unaligned accesses out of equation. For following reason. We are not talking about reading variables in general, but specifically about base types that match processor register, int, long, void *. And we can expect them to be aligned, compiler is obliged to do it for us. In the context of "atomic" load we can take processor's memory model out of equation too, because there is ambiguity in either case, i.e. did you get value before or after modification. I mean processor's memory model affect ambiguity, but doesn't eliminate it, and it doesn't matter which ambiguity is it. As for language "memory model" it's tricky, isn't it? Our requirement for language standard compliance predates notion of "memory model" in C. It should be noted however that two disjoint subroutines accessing same shared variable, and called from disjoint translation unit do constitute desirable "memory model", don't they? [I suppose this is also argument against LTO.]

I have seen processors where int loads took several instructions. Some small micros do this, MIPS does for constant loads

This can't be viewed as load, because there is no separately addressable memory cell. Pieces of constant are encoded into instructions themselves. As already mentioned, we are not talking about loads in most general sense, but specifically about aligned loads of shared variables that fit into processor register.

two disjoint subroutines accessing same shared variable, and called from disjoint translation unit do constitute desirable "memory model", don't they?

And so would variable declared volatile...

OK, would it be appropriate to say like this? It's desirable to use atomic_load, because it conveys information to compiler what it can do in terms of optimization. It will be compiled as just load [on supported platforms], but compiler won't be as free to move it around as just reference. It should be noted that essentially same effect can be achieved by declaring variable volatile. And it would actually be acceptable approach for compilers that don't specify "memory model". One can also point out that CRYPTO_atomic_* reside in separate translation unit, which actually limits such compiler's ability to screw things up. [On the other hand one can note that formally speaking adhering to atomic_load should make LTO safe, at least in respect to involved variables.]
If it's adequate summary, then it might be appropriate to implement CRYPTO_atomic_read. But suggestion is to adhere to volatile where atomic_load is not an option. Concern here is that synchronization costs would be off-charts disproportionate to [zero] benefit. And "might" in first sentence means that one can still wonder if there is really legitimate reason for it. I mean since you can't really take sensible decision based on value of reference counter without actually modifying it... I suppose I have to double-check #4402.

The counter drbg->restart_count in #4402 is not a reference counter, it's more like a modification timestamp. A chained drbg checks wether drbg->restart_count != drbg->parent->restart_count. If this is the case, it knows that the parent reseeded more recently than itself, and will auto-reseed. As @paulidale already noted, a race condition will in the worst case have the effect, that the drbg is reseeded more than once , or the reseed occures one or more generate() requests later than intended.

@mspncp summed it up well.  The instance in question doesn't strictly require this functionality.
Hence to offer to close this without merging.

It seems that volatile isn't a good answer: https://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming
It guarantees going to memory, not that the memory access is atomic.

Once again, volatile is suggested as compromise for specific case, load of aligned integer. There is no contradiction with referred article, because it too recognizes that any load of aligned integer, be it volatile or not, is atomic. And what is the compromise? Pre-C11[?] doesn't make any promises about how and when variables are loaded, written or cached in registers. Except for volatile ones. So by adhering to volatile load we simply prevent compiler from caching the value in register. And referred article effectively recognizes that. And once again, the reason for seeking compromise is that synchronization doesn't give you any advantage, in sense that you can have outdated value even with mutexes around it.

Pre-C11[?] doesn't make any promises about how and when variables are loaded, written or cached in registers.

Well, it's not like C11 makes such promises in general. It's just in addition to volatiles it adds notion of atomic variables and specifies their behaviour in respect to memory references.

synchronization doesn't give you any advantage, in sense that you can have outdated value even with mutexes around it.

As far as I understand it, atomic read/write is meant to prevent me from reading inconsistent values (partiallly updated by another thread). This has nothing to do with the question whether the value is current or might become outdated immediately afterwards.  So isn't this discussion  comparing apples and oranges? Or did I miss something?

by adhering to volatile load we simply prevent compiler from caching the value in register.

Just in case to clarify. I have to imagine some super aggressive LTO that inlines all functions and for whatever reason chooses to cache variable value in register for like forever.

atomic read/write is meant to prevent me from reading inconsistent values (partiallly updated by another thread).

This is misleading formulation. Atomic variable can't be partially updated, per its definition. For this reason compiler won't even support types that hardware doesn't guarantee atomic access for. I.e. you a not free to declare arbitrary type [base or not] as atomic.

Or did I miss something?

Well, the spirit of the quote is rather "[provided that we recognize that load of aligned integer is actually atomic (on all known ILP32 and better platforms)] synchronization doesn't give you any advantage."

[provided that we recognize that load of aligned integer is actually atomic (on all known ILP32 and better platforms)]

And of course so is store in thread that is updating the variable in question of course. Be it one declared atomic or not.

Well, the spirit of the quote is rather "[provided that we recognize that load of aligned integer is actually atomic (on all known ILP32 and better platforms)] synchronization doesn't give you any advantage."

Ok, I think you convinced me now to keep things simple in PR #4402 and just do a naive compare without worrying too much ;-).

I can't see a simple compare hurting for #4402 A delayed or extra reseed is harmless.  I don't think a reseed can reasonably be missed which is the problem case (2^32 reseeds between generations is a problem but essentially impossible).
What synchronisation does give you is a guarantee that the two halves weren't read separately.  E.g. the structure is misaligned or you're running on an 8 bit CPU that requires four loads or, perhaps, crosses a page boundary.
Anyway, I'll close this unmerged tomorrow if I don't hear any objections.

No concerns about keeping this have been raised so I'm closing without merging.

It would probably be document the conclusions in the tree somewhere, in terms of what behavior we have decided to rely upon.

Reopening in light of #4467

Now that it's re-opened because it seems useful (see the atomic-add calls with 0), are @dot-asm and others satisfied with it?  Another option is to define atomic-read as atomic-add with zero and "fix" it later.

Fixed a #defined() to use the correct macro (__ATOMIC_ACQUIRE instead of __ATOMIC_ACQ_REL).

Should an atomic write also be supported?
int CRYPTO_atomic_write(int *val, int n, CRYPTO_RWLOCK *lock)

Again, atomic_add can do this by adding zero but a write would be more efficient on many platforms since it avoids half of the read/write cycle.

CRYPTO_atomic_write added.

ping?

Merged, thanks.

Merged, thanks.

Load/store makes sense, so does read/write, but load/write doesn't.

Generally speaking it's rather a compiler-specific thing than threading-model-specific. For example there is gcc for Windows, you know. To extend the argument it might use C11 coverage (see refcount.h for inspiration). In other words it might be appropriate to have it as separate module as apposite to threading-module-specific...

Load/store makes sense, so does read/write, but load/write doesn't.

Disregard this, I've misread code.

are @dot-asm and others satisfied with it?

I'm not, because I still think that it gives you wrong impression. But I have to collect my thoughts....

I've made the changes to the above problems in #4517


workaround for config issue in grails3

The Mail plugin is not working with Grails-3.0.1, It seems like the issue is with props: [] in mail configuration and javaMailProperties is not set properly for JavaMailSenderImpl due to
props: [
 'mail.smtp.auth'                  : true,
 'mail.smtp.socketFactory.port'    : 465,
 'mail.smtp.socketFactory.class'   : 'javax.net.ssl.SSLSocketFactory',
 'mail.smtp.socketFactory.fallback': 'false'
]

is transformed into
props: [ mail: [ smtp: [ auth : true, socketFactory: [ port:465, class: 'javax.net.ssl.SSLSocketFactory', fallback: 'false' ] ] ] ]

Here is the github link for the workaround I've implemented https://github.com/puneetbehl/mail/commit/caa33402c41f6ebfe25e54e46f9bcb8b00e8d3cc

Can merge this ?

As mentioned in the comments, pull request needs to be revised to just use config.props.toFlatConfig()

closed as better pull request applied already


changing headless to user variable

to be able to generate boxes without need of GUI.

@denisok I am not sure I understand this change. The end result is the same no?

@hwoarang if you don't have any gui - it allows you to still build the box:
./packer build -parallel=false -only=virtualbox,libvirt -var 'headless=true' definitions/15.0-x86_64.json
for example that could be used for automatic box build with Jenkins or any other tools.
Without the change QEMU and VirtualBox would want to start screen session.

Oh I get it now. Thank you


branch-2.1 check illegal partition exprs (#40158)

pick https://github.com/apache/doris/pull/40158

run buildall

run buildall


Update polars to 0.38.3

Motivation
The current version of polars used (v0.36.2) is generating somewhat corrupted parquet files. They can be read by some libraries (such as arrow), but not others (spark, trino). Updating to 0.38.3 resolves this issue. This is lot the latest release of polars, but 0.39 and later have some breaking changes that would impact cryo that I wanted to avoid, since 38 already includes the fix that I need
Solution
There are some breaking changes on the 0.37 and 0.38 upgrades, but none of these should impact cryo from what I've seen:
https://github.com/pola-rs/polars/releases/tag/rs-0.37.0
https://github.com/pola-rs/polars/releases/tag/rs-0.38.0
PR Checklist

[ ] Added Tests
[ ] Added Documentation
[ ] Breaking changes

updated your branch here #208 because needed additional changes


Get-TLSInformation missing mandatory parameter

I updated the module to 4.2.10, but Get-TLSInformation is missing a mandatory parameter.

This is also true of Get-TlsCertificate

Hmm...I have parameters marked as mandatory for each of their respective
parameter sets as such:
[image: image.png]
Is there something else I could do here?
On Tue, May 9, 2023 at 1:13 PM Jeff Hicks @.***> wrote:

This is also true of Get-TlsCertificate
—
Reply to this email directly, view it on GitHub
https://github.com/anthonyg-1/PSTcpIp/issues/8#issuecomment-1540560329,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHGBZJWFVB6RF5O7H3GXZMLXFJ3MNANCNFSM6AAAAAAX3S256M
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Never mind, got it. Need to set default parameter set. Doing that now.
On Tue, May 9, 2023 at 1:39 PM Tony G @.***> wrote:

Hmm...I have parameters marked as mandatory for each of their respective
parameter sets as such:
[image: image.png]
Is there something else I could do here?
On Tue, May 9, 2023 at 1:13 PM Jeff Hicks @.***>
wrote:

This is also true of Get-TlsCertificate
—
Reply to this email directly, view it on GitHub
https://github.com/anthonyg-1/PSTcpIp/issues/8#issuecomment-1540560329,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHGBZJWFVB6RF5O7H3GXZMLXFJ3MNANCNFSM6AAAAAAX3S256M
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Fixed in 4.2.11


Tune logging: "Using hardcoded default" as info

I think that this is definitely a warning.  It should be rare that no configuration is provided so when it isn't it is probably an indication of a problem.

I think that this is definitely a warning. It should be rare that no configuration is provided so when it isn't it is probably an indication of a problem.

+1 I think we should leave it as a warning.

The problem is that this warning is unavoidable when using CompositeCacheManager.getUnconfiguredInstance():
	at org.apache.commons.jcs.utils.threadpool.ThreadPoolManager.configure(ThreadPoolManager.java:324)
	at org.apache.commons.jcs.utils.threadpool.ThreadPoolManager.<init>(ThreadPoolManager.java:96)
	at org.apache.commons.jcs.utils.threadpool.ThreadPoolManager.getInstance(ThreadPoolManager.java:202)
	at org.apache.commons.jcs.engine.control.event.ElementEventQueue.<init>(ElementEventQueue.java:56)
	at org.apache.commons.jcs.engine.control.CompositeCacheManager.initialize(CompositeCacheManager.java:276)
	at org.apache.commons.jcs.engine.control.CompositeCacheManager.getUnconfiguredInstance(CompositeCacheManager.java:214)

Could I have the complete stack trace please?

Basically, this is all. I set a breakpoint at the log.warn("No configuration settings found… line and executed new RuntimeException().printStackTrace() There's the full stack trace from running @JOSM:
java.lang.RuntimeException
	at org.apache.commons.jcs.utils.threadpool.ThreadPoolManager.configure(ThreadPoolManager.java:324)
	at org.apache.commons.jcs.utils.threadpool.ThreadPoolManager.<init>(ThreadPoolManager.java:96)
	at org.apache.commons.jcs.utils.threadpool.ThreadPoolManager.getInstance(ThreadPoolManager.java:202)
	at org.apache.commons.jcs.engine.control.event.ElementEventQueue.<init>(ElementEventQueue.java:56)
	at org.apache.commons.jcs.engine.control.CompositeCacheManager.initialize(CompositeCacheManager.java:276)
	at org.apache.commons.jcs.engine.control.CompositeCacheManager.getUnconfiguredInstance(CompositeCacheManager.java:214)
	at org.openstreetmap.josm.data.cache.JCSCacheManager.initialize(JCSCacheManager.java:156)
	at org.openstreetmap.josm.data.cache.JCSCacheManager.getCache(JCSCacheManager.java:191)
	at org.openstreetmap.josm.gui.layer.AbstractCachedTileSourceLayer.getCache(AbstractCachedTileSourceLayer.java:118)
	at org.openstreetmap.josm.gui.layer.TMSLayer.getCache(TMSLayer.java:144)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:830)

Addressed in https://github.com/apache/commons-jcs/commit/b9fb77b351690414335d9bb8864b7f21e13e7a23


added internal flag to the AttributeMetadataFilter

Not sure if this was meant for review yet or not, but the implementation is missing (see https://github.com/hypertrace/attribute-service/blob/main/attribute-service-impl/src/main/java/org/hypertrace/core/attribute/service/AttributeServiceImpl.java#L361 ) and tests please.

LGTM - will let @skjindal93 re-review.
For snyk, can we please get that green either in this PR or as a followup.


New 0.60.5 app fails to run in Firebase Test Lab Pixel, API Level 26

New 0.60.5 app created via init fails Robo test when using Android Application Bundle in Firebase Test Lab on Pixel, API Level 26 (and more).
React Native version:
System:
    OS: Linux 4.15 Ubuntu 18.04.3 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
    Memory: 1.50 GB / 15.43 GB
    Shell: 4.4.20 - /bin/bash
  Binaries:
    Node: 10.14.2 - ~/.nodenv/versions/10.14.2/bin/node
    Yarn: 1.17.3 - /usr/bin/yarn
    npm: 6.4.1 - ~/.nodenv/versions/10.14.2/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    Android SDK:
      API Levels: 23, 25, 26, 27, 28
      Build Tools: 27.0.3, 28.0.3
      System Images: android-19 | Intel x86 Atom, android-22 | Google APIs Intel x86 Atom, android-24 | Google Play Intel x86 Atom, android-27 | Intel x86 Atom, android-27 | Intel x86 Atom_64, android-27 | Google Play Intel x86 Atom, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom
  npmPackages:
    react: 16.8.6 => 16.8.6
    react-native: 0.60.5 => 0.60.5
  npmGlobalPackages:
    react-native-cli: 2.0.1

Steps To Reproduce

react-native init AwesomeProject2
cd AwesomeProject2/android && ./gradlew bundleRelease
Upload app.aab to Firebase Test Lab and run Robo test on Pixel, API Level 26

Describe what you expected to happen:
A successful test.
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so

FATAL EXCEPTION: create_react_context
Process: com.awesomeproject2, PID: 13159
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so
	at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
	at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
	at com.facebook.hermes.reactexecutor.HermesExecutor.<clinit>(HermesExecutor.java:20)
	at com.facebook.hermes.reactexecutor.HermesExecutorFactory.create(HermesExecutorFactory.java:27)
	at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:949)
	at java.lang.Thread.run(Thread.java:764)

web-build_2019-08-15T13:49:10.847Z_lej5_sailfish-26-en_US-portrait_logcat.log
app.aab.gz

Having the same problem here, uploaded my app to the google play store, it works fine on emulator(both downloading it from the play store and directly react-native run-android).Should i be concerned about an unhandled error?

I've been in contact with Firebase team in regards to this.
I too was having the same similar issue being reported by Firebase Crashlytics.
From Firebase support:

Upon investigation, our Test Lab engineers observed a known bug in which matrices that were intended to complete successfully were being marked "ERROR" and stuck in "PENDING".
They have worked on a fix for this, but we're still yet to confirm if it's been rolled out in public.

After this supposed update to Test Lab, after uploading a new build to Google Console, I am no longer receiving this previously reported crash.
To note: My crash was being reported on a Nexus 5X.
This maybe be very much related to the issue you mentioned and might be worth trying to upload a new build to test and see if it triggers a crash being reported.

Hi, I am still having the same issue with that Nexus 5X. It just happened today, is the bug fixed or is there any update about this bug?
Thanks!


PEHA D 451 FU-BM

Manufacturer: PEHA
Model: D 451 FU-BM
Production date/period:
Link to product:

In version 0.3.7


Upgrade WildFly Core to 2.0.0.Alpha1

Windows Build 1564 is now running using a merge of 100bb281cccc85124d0e93b62c8dd66a5aa9beeb

Linux Build 6486 is now running using a merge of 100bb281cccc85124d0e93b62c8dd66a5aa9beeb

Linux with security manager Build 1392 is now running using a merge of 100bb281cccc85124d0e93b62c8dd66a5aa9beeb

Linux with security manager Build 1392 outcome was SUCCESS using a merge of 100bb281cccc85124d0e93b62c8dd66a5aa9beeb
Summary: Tests passed: 821, ignored: 319 Build time: 0:07:51

Windows Build 1564 outcome was SUCCESS using a merge of 100bb281cccc85124d0e93b62c8dd66a5aa9beeb
Summary: Tests passed: 2863, ignored: 374 Build time: 0:47:32

Linux Build 6486 outcome was SUCCESS using a merge of 100bb281cccc85124d0e93b62c8dd66a5aa9beeb
Summary: Tests passed: 2862, ignored: 374, muted: 1 Build time: 0:48:21


Vulkan: GPUParticles Bounce is tied to Fixed Fps

Godot version
v4.0.alpha.custom_build [d28944834]
System information
Linux, Vulkan
Issue description
The Particle bounces are locked to framerate
and the difference it huge
Steps to reproduce
change particle framerate and bouncyness 1 big difference
Minimal reproduction project
TooBouncy.zip
(wait 5 secs for them to spread, left is 30, right is unlocked framerate)

This is expected, as simulating collisions accurately isn't possible at very low FPS. I recommend keeping Fixed Fps to 20 at least (and preferably 30 or higher).

yeah, but i always set the fps to 0 for smoothesd

yeah, but i always set the fps to 0 for smoothesd

Setting Fixed Fps to 0 will make particle behavior depend on the rendering FPS, so this is not recommended.


chore: update github runners to ubuntu-24.04

:tada: This PR is included in version 6.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[Distributed] Polishing the stubbing DistributedProtocol macro

This corrects the implementation of the distributed macro to fill in stubs even in the concrete type.
The extension emitted by the macro "technically" provides those default implementations, but because extension macros run after peer macros this duplication is necessary.
We solved the root cause in https://github.com/apple/swift/pull/71717 so the workarounds here are not necessary, will remove them once https://github.com/apple/swift/pull/71717 lands. We can emit only the one place.
Also polishing up the macro while at it -- now handling access control.

@swift-ci please smoke test

This can either be seen as a workaround for https://github.com/apple/swift/pull/71719 OR the proper way such macros should be implemented -- depending which way we want to go with macro expansion ordering.

@swift-ci please smoke test

Instead of emitting twice this now depends on: https://github.com/apple/swift/pull/71717

@swift-ci please smoke test


previous_model setters fail when writer method is not defined / raises exception

We ran into an issue that prevents us from using counter_culture.
A model that does not define a setter method for a database attribute will raise an exception when using counter_culture. We find this a useful pattern for fields that store the side effect of another action but should not be updated directly. See this example activerecord class:
create_table :users do |t|
  t.string :first_name
  t.string :last_name
  t.string :name
end

class User < ActiveRecord::Base
  def name=(new_name)
    fail "Do not set name directly, instead set first_name or last_name"
  end
  def first_name=(*args)
    super
    write_attribute(:name, "#{first_name} #{last_name}")
  end
  def last_name=(*args)
    super
    write_attribute(:name, "#{first_name} #{last_name}")
  end
end

Using counter_culter with this class will fail when it iterates through changed_attributes and creates a copy by assigning each attribute. Do you plan to support any other options here? Using write_attribute, for example, would work in our case. Or disabling this when it's not used?
The code that iterates through each attribute and sets them using writer methods is at:
lib/counter_culture.rb:355
Thanks,

Graham

Graham -- yes, that'd be a change I'd be happy to merge. Can you put together a pull request? Thanks!

Graham -- wanted to follow up here and see if you can put together a pull request for this? Thanks.

Hey there,
We ended up not needing this plugin and just went with the default rails counter's for our app. If we end up needing this in the future I may be able to dedicate some time to come up with a patch but not currently a need for us. Closing the issue since there doesn't seem to be much of a need outside of our use case.


Error generating code. Check the Developer Console AND the backend logs for details. Feel free to open a Github issue.

ERROR:    Exception in ASGI application
Traceback (most recent call last):
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/uvicorn/protocols/websockets/websockets_impl.py", line 247, in run_asgi
result = await self.app(self.scope, self.asgi_receive, self.asgi_send)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/uvicorn/middleware/proxy_headers.py", line 84, in call
return await self.app(scope, receive, send)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/fastapi/applications.py", line 276, in call
await super().call(scope, receive, send)
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/starlette/applications.py", line 122, in call
await self.middleware_stack(scope, receive, send)
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/starlette/middleware/errors.py", line 149, in call
await self.app(scope, receive, send)
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/starlette/middleware/cors.py", line 75, in call
await self.app(scope, receive, send)
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/starlette/middleware/exceptions.py", line 79, in call
raise exc
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/starlette/middleware/exceptions.py", line 68, in call
await self.app(scope, receive, sender)
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/fastapi/middleware/asyncexitstack.py", line 21, in call
raise e
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/fastapi/middleware/asyncexitstack.py", line 18, in call
await self.app(scope, receive, send)
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/starlette/routing.py", line 718, in call
await route.handle(scope, receive, send)
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/starlette/routing.py", line 341, in handle
await self.app(scope, receive, send)
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/starlette/routing.py", line 82, in app
await func(session)
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/fastapi/routing.py", line 289, in app
await dependant.call(**values)
File "/Users/hesoso/Desktop/screenshot-to-code/backend/main.py", line 149, in stream_code
completion = await stream_openai_response(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/hesoso/Desktop/screenshot-to-code/backend/llm.py", line 23, in stream_openai_response
completion = await client.chat.completions.create(**params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/openai/resources/chat/completions.py", line 1191, in create
return await self._post(
^^^^^^^^^^^^^^^^^
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/openai/_base_client.py", line 1474, in post
return await self.request(cast_to, opts, stream=stream, stream_cls=stream_cls)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/openai/_base_client.py", line 1275, in request
return await self._request(
^^^^^^^^^^^^^^^^^^^^
File "/Users/hesoso/Library/Caches/pypoetry/virtualenvs/backend-OF4-y6Ak-py3.12/lib/python3.12/site-packages/openai/_base_client.py", line 1318, in _request
raise self._make_status_error_from_response(err.response) from None
openai.NotFoundError: Error code: 404 - {'error': {'message': 'The model gpt-4-vision-preview does not exist or you do not have access to it. Learn more: https://help.openai.com/en/articles/7102672-how-can-i-access-gpt-4.', 'type': 'invalid_request_error', 'param': None, 'code': 'model_not_found'}}
INFO:     connection closed

+1

https://github.com/abi/screenshot-to-code/issues/117


Viewer does not render data from a filled pdf (all data blank)

Try rendering the attached document in the demo viewer: all fields appear blank.
1 pager malfunctioning file.pdf
This issue is critical for all users who need to use fillable pdf documents.

This is not an acroform problem (although I suspect this is a flattened form). The problem is a missing font, as shown in this error message: "Error during font loading: Font Ffcs1 is not available". Just use some default font.

Should this be closed as fixed now, given the PR referenced above?


Add a cheatcode to skip tests on condition, with clear output

Component
Forge
Describe the feature you would like
When coding a test harness for live contracts, it is not possible to know in advance the state the the smart contracts will be in. Therefore, some tests will make sense, and others will not.
For example, we might have a set of tests that make sense on a given uninitialized contract, but once the contract is initialized it would make more sense to skip those tests and move on to the next ones in the same file.
There is an easy workaround in making the test return if a certain condition is met, with a console log to say that the test was skipped. However, in the output it still comes as PASS and that might lead to confusion.
I would very much prefer if the test would show as SKIP, and maybe even in the summary at the end ("67 passed, 32 skipped, 0 failed", for example).
Additional context
In this test file, this test only makes sense in the contract is in an EJECTED state after the setup function.

Moving to #1123, thanks @mds1!


[BUG] CRPS not defined in get_method function in verification interface

Variable CRPS is not defined in get_method() function of pysteps.verification.interface module. Trying to call function with name='crps' raises NameError.
Steps to reproduce:
In [1]: import pysteps
In [2]: pysteps.verification.get_method('crps', 'probabilistic')
NameError                                 Traceback (most recent call last)
 in ()
----> 1 pysteps.verification.get_method('crps', 'probabilistic')
~/Nowcasting/pysteps/pysteps/verification/interface.py in get_method(name, type)
142
143         if name in ["crps"]:
--> 144             return CRPS
145         elif name in ["reldiag"]:
146             return reldiag_init, reldiag_accum, reldiag_compute
NameError: name 'CRPS' is not defined

Thank you @dnerini for this bugfix. However, commit https://github.com/pySTEPS/pysteps/commit/5e13ed98ce5b2dfbbc363c088191503b5ed18491 introduces a new fatal bug: import pysteps fails and raises IndentationError: unexpected indent at line 128 of pysteps.verification.interface.py .
Fix this by adding parenthesis around imported functions at lines 127-128 and 142-143. For example:
from .ensscores import (ensemble_skill, ensemble_spread, rankhist_accum,
                        rankhist_compute)


Runtime issues with Visual Studio 2015

I tried to build libhoard on windows with VS2015 using nmake. It built successfully. But when I try to run a sample program using hoard, It crashes in the following call stack :
ntdll.dll!RtlReportCriticalFailure()    Unknown
ntdll.dll!RtlpReportHeapFailure()   Unknown
ntdll.dll!RtlpHeapHandleError() Unknown
ntdll.dll!RtlpLogHeapFailure()  Unknown
ntdll.dll!NtdllpFreeStringRoutine() Unknown
ntdll.dll!RtlFreeUnicodeString()    Unknown
ntdll.dll!LdrpSnapThunk()   Unknown
ntdll.dll!LdrGetProcedureAddressEx()    Unknown
ntdll.dll!LdrGetProcedureAddress()  Unknown
KernelBase.dll!GetProcAddress() Unknown
libhoard.dll!PatchMe() Line 594 C++
libhoard.dll!DllMain(void * hinstDLL, unsigned long fdwReason, void * lpreserved) Line 122

It's a simple program to allocate memory :
int main()
{
    char *str = NULL;
    int rc = ERROR;

    printf("Allocating a buffer...\n");
    str = (char*)malloc(MAX_BUF_SIZE*sizeof(char));

    if (str == NULL)
    {
        printf("Allocation of buffer failed !!! Exiting... \n");
        return ERROR;
    }

    strncpy(str, "Hello", 6);
    printf("Entered string is : %s\n", str);
    return OK;
}

It's a visual studio project where I added source/uselibhoard.cpp as additional source file and libhoard.lib in the linker options. Please check the attached screenshots.

Which version of Windows are you using?

I am using Windows 2008 server R2.
On 02-Aug-2016 10:38 pm, "Emery Berger"<EMAIL_ADDRESS>wrote:

Which version of Windows are you using?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/emeryberger/Hoard/issues/27#issuecomment-236972435,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGdc3-J42eAIia15D5xD_0U8QFgl-Ph5ks5qb3lxgaJpZM4JZBHj
.

This works for me on Windows 10 with the latest commits.


"Config flow could not be loaded: undefined" error upon attempting to add integration

The logs show only this:
Logger: homeassistant.util.package
Source: util/package.py:99
First occurred: 11:19:53 (3 occurrences)
Last logged: 11:19:57

Unable to install package asusrouter==0.3.2: ERROR: Will not install to the user site because it will lack sys.path precedence to urllib3 in /snap/home-assistant-snap/501/lib/python3.9/site-packages WARNING: You are using pip version 22.0.4; however, version 22.1 is available. You should consider upgrading via the '/snap/home-assistant-snap/501/bin/python3.9 -m pip install --upgrade pip' command.

FYI I am running home-assistant-snap and an AC-86U router in case that makes a difference.

Hello, @bkuri,
Thanks for your feedback 👍🏻
I am afraid, this issue should be addressed to the home-assistant-snap since the log does only say "unable to install" of the library behind the integration (which is freely available to anyone with Python 3.9+ via PyPI).
Installation of the required packages is supposed to be done by HA automatically (and this is how it works on usual HA Core installations). As for the snaps, unfortunately, I don't have any experience with them.
But, of course, if the developers of ha-snap can explain what exactly is the problem (if this is library-related), I can implement the needed changes to the library.
If you decide, to open an issue in the snap repository and you would require any help from my side, you can always mention me as @Vaskivskyi, so I will be notified about it.

Hey,
Since the issue is not connected to the integration directly, I will close it for now.
If you will find a way to fix this behaviour of the installation on snaps, please reopen the issue or open a new one. Maybe we can then add this info to the readme for other users to use.

Of course, I may take a look, but cannot promise anything. Also, I will first need to find out how exactly snaps work (never used them before).
The integration does not specify where or how to install, because it doesn't even know anything except how to call Home Assistant features.
Cannot guarantee any timeframe, unfortunately. But I will let you know if I find a solution.

@Vaskivskyi thanks! Let me know if there's anything I can do to help

Unfortunately, I have not found anything that I could do from the integration point of view. As I have mentioned, all the dependencies installations are handled by HA directly and do not depend on the integration itself.
Sorry for not being able to help you. I will close the issue as one that cannot be solved.


Track more safety invariants in the type system

Meta - about this PR
This is a byproduct of attempting to figure out #278 by "asking the compiler if it sees a problem".
The idea seemed to be possibly useful, so this should be viewed almost like a draft/suggestion.
Description
This change creates several wrappers around unsafe operations to
better track the safety invariants. While not perfect, which should
reduce the number of footguns in the code.
It focuses on locking - using primitives like mutex guards known from
std. The locked state is tracked in those guards. This crate needs
some special features however. It needs to lock all locks in a slice and
unlock them in the same order. Similarly it needs to lock a queue inside
a Bucket while keeping reference to the bucket.
Additional specialized wrappers maintain safety of these advanced
operations similarly to guards. They are implemented in their own
modules to avoid access from other parts of code.
This change comes with two more side effects:

Cell was removed from the bucket as now locking provides required
safety.
Bucket pair uses Option to represent same buckets. This adds a
slight performance penalty but it's in slow path and may be optimized
out by the compiler. It's even possible that absence of Cell will
enable even more optimizations.

Ah, this has lower MSRV. I'm too exhausted to fix it now. Will come back later.
Some more ideas to consider:

Implement queue operations as methods on Queue
Add BucketPair wrapper type holding the pair, providing a nice getter and ensuring correct drop order. (unrelated to #278 but nice to have)


Fix File.is_public default value

Currently whenever FILER_IS_PUBLIC_DEFAULT is changed, makemigrations generates a new migration for filer's File model. Changing the default value to use a callable mitigates this problem.

Since adding new migrations to separate PRs is a pain, I just added additional fix here: make File._file_size a BigIntegerField. Currently, django-filer fails to upload files larger than max int (signed) in database just because of this field.

If your patch will not set a default on database level, is this an issue? It will have a default of True, because of older migrations, right? Or is the default handled "ORM" only, ie will not work at all when inserting without ORM?

@benzkji, Django model fields never save default values at database level. It's always handled by ORM.

@skirsdeda true, just checked my db. thanks!

How about merging this? Broken Travis seems to be a OSX issue (pip: command not found) and not an issue with the changes?

@skirsdeda could I ask you to split this in two PR? I swear I will merge them promptly and in the right order :bowing_man:

@yakky, not sure why travis build is still failing but should be good.

For some reason macos builds are failing again

(not related to this PR, I'm thinking to merge this anyway and have a look at the build failures later)

@yakky You also added 0008 migration in #1030 so that one will have to be renumbered to 0010 and dependencies changed 0009 if these 2 are to be merged sooner.

@skirsdeda this will surely land before the django 2.0 related ones. A rebase of those is needed anyway. Thanks for the heads up

@skirsdeda I cherry-picked commits on a sane develop branch which builds on osx (hopefully)

Merged with #1054


draggable cannot be set to "false"

I am using 3.4.0
I have set an element to draggable='false' but result it is always draggable="true" in the DOM
Example:
https://github.com/foray1010/Popup-my-Bookmarks/blob/preact/js/_components/popup/components/BookmarkItem.jsx#L494
https://github.com/foray1010/Popup-my-Bookmarks/blob/preact/js/_components/popup/components/BookmarkItem.jsx#L500

Hi @foray1010 - you need to use an actual Boolean value:
<a draggable={false} />

thanks! It is working now!

Great :)


page.exit type is wrong

The type for the function page.exit is
  function exit(path: string, callback: Callback, moreCallbacks?: Callback[]): void;

but it should be
  function exit(path: string, callback: Callback, ...moreCallbacks: Callback[]): void;

Thanks. Feel free to open a PR 🌷

Yes, I tried actually, as you can see I forked the repo but I'm not able to run the build and the tests, so I'm not sure how to proceed. I hope you can fix this

Got it. I take a look at it and the tool chain is pretty outdated.
Have made the change without tests.


Improve patient bulk upload failed processing messages

Background
When certain users upload patients to SimpleReport, their file passes initial validation but fails during the second processing stage. The email they receive then instructs them to try uploading again, which leads to the same results.
Action requested
We need to better set expectations for users that their file has to go through processing after it completes validation. If their file fails, we need to give them more actionable, less frustrating next steps.
1. Step 3 in "Import from spreadsheet" page

Add "processing" before "adding your patients"

2. Data validation success message

Remove "Success:" from header, which suggests process is complete
Add "processing" to the message
Slightly reword message to accommodate changes
Note: Could be useful to get data on average processing time to help inform this message in the future, if possible

3. Processing failure email

Remove mention of trying to upload again
Remove button to visit SimpleReport
Add range of reasons that upload could have failed
Put call-to-action about contacting support on its own line

Acceptance Criteria

[ ] Validation success message mentions processing and sets expectation of potential failure
[ ] Processing failure email better conveys what went wrong
[ ] Processing failure email immediately directs user to reach out to SR Support

Additional context
Current validation success message:

Current processing failure email:

@mehansen @jayna-SkylightDigital I suggested some language updates at three different touchpoints — step 3 in the upload page, the validation success message, and the upload failure email — outlined above in the Action requested section. Let me know if you have any feedback or want to talk about it more!


react/19/replace-default-props does not add ES6 default parameters

The example nicely shows that default props from defaultProps will be added to the component props as shown in this example https://github.com/codemod-com/codemod/tree/main/packages/codemods/react/19/replace-default-props.
However, when I am running npx codemod react/19/replace-default-props it only removes defaultProps and not adding default props to destructured component props. Even when I tried to just have the exact code from the mentioned example, it only removed this block:
Button.defaultProps = {
    size: '16px',
    color: 'blue'
}

and the rest was left untouched
const Button = ({ size, color }) => {
    return <button style={{ color, fontSize: size }}>Click me</button>;
}

I worked on codemod in version 0.13.3.
Tested on project either in pure js or TS with tsx files.
Tested either on Node 18.17.1 or 20.15.1.
Tested on React either 18.3.1 and 18.2.0. Not sure if it matters.
All of them resulted in removing only defaultProps and not adding ES6 default parameters to component.

Thanks for reporting this @quarhodron! @DmytroHryshyn will be away for some time. @arybitskiy can you please take a look at this?

@mohab-sameh do you think @arybitskiy will be able to still look at it because it seems he hasn't done any commits recently

I'm also seeing the same issue.
Initially the codemod was returning "No changes were made during the codemod run.". I think this is because much of our code is in the following format:
const defaultProps = {
    size: '16px',
    color: 'blue',
};

const Button = ({ size, color }) => {
    return <button style={{ color, fontSize: size }}>Click me</button>;
}

Button.defaultProps = defaultProps;

If I manually remove the defaultProps variable to match the example, the Button.defaultProps assignment is simply removed without updating the destructured props.

@amirabbas-gh and I pushed a fix to the registry. try it out and let me know if there’s still an issue. Just run:
npx codemod@latest react/19/replace-default-props --no-cache
@rickhanlonii, we should be good to close this issue now.
(fyi, this codemod was never checked into this repo or the official migration guide. It lives here: https://github.com/codemod-com/Commons/tree/main/react/19/replace-default-props and in the registry)