Curl: Add methods to parse response

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

Overview
This work was originally part of #9535 and then #10834 (a recreation of the former PR) but I've refactored the methods to make them a bit more general purpose here. While working on migrating livecheck to curl, it became apparent that there are a few areas in brew where similar code exists to parse curl output.
The intention of this PR is to provide methods for working with curl output in a standardized way, so we can avoid unnecessary code duplication. Notable changes are as follows:

Adds parse_curl_output and parse_curl_head methods to parse curl output (a string containing response head(s) and/or the final response body). The code in these methods is partly taken from existing code in brew, as the aim is to replace existing code with these methods. The main difference is that these methods parse response heads into hashes and organize the data in a specific fashion (so we're not reinventing the wheel in multiple locations).
Adds curl_response_status_code and curl_response_last_location methods that take the parsed output from the aforementioned methods and extract specific information (the status code of the last response and the last location header, respectively).
Expands Utils::Curl tests to cover the new methods.

Example
If we have curl output like:
HTTP/2 301 \r
date: Mon, 26 Apr 2021 15:06:34 GMT\r
content-type: text/plain; charset=utf-8\r
content-length: 21\r
location: https://example.com/\r
\r
HTTP/2 200 \r
content-encoding: gzip\r
cache-control: max-age=604800\r
content-type: text/html; charset=UTF-8\r
date: Mon, 26 Apr 2021 15:09:15 GMT\r
last-modified: Mon, 26 Apr 2021 12:34:56 GMT\r
content-length: 169\r
\r
<!DOCTYPE html>

    <meta charset="utf-8">
    <title>Example</title>

Example

Hello, world!

parse_curl_output will produce a hash like:
{
  heads: [
    {
      status_code: "301",
      headers: {
        "date"           => "Mon, 26 Apr 2021 15:06:34 GMT",
        "content-type"   => "text/plain; charset=utf-8",
        "content-length" => "21",
        "location"       => "https://example.com/"
      }
    },
    {
      status_code: "200",
      headers: {
        "content-encoding" => "gzip",
        "cache-control"    => "max-age=604800",
        "content-type"     => "text/html; charset=UTF-8",
        "date"             => "Mon, 26 Apr 2021 15:09:15 GMT",
        "last-modified"    => "Mon, 26 Apr 2021 12:34:56 GMT",
        "content-length"   =>  "169"
      }
    }
  ],
  body: "<!DOCTYPE html>\n\n  \n    <meta charset=\"utf-8\">\n    <title>Example</title>\n  \n  \n
Example
\n
Hello, world!
\n  \n\n"
}

The response heads are parsed using parse_curl_head, which produces a hash containing the status code and header strings.
If we provide the heads array (the first member of the output array from parse_curl_output), it returns "200". If we do the same with curl_response_last_location, it returns "https://example.com/".
Conclusion
This PR only focuses on adding these methods and I would appreciate feedback on the shape of this. I'll add comments in places that I think may benefit from discussion.
If/when this is merged, I'll create a follow-up PR that replaces existing code with these methods (as it was suggested that it may be better to keep this separate). I'll be rebasing #10834 onto this shortly and I'll also update that PR to account for any changes that we make here in review.

Review period will end on 2021-04-27 at 16:48:56 UTC.

Review period ended.

This PR only focuses on adding these methods and I would appreciate feedback on the shape of this. I'll add comments in places that I think may benefit from discussion.
If/when this is merged, I'll create a follow-up PR that replaces existing code with these methods (as it was suggested that it may be better to keep this separate). I'll be rebasing #10834 onto this shortly and I'll also update that PR to account for any changes that we make here in review.

I'll need to see the planned usage of these methods before I can give decent review. I don't think it's worth designing them divorced from their planned usage. If that means #10834 is the demonstration of this: ok but please let's try and do what we can to get that merged ASAP, thanks.

I'll need to see the planned usage of these methods before I can give decent review. I don't think it's worth designing them divorced from their planned usage.

I have a separate branch [based on this one] for the commits that make changes to adopt the methods in this PR but I've merged it into this branch so you can see what code it's intended to replace and how it works in practice. If we still want to handle those changes separately (per https://github.com/Homebrew/brew/pull/10834#pullrequestreview-610798500), I can always pare this back to the existing commit before we consider merging.

# Duplicate of #

@samford What's the latest here? Thanks ❤

I remembered this PR last week and had been meaning to come back to it, so thanks for the reminder.
I had previously put this on hold until I could look into the Typhoeus (or Ethon) gem but that approach may not end up being feasible. When I originally brought it up, you suggested it could be a possibility if it doesn't build native extensions. It initially looked promising because it doesn't build native extensions on macOS but I later discovered it does on Linux. Namely, typhoeus depends on ethon which depends on ffi, which builds native extensions on Linux.
There may be some way around it but I think it makes sense to move this PR forward in the interim time. Regardless of how we approach curl in the long-term, this PR will clean up some duplicated code for the time being.
I've incorporated some of the suggested changes locally and I'll update this branch after I've responded to the unresolved comments.

I receive a Could not resolve to a node with the global id of 'MDE3OlB1bGxSZXF1ZXN0UmV2aWV3'. error when trying to reply to the open comments, so I'm going to have to respond to them separately. Pardon the relative inconvenience.

-       return if !appcast_contents || appcast_contents.include?(adjusted_version_stanza)
+       return if appcast_contents&.include?(adjusted_version_stanza)

Unfortunately, using the safe navigation operator wouldn't achieve the same goal. If appcast_contents is nil, the safe navigation operator would evaluate to nil, the condition won't be true, and #check_appcast_contains_version won't return early. As a result, the subsequent error message about the appcast not containing the version number will apply, which doesn't make sense if we weren't able to check the appcast content.
As one example, this would occur if the curl request in #curl_http_content_headers_and_checksum exceeds the timeout, as details[:file] would be nil in the return hash.
It may be better to handle a falsy appcast_contents value with a different error message before this point (e.g., "appcast at URL '...' could not be retrieved"), making it clear that we didn't get the appcast content. This is arguably better than silently failing, which would erroneously suggest the appcast was successfully retrieved and contained the version.
If we want to go that route, we could avoid duplicating the rescue error by simply setting appcast_contents = nil in the rescue block and then handle the error and early return outside of it. This would handle both types of failures equally.

What is a response "head"? Headers?

A "head" here is the status line and header lines for one HTTP response (i.e., not the body). The heads array can contain head hashes from multiple responses. [Examples of the head hash format can be found in curl_spec.rb.]
For a response with no redirections, the curl output can consist of a head (the status line and headers) and/or a body (the content). When there are redirections, the curl output would contain heads for multiple responses. The head(s) and the body are separated by \r\n\r\n and that's what we use to #partition the output.

When is the output [in #parse_curl_output] not a string and what else can it be?

I'm not sure it would ever be anything other than a string but my original thinking was that this would allow us to gracefully handle bad input and avoid an error (since output needs to be a string for output.lstrip, output.match(...), and output.include?(...) to work).
Looking at a later comment in the previous review, it does feel more appropriate to use a Sorbet type signature instead of this explicit guard, so I'll update this accordingly.

When is head_text not a String and what else can it be? Duck typing and Sorbet feel like they may help avoid these manual type checks.

Same as above, I don't imagine this would ever be anything other than a string and I'll replace the !head_text.is_a?(String) condition with a Sorbet type signature as well.

[#parse_curl_head] seems to only be used once so I'd suggest it may be better moved from utils.

It's only used in #parse_curl_output, so it could technically be inlined but I opted for a separate #parse_curl_head method to make the former easier to read. I've made #parse_curl_head private for the moment (it wasn't my intention for it to be offered as a public method unless/until it's needed) but let me know if you had something different in mind.

GitHub isn't allowing me to comment on certain threads again (Could not resolve to a node with the global id of 'MDE3OlB1bGxSZXF1ZXN0UmV2aWV3'.), so I have to address one discussion individually here.

A "head" here is the status line and header lines for one HTTP response (i.e., not the body). The heads array can contain head hashes from multiple responses. [Examples of the head hash format can be found in curl_spec.rb.]
For a response with no redirections, the curl output can consist of a head (the status line and headers) and/or a body (the content). When there are redirections, the curl output would contain heads for multiple responses. The head(s) and the body are separated by \r\n\r\n and that's what we use to #partition the output.

I think heads could get a better name here, it's not obvious what it means from this alone. Perhaps incorporate some of the above into the comment?

I agree that heads isn't a terribly evocative or recognizable name. responses may be more understandable, as long as users understand that the :responses hashes from #parse_curl_output don't include body content (i.e., :body is implicitly the body from the final response).
I've gone ahead and updated all the related code/language in the latest push to use responses/response/etc., so let me know what you think of this aspect of the latest changes.

I agree that heads isn't a terribly evocative or recognizable name. responses may be more understandable, as long as users understand that the :responses hashes from #parse_curl_output don't include body content (i.e., :body is implicitly the body from the final response).

responses_headers or something?

I did some manual testing over the past couple days and didn't encounter any related failures. I looked over these changes another time and the only thing that stuck out was that I forgot to commit the aforementioned break in Strategy#page_headers. I've added it in this latest push and this should be good to go at this point.
I'm going to bed over here and I'll merge this in the morning (EDT), so I'll be around if anything starts smoking 😆

Merging now. Thanks for your patience and all the review along the way, @MikeMcQuaid!

Great work thanks @samford!

Hey @samford, there's something in this PR that is causing some audits to fail on the cask side of things. I've drilled it down to this commit.
Here's a couple of examples;
https://github.com/Homebrew/homebrew-cask/pull/122377
https://github.com/Homebrew/homebrew-cask/pull/122490
The files are fetched correctly, however the URL is still failing the audit
audit for opencore-configurator: failed
 - The binary URL https://mackie100projects.altervista.org/apps/opencoreconf/download-new-build.php?version=last is not reachable
Error: 1 problem in 1 cask detected

I may be able to do some more digging tonight - but not for a few hours.

@bevanjkay I wasn't able to replicate this locally with the opencore-configurator changes but I'm able to replicate this with the visual-paradigm PR. What I'm seeing is that curl fails on the binary URL with a 28 error, meaning the curl_output call is timing out after the 25 seconds max_time limit. This issue manifests for visual-paradigm because the dmg is ~750 MB. Even if the file was successfully fetched before (i.e., cached locally), it's downloaded again and times out.
This issue was introduced in the Curl: Update to use response parsing methods commit because it changed the behavior of #curl_http_content_headers_and_checksum so that it only parses the curl output on status.success?. If I'm understanding correctly, the previous behavior may have been parsing the intermediate responses (redirection(s), in this case) but not the final response that was timing out. The behavior introduced in this PR doesn't return information from any responses because I moved the response parsing logic into the if status.success? block.
I tested this and it should be as simple as moving the parsing logic back to its previous location, so it isn't guarded by status.success? anymore. This reinstates the old behavior and allows the audit to pass in this particular scenario. I'll have to look into this further tomorrow (it's a weird situation) but I'll open a PR for the fix in a moment.

How do we best handle third party taps which may be hit by the new redirection limit? Just tell them to change their formula?
https://github.com/orgs/Homebrew/discussions/3215

How do we best handle third party taps which may be hit by the new redirection limit?

This shouldn't be something that anyone needs to think about, so I think we should just increase the default max_iterations value to something that's really unlikely to be reached in practice. max_iterations should almost never come into play (i.e., it's not intended to restrict redirections, as that should be done using curl's --max-redirs option) but the current default is low enough that it has sometimes been reached under normal circumstances. I think something like 25 is probably fine, where it's high enough to only come into play if something weird is going on but low enough that we won't have to go through a bunch of needless iterations if/when it does. I'll open a PR for this in a moment.
Long term, we may want to figure out a programmatic way of setting the limit for the while loop (e.g., count the number of instances of \r\n\r\n and/or HTTP status lines in the output), so we don't have to deal with a fixed maximum. If we can accomplish that, it should obviate the need to manually control the max_iterations value (like we're currently doing in Livecheck::Strategy).

I suppose another question would be: any reason for 5 specifically over something more conservative?

5 was just an arbitrary number and there's nothing really special about it. If I remember correctly, our intention was to start low and increase it if we start seeing the related error under normal circumstances. Originally the code in #parse_curl_output lived in the Livecheck::Strategy#page_content method, so it wasn't a huge issue if a check failed for this reason (I typically resolved the error when I saw it by updating URLs). However, now this code is used in important methods like #curl_download, so it's a real problem if it prevents a user from installing a formula/cask (as in the linked discussion).

https://github.com/orgs/Homebrew/discussions/3215
Not sure if proxies are having a further effect on this or not.

I wasn't able to replicate it locally when installing the virt-manager formula from the third-party jeffreywildman/virt-manager tap (my guess at the source of this). If the higher max_iterations default doesn't resolve the issue, it may be something on their end that they need to sort out.

This shouldn't be something that anyone needs to think about, so I think we should just increase the default max_iterations value to something that's really unlikely to be reached in practice. max_iterations should almost never come into play (i.e., it's not intended to restrict redirections, as that should be done using curl's --max-redirs option) but the current default is low enough that it has sometimes been reached under normal circumstances.

👍🏻 fine with me to jump bump this limit to whatever is necessary.

Bumped to 25 in #13202 and tagged in 3.4.9.


How to add video texture to a mesh

Hello,
I am new to libgdx and wanted to know how we can implement a video texture to mesh for Android Devices. I would be grateful if someone could please help me with that.
Thanks :)

You maybe wanna try out gdx-video. Sadly, it isn't yet deployed to sonatype. If you got more questions, I'm on the the discord server


help the typechecker go faster

As I mentioned in https://github.com/borglab/SwiftFusion/pull/66, the Swift typechecker is slow when there are overloaded operators.
We can speed it up without figuring out all the answers in that discussion by giving the compiler hints that help it resolve the overloads.
Before:
marcrasi@marcrasi:~/git/SwiftFusion$ swift package clean && time swift build
[88/88] Linking Benchmarks

real    0m27.196s
user    1m54.372s
sys     0m5.155s

After:
marcrasi@marcrasi:~/git/SwiftFusion$ swift package clean && time swift build
[88/88] Linking Benchmarks

real    0m12.526s
user    1m39.393s
sys     0m4.367s

For future reference, I found the offending expressions with:
swift package clean && swift build -Xswiftc -Xfrontend -Xswiftc -debug-time-function-bodies > compile_times.txt
sort -g compile_times.txt | uniq | tail -n10

Yup, no functional changes here.


Has one bug

Failing test for a bug with hasOne.
Given a hasOne's inverse is a hasMany
when a hasOne is replaced
then the hasOne's owner record should be removed from the hasMany.

Thanks @opsb - I plan to investigate this in the next few days.

I put a whole bunch of tests together when implementing the inverse relationships for orbit-firebase, here's a link in case you find it useful when you're implementing them on Cache, https://github.com/lytbulb/orbit-firebase/blob/master/test/tests/orbit_firebase/unit/operation-decomposer-test.js#L159.


selectionStart should not be nullable: TSJS-lib-generator regression in 2.8.x

TypeScript Version:  2.8.1

Search Terms:
selectionStart, selectionEnd
Code
// Source code from https://github.com/styfle/copee
function fromElement(el: HTMLInputElement | HTMLTextAreaElement, preserveSelection?: boolean) {
    let start = 0;
    let end = 0;
    let success = false;

    if (preserveSelection) {
        start = el.selectionStart;
        end = el.selectionEnd;
    }

    el.select();

    try {
        success = document.execCommand('copy');
    } catch (err) {
        success = false;
    }

    if (preserveSelection) {
        el.setSelectionRange(start, end);
    }

    return success;
}

Expected behavior:
el.selectionStart and el.selectionEnd should return number
Actual behavior:
el.selectionStart and el.selectionEnd actually return number | null
Playground Link:
Playground
Related Issues:
#22381 , https://github.com/styfle/copee/pull/21

looking at the spec, seems like null is a possible value for selectionStart and selectionEnd.

@mhegazy Interesting. It looks like type=text is never null but type=email is null for example.

Is there a way to tell typescript that the HTMLInputElement is type=text?
Also, why did this change in TS 2.8? Was it just wrong the whole time?

Is there a way to tell typescript that the HTMLInputElement is type=text?

Do not think there is a simple way to do this really.

Also, why did this change in TS 2.8?

We auto-generate the library from the webidl file from edge. see https://github.com/Microsoft/TSJS-lib-generator. We have taken an update to the file in 2.8.

Was it just wrong the whole time?

the input file can have bugs, and it can be wrong.. so yes.

if you are sure it is not null, you can use the null assertion operator !

Oh yeah, the null assertion operator is new.
But now that I think about it, the user may pass in an input element that I don't the type.
So I'll just fallback to 0, just in case.
Thanks 👍


crawler: don't hold lock while writing to network

LRU crawler in per-LRU mode only flushes the write buffer to the client socket while not holding important locks. The hash table iterator version of the crawler was accidentally holding an item lock while flushing to the network. Item locks must NOT be held for long periods of time as they will cause the daemon to lag.
Originally the code used a circular buffer for writing to the network; this allowed it to easily do partial write flushes to the socket and continue filling the other half of the buffer.
Fixing this requires the buffer be resizeable, so we instead use a straight buffer allocation. The write buffer must be large enough to handle all items within a hash table bucket.
Hash table buckets are supposed to max out at an average depth of 1.5 items, so in theory it should never resize. However it's possible to go higher if a user clamps the hash table size. There could also be larger than average buckets naturally due to the hash algorithm and luck.

This PR is a two-parter. See the commit message of the second commit, and comments below.
PR TODO's:

[x] Allow partial buffer flushing (not really sure this is necessary; the buffer is small enough that it shouldn't block much)
[x] Add minimum buffering during hash crawl mode to cut down on syscalls.
[x] It passes tests, but anything we can add? Some more manual tests would be smart either way.

twiddled the min_items_per_write define to test the buffer expansion.. works fine.

I've added an lru_crawler mgdump command, which as the commit message says above:
This adds a command "mgdump", which dumps keys in the format:

"mg key\r\nmg key2\r\n"

if a key is binary encoded, it uses the meta binary encoding scheme of
base64-ing keys and appends a "b" flag:

"mg 44OG44K544OI b\r\n"

when the dump is complete it prints an "EN\r\n"

A naiive benchmark of dumping 10 million keys:
$ time echo "lru_crawler metadump hash" | nc -w 1 localhost 11211 | wc -l
10000001

real    0m5.551s
user    0m0.268s
sys     0m2.508s

$ time echo "lru_crawler mgdump hash" | nc -w 1 localhost 11211 | wc -l
10000001

real    0m3.776s
user    0m0.260s
sys     0m2.234s

subtract 1s from the "real" time as that's waiting for the nc timeout.
This is with lru_crawler_sleep=0 - even with it set to the default of 100 it completes the dump in less time.
This dump format is geared towards getting the keys back out so they can be fetched as fast as possible, without having to decode/re-encode the key, by leveraging the metaget format. Metaget can fetch client flags, time remaining, and generally all information needed to copy the item to another memcached server.

Going to let this sit for a few days to make sure I'm happy with it, then add a quick test and the doc/protocol.txt entries. The patch is super trivial since it just reuses the same internal modular interface the rest of the crawl commands use.

Thanks for the fix.
just trying to understand why mgdump took less time than metadump?

The eval function uses 40% less CPU. Printf's are very slow and the mgdump doesn't use one. It's only dealing with the key as well.
This is also setting up for cutting the CPU usage of the dump tool by more than half, which you will see once I take some time to write that up.

Very high odds I merge this this week. I tried a bit to make an "msdump" stream which just straight gives you the ms command + value but there's a lot of plumbing work necessary. I still like the separate streams since it gives opportunities to dump faster than a single connection would allow. More flexible overall at what I hope will be a small cost.

Tested this a bunch with the new mcdumpload. Merged it up.


useFormState Example throwing runtime Error

Did you modify the content of sandpack? seems like this is not not reproducible? can you share more details on how this happened?

https://github.com/reactjs/react.dev/pull/6496 Now its fixed


irmin-pack: Dict should be bounded in memory

I believe this has now been fixed by https://github.com/mirage/irmin/pull/817.

See #817 for a quick workaround


ttn.join hangs

Having issues with the ttn.join command, ttn.status responds, however when a join is attempted the Arduino/IDE seems to hang (nothing prints. have to unplug board from machine to be able to close serial monitor).
Tested with both a custom dev board (SAMD21) and also Arduino Due using TX/RX1, reset pin flipped before calling ttn.status.
Using example code from library (Send).

Additional info:

In range of gateway
The LoRa module is RN2483 v1.0.1

Do you have an example sketch for us to reproduce? Did you try using the 4th retry argument to limit the number of times it retries? See https://github.com/TheThingsNetwork/arduino-device-lib/blob/master/src/TheThingsNetwork.h#L89

`#include <TheThingsNetwork.h>
#include <TheThingsMessage.h>
// Set your AppEUI and AppKey
const char *appEui = "70B3D57EF0001BEF";
const char *appKey = "95CBD7CE8387E60F245C2F01B0C8C215";
#define loraSerial Serial2
#define debugSerial SerialUSB
// Replace REPLACE_ME with TTN_FP_EU868 or TTN_FP_US915
#define freqPlan TTN_FP_EU868
TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);
devicedata_t data = api_DeviceData_init_default;
void setup() {
loraSerial.begin(57600);
debugSerial.begin(57600);
while (!debugSerial && millis() < 10000);
pinMode(17, OUTPUT);
pinMode(28, OUTPUT);
digitalWrite(17, LOW);
delay(1000);
digitalWrite(17, HIGH);
delay(1000);
// Wait a maximum of 10s for Serial Monitor
while (!loraSerial && millis() < 10000);
debugSerial.println("-- STATUS");
ttn.showStatus();
delay(3000);
debugSerial.println("-- JOIN");
ttn.join(appEui, appKey, 2);
digitalWrite(28, HIGH);    // turn the LED off by making the voltage LOW
// Select what fields to include in the encoded message
data.has_motion = true;
data.has_water = false;
data.has_temperature_celcius = true;
data.has_temperature_fahrenheit = true;
data.has_humidity = true;
}
void loop() {
debugSerial.println("-- LOOP");
// Read the sensors
data.motion = true;
data.water = 682;
data.temperature_celcius = 30;
data.temperature_fahrenheit = 86;
data.humidity = 97;
// Encode the selected fields of the struct as bytes
byte *buffer;
size_t size;
TheThingsMessage::encodeDeviceData(&data, &buffer, &size);
ttn.sendBytes(buffer, size);
delay(10000);
}`

appKey ommited:
#include <TheThingsNetwork.h>
#include <TheThingsMessage.h>

// Set your AppEUI and AppKey
const char *appEui = "70B3D57EF0001BEF";
const char *appKey = "";

#define loraSerial Serial2
#define debugSerial SerialUSB

// Replace REPLACE_ME with TTN_FP_EU868 or TTN_FP_US915
#define freqPlan TTN_FP_EU868

TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);

devicedata_t data = api_DeviceData_init_default;

void setup() {
  loraSerial.begin(57600);
  debugSerial.begin(57600);

  while (!debugSerial && millis() < 10000);

  pinMode(17, OUTPUT);
  pinMode(28, OUTPUT);

  digitalWrite(17, LOW);
  delay(1000);
  digitalWrite(17, HIGH);
  delay(1000);

  // Wait a maximum of 10s for Serial Monitor

  while (!loraSerial && millis() < 10000);

  debugSerial.println("-- STATUS");
  ttn.showStatus();

  delay(3000);

  debugSerial.println("-- JOIN");
  ttn.join(appEui, appKey, 2);

  digitalWrite(28, HIGH);    // turn the LED off by making the voltage LOW

  // Select what fields to include in the encoded message
  data.has_motion = true;
  data.has_water = false;
  data.has_temperature_celcius = true;
  data.has_temperature_fahrenheit = true;
  data.has_humidity = true;
}

void loop() {
  debugSerial.println("-- LOOP");

  // Read the sensors
  data.motion = true;
  data.water = 682;
  data.temperature_celcius = 30;
  data.temperature_fahrenheit = 86;
  data.humidity = 97;

  // Encode the selected fields of the struct as bytes
  byte *buffer;
  size_t size;
  TheThingsMessage::encodeDeviceData(&data, &buffer, &size);

  ttn.sendBytes(buffer, size);

  delay(10000);
}

Output before hang:
-- STATUS
EUI: 0004A30B001C4D8F
Battery: 3273
AppEui:<PHONE_NUMBER>000000
DevEui: 0004A30B001C4D8F
Data Rate: 5
RX Delay 1: 1000
RX Delay 2: 2000
Total Airtime: 0.00 s
-- JOIN

It is pretty much based on the Send example, just adding in a reset for the RN2483 and using Pin 28 to indicate status

Thanks @Oliverr. I don't see a reset in your example. Why would you need that?
I would always suggest to first try Send.ino and even remove all accept the first line of the loop() there to just rule out any other causes.

Hardware reset:
digitalWrite(17, LOW);
delay(1000);
digitalWrite(17, HIGH);
delay(1000);

I'll try the send.ino and report back

#include <TheThingsNetwork.h>

// Set your AppEUI and AppKey
const char *appEui = "70B3D57EF0001BEF";
const char *appKey = "OMITTED";

#define loraSerial Serial2
#define debugSerial Serial

// Replace REPLACE_ME with TTN_FP_EU868 or TTN_FP_US915
#define freqPlan TTN_FP_EU868

TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);

void setup() {
  loraSerial.begin(57600);
  debugSerial.begin(57600);

  // Wait a maximum of 10s for Serial Monitor
  while (!debugSerial && millis() < 10000);

  debugSerial.println("-- STATUS");
  ttn.showStatus();

  debugSerial.println("-- JOIN");
  ttn.join(appEui, appKey);
}

void loop() {
  debugSerial.println("-- LOOP");

  // Prepare payload of 1 byte to indicate LED status
  //byte payload[1];
  //payload[0] = (digitalRead(LED_BUILTIN) == HIGH) ? 1 : 0;

  // Send it off
  //ttn.sendBytes(payload, sizeof(payload));

  delay(10000);
}

Produces:
-- STATUS

Looking at your other sketch Serial should be SerialUSB right?

Correct, 'Serial' is an alias of 'SerialUSB'

Hi,
I tried to use it in an AVR, so i found the microcontroller resets itself at a certain moment.
I found that the code fails returning from this funtion:
void TheThingsNetwork::configureEU868(uint8_t sf)
Hope it helps

found it:
change  char dr[1]; per   char dr[2];

You mean at https://github.com/TheThingsNetwork/arduino-device-lib/blob/master/src/TheThingsNetwork.cpp#L614 and https://github.com/TheThingsNetwork/arduino-device-lib/blob/master/src/TheThingsNetwork.cpp#L655?

@Nicolasdejean please verify

I wasn't at the last revision.
the lines are already changed in the last revision
the fix:https://github.com/TheThingsNetwork/arduino-device-lib/pull/157
the lines
https://github.com/TheThingsNetwork/arduino-device-lib/blob/master/src/TheThingsNetwork.cpp#L564 & https://github.com/TheThingsNetwork/arduino-device-lib/blob/master/src/TheThingsNetwork.cpp#L622

Ah, @Oliverr is this the same issue you had? Make sure you are on version 2.0 of the library

@FokkeZB I can confirm I am using 2.0.0, still getting locked up during .join()

Just checked TheThingsNetwork.cpp, showing char dr[2]; on lines 564 and 622

OK, so @mikimite had a different issue then.
@Oliverr what I find weird about your findings with https://github.com/TheThingsNetwork/arduino-device-lib/issues/172#issuecomment-268542507 is that it got stuck at showStatus() and not join() while with https://github.com/TheThingsNetwork/arduino-device-lib/issues/172#issuecomment-268530795 it was indeed join(). The only difference I see is the use of SerialUSB instead of Serial and the digitalWrite() to pin 17. Any idea?

Away at the moment, let me check it in a couple of days.
I will make sure the 2 sketches are setup the same way (resets etc.)

Just got back. Done some tidying and have the following scenarios:
#include <TheThingsNetwork.h>

#define loraSerial Serial2
#define debugSerial SerialUSB

// Replace REPLACE_ME with TTN_FP_EU868 or TTN_FP_US915
#define freqPlan TTN_FP_EU868

TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);

void setup()
{
  loraSerial.begin(57600);
  debugSerial.begin(57600);

  pinMode(17, OUTPUT);
  digitalWrite(17, LOW);
  delay(1000);
  digitalWrite(17, HIGH);
  delay(500);

}

void loop()
{
  debugSerial.println("Device Information");
  debugSerial.println();
  ttn.showStatus();
  debugSerial.println();
  debugSerial.println("Use the EUI to register the device for OTAA");
  debugSerial.println("-------------------------------------------");
  debugSerial.println();

  delay(10000);
}

This works fine:
Device Information

EUI: 0004A30B001C4D8F
Battery: 3263
AppEui: 70B3D57EF0001BEF
DevEui: 0004A30B001C4393
Data Rate: 5
RX Delay 1: 1000
RX Delay 2: 2000
Total Airtime: 0.00 s

Use the EUI to register the device for OTAA
-------------------------------------------

Moving onto the Send scenario, when running this Send example:
#include <TheThingsNetwork.h>

// Set your AppEUI and AppKey
const char *appEui = "70B3D57EF0001BEF";
const char *appKey = "OMITTED";

#define loraSerial Serial2
#define debugSerial SerialUSB

// Replace REPLACE_ME with TTN_FP_EU868 or TTN_FP_US915
#define freqPlan TTN_FP_EU868

TheThingsNetwork ttn(loraSerial, debugSerial, freqPlan);

void setup() {
  loraSerial.begin(57600);
  debugSerial.begin(57600);

  // Wait a maximum of 10s for Serial Monitor
  //while (!debugSerial && millis() < 10000);

  pinMode(17, OUTPUT);
  digitalWrite(17, LOW);
  delay(1000);
  digitalWrite(17, HIGH);
  delay(500);

  debugSerial.println("-- STATUS");
  ttn.showStatus();

  debugSerial.println("-- JOIN");
  ttn.join(appEui, appKey);
}

void loop() {
  debugSerial.println("-- LOOP");

  // Prepare payload of 1 byte to indicate LED status
  byte payload[1];
  payload[0] = (digitalRead(LED_BUILTIN) == HIGH) ? 1 : 0;

  // Send it off
  ttn.sendBytes(payload, sizeof(payload));

  delay(10000);
}

This hangs at the .join() stage, locking up the serial monitor:
-- STATUS
EUI: 0004A30B001C4D8F
Battery: 3263
AppEui: 70B3D57EF0001BEF
DevEui: 0004A30B001C4393
Data Rate: 5
RX Delay 1: 1000
RX Delay 2: 2000
Total Airtime: 0.00 s
-- JOIN

Thanks @Oliverr, @Nicolasdejean and @johanstokking will follow up with you.

@Oliverr do you mean that with the sketch you posted last, you do not get lock ups, but when using the library, you do?

Correct, no issues with join and data is sent and is accessible in production (without the library).

Seems like we do some weird things in readLine().
It's hard to debug it remotely because I don't have your hardware setup here. Can you add some debugPrintLn() in the join() and provision() in TheThingsNetwork.cpp so we can at least see where the lock up starts?

@Oliverr OK I can confirm that we're screwing up with pointers, see #180, and it's typically device dependent how problems show.

@johanstokking thanks for picking that up. Let me know if you need anything confirming


Guidance for process.env

Hi
I created a React Word AddIn and want to use something like process.env.ENVIRONMENT. Can you please provide some guidance on how to determine if the code is running locally or in production?
Thank you!
Pascal

When the local dev server is run ("npm run dev-server" invokes "webpack --mode development"), process.env.NODE_ENV will be set to "development".  Otherwise, the value will be "production".
Webpack does this automatically. More info is available here:
https://webpack.js.org/guides/production/#specify-the-mode


[FE] Fix layout responsiveness + logo size on mobile

The whole page layout should be centered, and the margin on the right should be removed. Additionally, the size of the logo should be set proportionally.
This is currently happening on lower (mobile) resolutions, but It would be great if other resolutions were checked as well.

@stoimenov95 can you please elaborate?
Is this regarding the new design?

@edichoska Will provide more info, I should've kept it in the Backlog...

This is connected to the #221


Make thread! into a function and rename it named

This turns the thread! macro into a function so that the line! and column! macro will work correctly inside of it. Also renames thread to named.
Merging this will mean updating all our other crates.

This change is

r? @ustulation
(maidsafe_highfive has picked a reviewer for you, use r? to override)

Review status: 0 of 1 files reviewed at latest revision, 1 unresolved discussion.

src/thread.rs, line 91 [r2] (raw file):

{
    let thread_name: String = thread_name.into();
    let t = std::thread::Builder::new().name(thread_name)

call it joiner or jh or something. Single alphabet might be too much reduction in length ?

Comments from Reviewable

I  propose that the named function returns RaiiThreadJoiner instead of JoinHandle. To allow spawning detached threads too, I propose augmenting RaiiThreadJoiner with a release method which consumes self and returns the JoinHandle. That way, the more common case (scoped threads) would be more convenient to use while making the less common case (detached threads) still possible.

Yes the release/detach would be useful. Then we can have it return RaiiThreadJoiner by default.

Reviewed 7 of 7 files at r4.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Add LinearMatrix.from_mapping, and replace BladeMap with it

For the example application in spacetime algebra, bm(x) is at least 10x faster.
In theory we could now also write split without using bm at all:
split = LinearMatrix.from_mapping([
    # even subalgebra of D
    (D.scalar, P.scalar),
    (d01, p1),
    (d02, p2),
    (d03, p3),
    (d12, p12),
    (d23, p23),
    (d13, p13),
    (d0123, p123),

    # split(odd) = split(odd * d0)
    (d0, P.scalar),
    (d1, -p1),
    (d2, -p2),
    (d3, -p3),
    (d012, p12),
    (d013, p13),
    (d023, p23),
    (d123, -p123),
])

but I don't have a good enough understanding of what split.adjoint(p1) should be to feel comfortable doing this.

so, pedagogically i dont think it adds anything to STA. however, i think its good because it teachs the transformation tools  at the same time, and these are more generally useful

i like this change.


Preserving gpg-agent between user and sudo invocations

Issue description
If you use programs.gnupg.agent.enable = true; in your configuration.nix, this enables a supervised gpg-agent that is run within systemd. However when using gpg under sudoor sudo -E, the gpg-agent managed by systemd is ignored, and instead new gpg-agents are used. I want to be able to share the same gpg-agent whether running commands under sudo or without sudo.
Steps to reproduce
The programs.gnupg.agent.enable = true; runs a systemd managed gpg-agent.
systemctl --user status gpg-agent

This will mean that the gpg-agent launched will put socket files in the /run/user/UID/gnupg directories. See this by doing:
> gpgconf --list-dirs
sysconfdir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/etc/gnupg
bindir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/bin
libexecdir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/libexec
libdir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/lib/gnupg
datadir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/share/gnupg
localedir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/share/locale
socketdir:/run/user/1000/gnupg
dirmngr-socket:/run/user/1000/gnupg/S.dirmngr
agent-ssh-socket:/run/user/1000/gnupg/S.gpg-agent.ssh
agent-extra-socket:/run/user/1000/gnupg/S.gpg-agent.extra
agent-browser-socket:/run/user/1000/gnupg/S.gpg-agent.browser
agent-socket:/run/user/1000/gnupg/S.gpg-agent
homedir:/home/cmcdragonkai/.gnupg

This is good. However now try this:
> sudo -E gpgconf --list-dirs
sysconfdir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/etc/gnupg
bindir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/bin
libexecdir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/libexec
libdir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/lib/gnupg
datadir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/share/gnupg
localedir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/share/locale
socketdir:/home/cmcdragonkai/.gnupg
dirmngr-socket:/home/cmcdragonkai/.gnupg/S.dirmngr
agent-ssh-socket:/home/cmcdragonkai/.gnupg/S.gpg-agent.ssh
agent-extra-socket:/home/cmcdragonkai/.gnupg/S.gpg-agent.extra
agent-browser-socket:/home/cmcdragonkai/.gnupg/S.gpg-agent.browser
agent-socket:/home/cmcdragonkai/.gnupg/S.gpg-agent
homedir:/home/cmcdragonkai/.gnupg

Or
> sudo gpgconf --list-dirs
sysconfdir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/etc/gnupg
bindir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/bin
libexecdir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/libexec
libdir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/lib/gnupg
datadir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/share/gnupg
localedir:/nix/store/rk6df3iamxmiywq9rlqy72fhvwqhk1qk-gnupg-2.2.11/share/locale
socketdir:/root/.gnupg
dirmngr-socket:/root/.gnupg/S.dirmngr
agent-ssh-socket:/root/.gnupg/S.gpg-agent.ssh
agent-extra-socket:/root/.gnupg/S.gpg-agent.extra
agent-browser-socket:/root/.gnupg/S.gpg-agent.browser
agent-socket:/root/.gnupg/S.gpg-agent
homedir:/root/.gnupg

The problem is that when running a command with sudo, we should try to reuse the same gpg-agent, since we are just elevating our permissions to do something sensitive, we may need to use our gpg keys that exist in our user profile.
I'm not sure, if this can be fixed by inheriting some sort of environment variable that makes gpg look at the same spot as when the user profile is using it.
Furthermore, this also relates to a pinentry problem as well. As the pinentry program only works if the tty is owned by the same user. And the Arch docs say that you need to chown the tty while in sudo mode and then chown back once you exit. I'm not sure how this is meant to be fixed.
Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.
 - system: `"x86_64-linux"`
 - host os: `Linux 4.17.19, Matrix Central, noversion`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.1.3`
 - channels(root): `""`
 - nixpkgs: `/etc/nixos/nixpkgs`

Related issues:

https://github.com/NixOS/nixpkgs/issues/29331
https://github.com/NixOS/nixpkgs/issues/35464

Also another thing to mention is that running: sudo -i or sudo -s will automatically start a gpg-agent for root. So as soon as you sudo you'll get a root gpg-agent and a user-local gpg-agent. It is ok for each user to have its own gpg-agent, and this is expected.
However this gpg-agent is not managed by systemd, instead it's a normal gpg-agent that runs sockets at /root/.gnupg. I'm wondering if programs.gnupg.agent.enable = true; is meant to start gnupg managed by systemd for users, why is this not being done for the root user as well. Therefore there would be a /run/users/0/gnupg directory.
I think the ideal behaviour would be:

sudo -i uses /run/users/0/gnupg - managed by systemd user services (not sure if this feasible as root user is special)
sudo -s uses /run/users/0/gnupg - managed by systemd user services (not sure if this feasible as root user is special)
sudo -E should use /run/users/UID/gnupg where UID is the user that launched sudo

The tty ownership problem and pinentry is another problem.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/i3-and-gnome-keyring/5719/4

still important to me

Also linked to https://github.com/NixOS/nixpkgs/issues/106563

Also linked to https://github.com/NixOS/nixpkgs/issues/106563

still relevant

It looks like gpg will only look for its sockets in /run/user/UID where UID is the real UID it's running as, and fall back to the home dir (~/.gnupg by default). Hence gpg running as root won't find /run/user/0/gnupg/S.gpg-agent and start its own agent. I don't think this behaviour has anything to do with NixOS; might be worth opening a bug upstream.


phpunit db connection refuse with git repo

Laravel Version: 5.7.25
PHP Version: 7.2
Database Driver & Version: MySql 8.0.13

Description:
I'm having a strage behaviour with an application I'm working on.. I can run cli commands like php artisan migrate:fresh and the database populates well,
but if I run vendor/bin/phpunit I get pdoexception connection refused
i'm on an aws vpc connecting to the database in a private layer
laracasts forum topic
are there any known issue about phpunit env variables?
Steps To Reproduce:
you can try fork my project at https://github.com/Kaleskop/kaleskop.git but there's ffmpeg dependencies to setup

Hi there,
Welcome to Laravel and we are glad to have you as part of the community.
Unfortunately this GitHub area is not a support area for general application issues. This is only for issues/bugs with the framework code itself.
I will be closing your ticket here. Instead please try asking your question on one of the many great community support areas that will likely give you a better answer more quickly:

Laravel Slack (https://larachat.co/)
Laravel.io Forum (https://laravel.io/forum)
Laracasts Forum (https://laracasts.com/discuss)
StackOverflow (http://stackoverflow.com/questions/tagged/laravel)

If you feel I've closed this issue in error, please provide more information about how this is a framework issue, and I'll reopen the ticket.
Thanks in advance.


vite] http proxy error at /api/sentiment/pcrAnalyzer/index:

Hi
Below error is shown when VITE server started. Can you pls let me know how to fix the proxy eror.
VITE v3.2.7  ready in 390 ms
➜  Local:   http://localhost:80/
➜  Network: http://<IP_ADDRESS>:80/
1:05:54 PM [vite] http proxy error at /api/sentiment/pcrAnalyzer/index:
Error: connect ECONNREFUSED <IP_ADDRESS>:5000
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)
1:05:54 PM [vite] http proxy error at /api/valuation/index:
Error: connect ECONNREFUSED <IP_ADDRESS>:5000
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)
1:06:45 PM [vite] http proxy error at /api/tickers:
Error: connect ECONNREFUSED <IP_ADDRESS>:5000
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)
1:06:47 PM [vite] http proxy error at /api/sentiment/pcrAnalyzer/index:
Error: connect ECONNREFUSED <IP_ADDRESS>:5000
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)
1:06:47 PM [vite] http proxy error at /api/valuation/index:
Error: connect ECONNREFUSED <IP_ADDRESS>:5000
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)
1:08:37 PM [vite] http proxy error at /api/sentiment/pcrAnalyzer/index:
Error: connect ECONNREFUSED <IP_ADDRESS>:5000
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)
1:08:37 PM [vite] http proxy error at /api/valuation/index:
Error: connect ECONNREFUSED <IP_ADDRESS>:5000
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)

Hi @ramjak2,
This repository is no longer being maintained due to absence of any active maintainers/contributors. There may be a huge disconnect between the actual frontend(Vue on docker branch) and backend causing this failure. I am unable to do it myself due to my commitments towards work place and new ongoing open source project - https://github.com/devfinwiz/Fin-Maestro-Kin.
Alternative for you:

Switch to master branch.
Try using https://github.com/devfinwiz/Fin-Maestro-Web/blob/master/CommonFEGradio/driver.py. This is an alternate frontend to execute some key modules of the project.
Make sure to have all the dependencies resolved in your environment.

The new open source project mentioned above will ensure creation of an independent API that will function 24/7 with ease of quick deployment and documentation. It will comprise of existing Fin-Maestro-Web modules and many new ones ensuring availability of processed financial data to extract useful insights.


writeTextToCanvas treats "-" hyphen/minus, or "_" underscore, characters as space in some cases.

writeTextToCanvas doesn't show anything for only hyphens or underscores, and also cuts off sometimes, but that seems to be another issue.
(Running Cesium JS in Electron, there's no cutoff, but all hyphen or underscore text still does not render.)
Text with mixed hyphens and underscores renders only hyphens.
Checking the return value, it seems canvas height is set to 0, when the string contains only hyphens or only underscores.
An HTML canvas works as a workaround.
Sandcastle example:
https://sandcastle.cesium.com/#c=vZVRa9swEMe/yuGXOmDJabvBaN1sLHsc7GFhT4Yg2+dETNYF6ezMG/3uk2NStq5rUkh6tsF30v+O31mSO+Wg07hFB3dgcQtz9Lpt5LddLM6jcufPybLSFl0eTW5zm9tRI9GyZo1eqqqKf+UWYEM+RMje7DPNlePwpuy1rB01n3DlEH08TWA6SQZFoY0pSLnqBnYZANIUFmvtwa9p6xMoWobgsdNNgxWQNT0MqYDXCAZrfj/KdKNW+FB36zTjAn/wgubKdsoHGPi/MW2EeGY8gCdjGV8qE8pcDd59iN2friNiKqfBrg81piL0YIl3HYKSnMOSTS+P7YMQFyLYwLRj+4sreQRWkvUMGNbHCRHfnh0RlsulgPG6eM2v9+7caIFL7J8DYKfDunwZlWJQxrwAKdjrsVydFUaI/eZ6dsmdlOjNIaJwl+Ecpbo+muMjMYdTdogeD1ObfkExTm6jJMo89wZnoxDgg2425BhaZ2IpU8ZmY1TASou2/I4sS++HZMPULP1TmlW6A13dPfE3gtIo78NI3RrzVf/EPJplaZj/j9SQqrRdfenQGdUP09aXs89jUEqZpcF9WslEplDuUebf
Browser:
Vivaldi 5.3.2679.70 (Stable channel) (64-bit)
Operating System:
Windows 10 Pro 21H2 64-bit

Thanks for the report @maxizrinUX. I can't seem to reproduce this on Chrome or Firefox. We do use some standard web APIs to implement writeTextToCanvas. Any chance this an underlying bug or difference of implementation in Vivaldi?

Everything renders correctly in the Sandcastle?
The same issues persist for Vivaldi Android, that's 3 platforms now.
Screenshot attached.
Ignoring the text being cut off, that seems to be another issue.
There are 2 lines not rendering, one of all underscores, and another all hyphens, and lines with a mix of both don't render the underscores.
There's also a potentially undesired behavior, where the text is only cropped from the left for some reason.
Since this method is using an HTML canvas, and that works properly when manually created, I can only assume something is wrong with the method.

When trying out the given sandcastle (in a version with red backgrounds, for debugging purposes), this is the result for me (on Chrome):

The missing underscores and the cut-off text are... well, the same thing. It's cutting off a bit from the bottom. When there only was an underscore, nothing is left there...
Changing the call to measureText at https://github.com/CesiumGS/cesium/blob/f1ec7782846e59c9cd5ce5683b1783a3bc561a20/Source/Core/writeTextToCanvas.js#L170 like this
  //const dimensions = measureText(context2D, text, font, stroke, fill);
  const metrics = context2D.measureText(text);
  const dimensions = {
    width: -metrics.actualBoundingBoxLeft + metrics.actualBoundingBoxRight,
    height: metrics.actualBoundingBoxDescent + metrics.actualBoundingBoxAscent,
    ascent: metrics.actualBoundingBoxAscent,
    descent: metrics.actualBoundingBoxDescent,
    minx: metrics.actualBoundingBoxLeft,
  };

results in the following:

That looks about right.
I don't know what measureText is doing or what it is supposed to do, but it's obviously not doing the right thing. One could just go with removing that function, but there might be caveats to that: There is a line
  // Set canvas.dimensions to be accessed in LabelCollection
  canvas.dimensions = dimensions;

which might mean that these 'wrong' (?) dimensions are used somewhere else, and in the worst case, the 'wrong' results might already be anticipated there (so fixing this, pragmatically, could lead to problems elsewhere)

For context, looks like the function was rewritten in https://github.com/CesiumGS/cesium/pull/9765.
(While it was "inspired by" the original third party implementation, it is not a direct in-lining. Though I would think we should have measureText mentioned in LICENCE.md by that logic.)
@maxizrinUX Would you be able to test before that PR and see if you're getting the same artifacts?

Would you be able to test before that PR and see if you're getting the same artifacts?

I won't have the time in the foreseeable future.
We have deadlines approaching, so I made a workaround method, and forged on.
Sorry.

The state at https://github.com/CesiumGS/cesium/tree/22f7db308755cceaaddf33ea660d3b722baeb0ad (shortly before the linked PR was merged) creates this:

It also omits the leading spaces in the first line, but the underscores are still there.
The state at https://github.com/CesiumGS/cesium/tree/5b777deb3dfa7411732ab55332e59edfc611485f (directly after merging the PR) creates the first image that I posted in my previous comment.

It seems that this function needs requirements clarification.  Is it truly useful to clamp the canvas to the drawn text, which is effectively causing leading spaces to be ignored?  Why isn't clamping occurring on the right side of text?  What is the implementor supposed to do with the string parameter "baseline" (bottom of what)?  Should this even be public or should it be made private?

The function will require some work, indeed. And as they say: "Pull requests are welcome". But displaying text is tremendously difficult.
(If somebody doesn't believe that: ꧁ خمن أي لغة هذه. ꧂ - and nowadays, some people even consider emojis as 'text' 😱 )
Some short notes:

Is it truly useful to clamp the canvas to the drawn text, which is effectively causing leading spaces to be ignored?

Clamping the canvas to the text does make sense and is useful. Otherwise, the question is: How large should the canvas be? (With the obvious answer: Well, as large as the drawn text...). The fact that the leading spaces are removed is (on a low technical level) unrelated to that, which is part of the answer to the next question:

Why isn't clamping occurring on the right side of text?

The wrong clamping appears to be the result of some attempts to compute the proper canvas size with the special measureText function. And apparently, this one has a few bugs: It properly computes the "right" end of the canvas, but does not properly compute the "left" side of the canvas.  (And... also not the "bottom" of the canvas, FWIW...)

What is the implementor supposed to do with the string parameter "baseline" (bottom of what)?

This is just the textBaseline property for the canvas. If somebody doesn't know what to do with it, one should leave it as its default value. (But admittedly: I could imagine that using something else than the default value could cause glitches - text rendering is difficult...)

Should this even be public or should it be made private?

It is public and will remain public. Not only for backward compatibility, but also because it is a useful function - or even necessary in order to easily create billboards with text.

However, the image in https://github.com/CesiumGS/cesium/pull/9765 showed some compatibility matrix where actualBoundingBoxAscend and actualBoundingBoxDescent had been marked as 'experimental', and not being supported by some browsers.
The latest version of that matrix is captured here (because it may change any minute, apparently):

These properties - and more specifically, all properties that I used for the workaround in a previous comment - are no longer experimental, and supported by all browsers. So it might be possible to get rid of that custom measureText implementation.

@javagl thanks for the info.  I should have been more specific as I was predominantly looking at measureText() rather than writeTextToCanvas().  Since I started looking at this last week I saw the actual... properties and was wondering what problem measureText() was trying to solve that built-in function wasn't providing.

OK, that clarifies ist. But measureText already is private (insofar that it is only a local helper function). What it does, exactly, is ... indeed obscure. Checking pixels to determine the bounding box looks dangerous, and I'd have to look more closely at the code (and maybe dump out the generated image as a PNG file to inspect it) to see what is going on there. But maybe it can just be removed and replaced with the built-in measureText function.


USB and Kernel 3.18-rc7-bone1

Are there any known issues with USB on 3.18-rc7-bone1?. I have tried both DMA and PIO mode without luck, as well as compiling MUSB/Gadget together as modules and directly into the kernel.
Here's the error I get on booting / through dmesg:
[    8.548618] random: nonblocking pool is initialized
[   10.576671] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
[   10.624483] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
[   10.634807] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
[   10.638015] musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
[   10.638062] platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
[   10.681790] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
[   10.700147] musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
[   10.717126] platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
[   10.735553] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
[   10.752677] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral

And I can't list USB devices:
root@arm:~# lsusb
unable to initialize libusb: -99

Here's my kernel config:
http://pastebin.com/Hi7U2xSD

Well, you have phy disabled:
# CONFIG_AM335X_PHY_USB is not set

That is extremely embarrassing. Thank you.


Inconsistent masses

Hello,
While processing the chemical_data.tsv file in the flat file dump (ftp://ftp.ebi.ac.uk/pub/databases/chebi/Flat_file_tab_delimited/chemical_data.tsv, downloaded 2019-10-10), I've noticed several compounds with multiple inconsistent values for the mass attribute. In most of these cases, the values are close, and the discrepancy seems to result from one of the values having been computed with more digits of precision than the other (example: CHEBI:16808). However, there are a few cases which differ more significantly:

CHEBI:55429 has MASS values 213.212 and 243.28000.
CHEBI:61753 has MASS values 1510.558 and 1525.59000.
CHEBI:35681 has MASS values 30.02600 and 58.07910.

In each of these cases, the value of the MONOISOTOPIC MASS attribute is consistent with the smaller of the MASS values.

Thanks for letting us know about these 3 ChEBI entries. These have now been corrected.


Feat: Support accessibilityLabel for Switch components

Description
This is a feature request. <Switch /> components do not support the accessibilityLabel prop.
Motivation: I am using the Appium testing framework as it is the preferred framework for integrating with BrowserStack. Appium highly recommends using accessibilityLabel to identify components, allowing developers to fallback on XPath as a last resort.
React Native version:
I am currently using<EMAIL_ADDRESS>but looking at the online docs for <Switch /> I see that the prop is still not supported in latest (0.63).
System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Memory: 125.42 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.14.1 - ~/.nvm/versions/node/v12.14.1/bin/node
    Yarn: 1.22.4 - ~/.nvm/versions/node/v12.14.1/bin/yarn
    npm: 6.13.4 - ~/.nvm/versions/node/v12.14.1/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.10.0 - /Users/kjohnson/.rbenv/shims/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.0, DriverKit 19.0, macOS 10.15, tvOS 14.0, watchOS 7.0
    Android SDK: Not Found
  IDEs:
    Android Studio: 3.2 AI-181.55<IP_ADDRESS>56338
    Xcode: 12.0.1/12A7300 - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.2 - /usr/bin/javac
    Python: 2.7.17 - /usr/local/bin/python
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.11.0 => 16.11.0
    react-native: 0.62.1 => 0.62.1
  npmGlobalPackages:
    *react-native*: Not Found

Steps To Reproduce

Render <Switch accessibilityLabel="test" />
<android.widget.Switch> has no content-desc property. This property should have the same value as the accessibilityLabel prop.

Expected Results
When viewed in Appium or another app view source explorer, the <android.widget.Switch> node in the rendered tree will have a content-desc="test" (see the ViewGroup for reference). The correct corresponding property will be set on iOS.
Snack, code example, screenshot, or link to a repository:
import React from 'react';
import { Switch, View } from 'react-native';

function App() {
  return <View><Switch accessibilityLabel="test" /></View>
}

This issue will most likely be resolved by #30944 as part of the Improved React Native Accessibility Project

Closing this then and tracking in #30944


SkinnedMesh gltf character distorted mesh

trying to get a gltf avatar model with this greate THREE.IK
the bones looks like correct for me only the mesh is bind wrong
THREE.IK master and aframe 0.9 with THREE 101
https://efficient-tote.glitch.me/

@arpu thanks for reporting! Possibly related to #9 and handling the correct orientations of the bones -- do you know what software generated this model, or it's expected joint orientation?

i have created this model with mixamo and blender like described in this blog post
https://www.donmccurdy.com/2017/11/06/creating-animated-gltf-characters-with-mixamo-and-blender/

ok i have done some more testing with new blender 2.80 beta ( importing the fbx from mixamo and export it with gltf exporter) result looks similar
https://truthful-web.glitch.m

on the fbx importing i use this fbx settings like described in the blog post
https://www.donmccurdy.com/assets/images/2017/11/manual_orientation.png
https://www.donmccurdy.com/assets/images/2017/11/bone_orientation.png

THREE.IK expects +Z to be facing the children joint; this is a potential solution to not requiring a specific orientation of skeleton, as all tools handle it differently

i have to less knowledge on this, for what is the best solution for this

@arpu @jsantell
After doing the axis conversion to +Z Forward on your mesh, the bind matrices are fixed :)
https://dashing-floor.glitch.me/
There is now a utility in the AxisUtils.js file called setZForward. Using this function on the root bone will reset the bone quaternions / positions to follow a +Z Forward coordinate system.
This is the code I added to your project. I had to rebind two meshes because both of them are using the same skeleton.
setZForward(rootBone);
rigMesh.bind(rigMesh.skeleton)
rigMesh2.bind(rigMesh2.skeleton)

@sneha-belkhale  this is awesome! thank you so much!
would  be cool if you want to join my little discord server,  for my freetime side project
https://discord.gg/cNfG834

Thanks to @sneha-belkhale, I think with https://github.com/jsantell/THREE.IK/pull/9, this should be solved, how does it look @arpu?

yeahh this works now fine


Upgrade Rails to 5.2 or 6.0 and Ruby to 2.7.0-preview1

Upgrade Rails to 5.2 or 6.0 and Ruby to 2.7.0-preview1
Problem
Using old versions of Ruby-on-Rails and Ruby.
Goal
To upgrade the repo to latest Rails and Ruby versions.
Steps to solve the problem

Upgrade Ruby from 2.6.3 to 2.7.0-preview.
Upgrade Rails to 6.0.0.rc1 (or at least 5.2).
Fix all lose functionality with help.

Status

Copied repo to separate repo.
Made upgrades.
Fixed regressions (loss test spec) maybe.

TODOs

Document loss of one test spec in this issue or separate issue.
Ask for review help with loss test spec.
Merged above upgrades into Railsgoat's master branch.

Help

Any help or comment to this issues are welcome.

This is the one test spec that stopped working after upgrading:
https://github.com/OWASP/railsgoat/blob/master/spec/vulnerabilities/sql_injection_spec.rb
and the line that I needed to change was:
find(:xpath, "//input[@id='user_id']", visible: false).set "8' OR admin='t') --"

Found this background material for Rails 5.2 SQL Injection Protection:

https://blog.bigbinary.com/2018/10/16/rails-5-2-disallows-raw-sql-in-active-record.html
https://github.com/rails/rails/pull/27947

So I change the *find line to this (@cktricky Right?):
find(:xpath, "//input[@id='user_id']", visible: false).set "8' OR 1 == 1) --"
```

Hey @jasnow, that should work!

Thanks


Don't generate plugin registry in ResidentWebRunner

generateDartPluginRegistry was being set to true unconditionally in
ResidentRunner, bypassing the primary check in
DartPluginRegistrantTarget, and the targetPlatform was not set in that
codepath, bypassing the second after the changes in
https://github.com/flutter/flutter/pull/87991. This caused web hot
restarts to be slower due to doing unnecessary work.
This ensures that generateDartPluginRegistry is false in the
ResidentWebRunner to skip that unnecessary step.
Fixes https://github.com/flutter/flutter/issues/91262
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

/cc @zanderso @christopherfujino FYI. I'm not sure how to run the perf test myself, but I verified locally that the undesired codepath was being run for web hot restart without this change, as is not with this change.

/cc @zanderso @christopherfujino FYI. I'm not sure how to run the perf test myself, but I verified locally that the undesired codepath was being run for web hot restart without this change, as is not with this change.

I don't know of an easier way of seeing how to run the benchmarks than looking at how the bots run them. In this case you can search on the dashboard for "chrome_dev_mode", which leads you to and example run:
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac_ios macos_chrome_dev_mode/2408/overview
From there, you probably just need to look at step 17 "run macos_chrome_dev_mode".

@godofredoc the ci.yaml validation looks like it is taking too long to queue on this PR.

@godofredoc the ci.yaml validation looks like it is taking too long to queue on this PR.
This is a problem with the request to trigger the builds timing out. Retried all builds.

Gold has detected about 1 new digest(s) on patchset 2.
View them at https://flutter-gold.skia.org/cl/github/91281

Any idea why this change affects goldens?

That is weird. maybe a rebase fixes it?

That is weird. maybe a rebase fixes it?

Yep! No idea what happened there; infra issue maybe?

I think Skia Gold's state is not a function of the files in your local copy. It's a function of whomever approved the last gold files?


Explore whether to use syn-md

syn-mid seems like an interesting library that provides constructs such as “functions whose bodies aren't parsed” and “blocks whose bodies aren't parsed”. This might help with some of the attribute macros.

I'm interested in taking a look at this.

@yaahallo That'd be great! I also tried out Darling in another library which treats procedural macros like Serde attributes—it might be a worthwhile thing to consider. The best examples I've seen for Darling were in their integration tests folder.

I'm unsure if this is still relevant, since in order to support async functions, I think we do need to actually interact with function bodies?

I say CLOSE IT


i18n Configuration Breaks /docs Route After CLI Integration

To Reproduce
1.	Install fuma using the official setup instructions. (pnpm create fumadocs-app)
2.  Install CLI (pnpm add @fumadocs/cli --save-dev)
3. Init i18n (pnpm fumadocs init i18n)
4. change lib/i18n cn to tr
5. go to http://localhost:3000/tr/docs or http://localhost:3000/en/docs or http://localhost:3000/docs
6.

Current vs. Expected behavior
I am expecting entering docs subfolder with example md files. after that I will create nwe ones with .tr.mdx lang extension
Provide environment information
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:02:45 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T8112
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 22.12.0
  npm: 10.9.0
  Yarn: N/A
  pnpm: 9.15.0
Relevant Packages:
  next: 15.1.2 // Latest available version is detected (15.1.2).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: N/A
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)
Core
Additional context
No response

Hmm Next.js 15 made it async, will update it later

is there any quick fix? @fuma-nama

still same after the cli changes:

Make sure to update to the latest CLI version

Still getting error after new clean setup.

Hmm maybe you can follow the manual setup guide, it should works

This part is not clear on the documentation:

Update the usages to your source to include a locale code:
import { source } from '@/lib/source';
// get page tree
source.pageTree[params.lang];
// get page
source.getPage(params.slug, params.lang);
// get pages
source.getPages(params.lang);
Note that without providing a locale code, it uses your default locale instead. You can see Source API for other usages.

Hmm which part, your can update your usage of source by following the guide

I couldn’t quite understand where exactly I should add the provided code snippet in the documentation.

You can click on the source variable in source.ts and find its references, and update the references according to the guide

It is really hard to follow manual setup, you cannot understand what is special files mean or find RootLayout I think it is outdated.

Root layout is very clear, it is required for every Next.js app
Next docs also mentioned special files "Finally, ensure all special files inside app/ are nested under app/[lang]", it is a conventional word


Vulnerability roundup 79: git-2.23.1: 3 advisories

search, files

[ ] CVE-2018-1000182 CVSSv3=6.4 (nixos-19.09)
[ ] CVE-2018-1000110 CVSSv3=5.3 (nixos-19.09)
[ ] CVE-2019-1003010 CVSSv3=4.3 (nixos-19.09)

Scanned versions: nixos-19.09: d85e435b7bd. May contain false positives.

These CVEs seem to only affect Jenkins Git Plugin.
But here is a real git vulnerability found in that version: CVE-2020-5260
https://github.com/git/git/security/advisories/GHSA-qm7j-c969-7j4q
Related PRs:

https://github.com/NixOS/nixpkgs/pull/85263
https://github.com/NixOS/nixpkgs/pull/85277

CVE-2020-5260 is fixed on 19.09, 20.03 and staging-next (soonish to master, #85263)


clang can not find source file in compilation database

Hello !
My work project has about 13000 source files in C (without the headers), and I generated a compilation database for them. I tried with absolute and relative paths, and also both formats in the compilation database (string vs array for the command line)
I built clink with latest clang 18 in openSUSE Tumbleweed.
When running clink with --parse-C=clang, , it says clang can not find the source files in the compilation database. But when I copy and search the source file name, it is right there in the .json file.
Is there a way to fix this, or is the issue directly from clang ?
Can clink also use (and document) the simpler alternative file compile_flags.txt, that can be used by clang instead of compile_commands.json ?

I have attached my compile database here: compile_commands.json.tar.gz and the namefile list here if it helps: namefile.files.tar.gz
You can look for the "arguments" field in the file format specification from clang  (https://clang.llvm.org/docs/JSONCompilationDatabase.html), where I see it is a json array.
Here is the output from  clink --debug --jobs 1  --parse-c=clang -i namefile.files >clink_outout.log 2>&1 , up until the first errors reported: clink_outout.log.tar.gz
If I can not use compile_commands.json (lets say because it is too large), maybe some alternatives can work:

the compile_flags.txt is a limited alternative, but it works for my real project (like I said, with 13000 source files), and is oficially supported and documented by clang (https://clang.llvm.org/docs/JSONCompilationDatabase.html)
also another option is to do what ycm-core plugin (for Vim) does: use a script file, with a method that is invoked for each source file, and the method returns compiler flags for building that source (see .ycm_extra_conf.py

Thank you for the support and hopefully this can be fixed or worked-around.
This is such a great tool by the way ! Just amazing ... !

Interesting. Clink claims it can’t find some of these files in the compile_commands.json database, even though they’re clearly there. It’s been a while since I looked at this part of the code base, but I thought it was just interacting with the libclang API, which means libclang can’t find these entries for some reason. I’ll have to debug this a bit further locally… Thanks for attaching those files.

This is such a great tool by the way ! Just amazing ... !

Thanks! Glad you like it :)

Is there a way in clang API to check for errors from parsing the compilation database ?

Sorry it took a while to find time to investigate this one. The problem appears to be that the compilation database parsing code was simply too strict in what it would accept. Do you have time to see if the fix I posted in https://github.com/Smattr/clink/pull/248 works for you?

It occurs to me just now that you also have relative -I… paths in your arguments. Not sure if this will cause problems as well, but lets see if this step gets us some progress first.

I’ll merge the PR now and continue to refine that area going forwards. Let me know if there’s further things you need addressing here.


Blacklist field not showing

Describe the bug
When editing the Bugsnag settings in Craft CMS the "Blacklist" field doesn't show

Steps to reproduce

Go to Settings
Click BugSnag
Observe theres no Blacklist field

Craft CMS version
4.4.11
Plugin version
4.0.0
Multi-site?
No
Additional context
No response

Fixed for the next release. To get this early, run composer require verbb/bugsnag:"dev-craft-4 as 4.0.0

Fixed in 4.0.1


CI/CD tests produce deprecation warnings

Description
Running our unit tests on CI/CD produces deprecation warnings
How to reproduce
Run tests on CI/CD and observe the output. You should find something similar to the following:
  /opt/hostedtoolcache/Python/3.7.17/x64/lib/python3.7/site-packages/pytest_cov/plugin.py:233: PytestDeprecationWarning: The hookimpl CovPlugin.pytest_configure_node uses old-style configuration options (marks or attributes).
  Please use the pytest.hookimpl(optionalhook=True) decorator instead
   to configure the hooks.
   See https://docs.pytest.org/en/latest/deprecations.html#configuring-hook-specs-impls-using-markers
    def pytest_configure_node(self, node):

../../../../../opt/hostedtoolcache/Python/3.7.17/x64/lib/python3.7/site-packages/pytest_cov/plugin.py:242
  /opt/hostedtoolcache/Python/3.7.17/x64/lib/python3.7/site-packages/pytest_cov/plugin.py:242: PytestDeprecationWarning: The hookimpl CovPlugin.pytest_testnodedown uses old-style configuration options (marks or attributes).
  Please use the pytest.hookimpl(optionalhook=True) decorator instead
   to configure the hooks.
   See https://docs.pytest.org/en/latest/deprecations.html#configuring-hook-specs-impls-using-markers
    def pytest_testnodedown(self, node, error):

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html

Expected behavior
Running tests shouldn't produce deprecation warnings. Test code should be tweaked to not generate these warnings

This appears to be specific to the code coverage package we're using and not part of the SmartRedis code itself

@billschereriii Let's update / change this to do an investigation of dependency update.

The warning is coming when you run Python tests, but is generated against ../../../../../opt/hostedtoolcache/Python/3.7.17/x64/lib/python3.7/site-packages/pytest_cov/plugin.py which is not source code that is under our control.


Fix code scanning alert no. 27: Uncontrolled data used in path expression

Fixes https://github.com/tamacat-cloud/tamacat2/security/code-scanning/27
To fix the problem, we need to ensure that the path provided by the user does not lead to directory traversal or access to unauthorized files. This can be achieved by normalizing the path and ensuring it remains within the intended directory.

Normalize the path to remove any redundant elements like ".." or ".".
Ensure that the resulting path is still within the docsRoot directory.
Reject any paths that do not meet these criteria.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

merge


@Font-Face

I found when scoper prefixed #scoper-id to @font-face it would break the custom font. I just altered this

if (g1.match(/^\s*(@media|@keyframes|to|from)|@font-face/)) {
return g1 + g2;
}

to include @font-face

Thanks for this. Haven't tested, but it seems we'd want @font-face inside the parens as well:
if (g1.match(/^\s*(@media|@keyframes|to|from|@font-face)/))
Also, there were a few other lines changed in the files. Can you keep the PR to just this one line. I'm also happy to make this fix myself.

Sure make the fix yourself. I'm green to github and not really sure how it works just yet
Happy to help
-Alan

On 27 Mar 2016, at 5:29 AM, Thomas Park<EMAIL_ADDRESS>wrote:
Thanks for this. Haven't tested, but it seems we'd want @font-face inside the parens as well:
if (g1.match(/^\s*(@media|@keyframes|to|from|@font-face)/))
Also, there were a few other lines changed in the files. Can you keep the PR to just this one line. I'm also happy to make this fix myself.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub


wow.js happens on page load and not on scroll

We have deployed a new design to our website . I'm using wow.js, and it works fine, except the animations all happen immediately after the page load, and not when they are scrolled to. I followed the docs, but can't figure it out.
Its working fine in pure html :  http://developer.groupdesign.in/saivision/html_changes/index.html
But when I implemented the same in our Codeigniter based application its stopped working on scroll and work on page load only :   http://taskit.co.za/index.php/
Pls help out

Just don't include the animated class on your wow elements.


bug; karpenter controller policy is missing required instance profile persmissions introduced in karpenter v0.32

Description
Karpenter will auto-generate instance profiles as of version v0.32. The karpenter_controller policy in modules/iam-role-for-service-accounts-eks/policies.tf does not currently include statements for manipulating instance profiles.
Updated karpenter policy can be found in the karpenter repository

[x] ✋ I have searched the open/closed issues and my issue is not listed.

Versions

Module version [Required]: v5.30.1
Terraform version: 1.6.3
Provider version(s): hashicorp/aws 5.25.0

Reproduction Code [Required]
Run the karpenter_controller_irsa_role module under terraform-aws-iam/examples/iam-role-for-service-accounts-eks ;
module "karpenter_controller_irsa_role" {
  source = "../../modules/iam-role-for-service-accounts-eks"

  role_name                          = "karpenter-controller"
  attach_karpenter_controller_policy = true

  karpenter_controller_cluster_name       = module.eks.cluster_name
  karpenter_controller_node_iam_role_arns = [module.eks.eks_managed_node_groups["default"].iam_role_arn]

  oidc_providers = {
    ex = {
      provider_arn               = module.eks.oidc_provider_arn
      namespace_service_accounts = ["karpenter:karpenter"]
    }
  }

  tags = local.tags
}

Steps to reproduce the behavior:

Create a module from iam-role-for-service-accounts-eks  with attach_karpenter_controller_policy = true
Apply changes with terraform
Inspect resulting karpenter IAM policy. The policy is missing required instance profile actions

Expected behavior
Expected a series of instance profile actions to be added to the karpenter role
Actual behavior
Found no instance profile actions associated with the karpenter role/policy
Additional context
Related Karpenter policy for the terraform module can be found here
Related Karpenter v0.32 policy can be found here

This issue has been resolved in version 5.32.0 :tada:


Initial directory in guest machines

Is your feature request related to a problem? Please describe.
I'd like to have the possibility to choose the default directory when I connect to a virtual machine. Currently it opens in the same folder as the host machine.
Describe the solution you'd like
It would be nice to have a possibility to set a per-machine initial directory; if missing/empty, default to current host dir (as it is now)
Describe alternatives you've considered
None
Additional context
None

Added a -w flag to set the working directory on each command invocation. No plans to allow setting a per-machine default.
You can also use ssh orb to default to the Linux home dir.

Released in v1.5.0 Canary 1. To switch to Canary: Settings > Update channel
New feature: Debug Shell provides useful commands & tools, making it easy to debug any container (even if minimal).

Released in stable v1.5.0.

New feature: OrbStack Debug Shell provides useful commands & tools, making it easy to debug any container (even if minimal).
"It's 12 AM and your Docker container isn't working, but debugging it with docker exec is impossible because it has no shell or tools. OrbStack Debug Shell provides a nice zsh setup with auto-complete, editors, common tools, and over 80,000 packages, on top of any container."
Read more: blog post


Fixed typo in RZZGate

Summary
Fixed typo in RZZ Gate documentation. Text contained R ZZ (θ=π)=−Z⊗Z instead of R ZZ (θ=π)=−i Z⊗Z
Fixes #12685
Details and comments

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

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
13 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.01%) to 89.729%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
1
93.64%

crates/qasm2/src/parse.rs
12
95.77%

Totals

Change from base Build<PHONE_NUMBER>:
-0.01%

Covered Lines:
63790

Relevant Lines:
71092

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.006%) to 89.846%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
4
92.62%

Totals

Change from base Build<PHONE_NUMBER>:
0.006%

Covered Lines:
65139

Relevant Lines:
72501

💛  - Coveralls


What is TermUnitEnum? I cannot see no documentation or explanations

Describe the bug
src/Microsoft.Marketplace.SaaS/Generated/Models/TermUnitEnum.cs  is not well described.
Expected behavior
The summary of the enum explains what it is about and how to use it.
Each case has a description

Version 1.2

@scseely

@xperiandri the TermUnit is from the subscription payload which is described here https://learn.microsoft.com/en-us/partner-center/marketplace/partner-center-portal/pc-saas-fulfillment-subscription-api#post-httpsmarketplaceapimicrosoftcomapisaassubscriptionsresolveapi-versionapiversion.
Please let me know if this helps

@xperiandri I hope the above answers your questions. Please feel free to reopen on any follow up questions. Closing this for now.


[Cognitive Services] unify client class names, folder cases.

Additional to https://github.com/Azure/azure-rest-api-specs/pull/3351, rename LUIS Client names.
Change one folder to lowercase......  for consistency and potential cross-platform issues.

PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[ ] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-go


Add option for save data backup during gameplay at regular intervals

https://github.com/sharkusmanch/playnite-ludusavi-restic/issues/9


In mobile browsers, markers disappear

When moving the map from the mobile, the markers disappear to go back only when the drag is released. Why?

Hi @Idas86,
I am so sorry it looks like I totally missed your message... 😖
If you managed to solve this issue, please could you kindly describe the cause and how you fixed it?
Or if it is still not fixed, please could you kindly share a reproduction example?

Closing due to inactivity.


DPL-804: Create barcode formats for RVI non-cherrypicked plates

User story
As an RVI lab technician, I need Sequencescape to accept new barcode formats to support importing plates received from Plymouth and Leamington Spa lighthouse labs which were not pre-cherrypicked.
The plates use a format that the lighthouse labs used themselves before distributing the plates to Sanger.  Exampled of plate barcodes are included in Additional Context.
Who are the primary contacts for this story
ss50 st2 sm49
Who is the nominated tester for UAT
st2
Acceptance criteria
To be considered successful the solution must allow:

[ ] Barcodes for plates received from Plymouth can be created in Sequencescape via Plate Genie's deep-well plate importer.
[ ] Barcodes for plates received from Leamington Spa can be created in Sequencescape via Plate Genie's deep-well plate importer.

Additional context
Plymouth plates have the format BnnnnnnRNAEXT where n represents exactly 1 digit.
Leamington Spa plate have the format ELUTEnnnnnnnn where n represents exactly 1 digit.

I've deployed this to training since UAT is unavailable at the moment due to other testing going on.


Fix match and party data message callbacks

The socket code expected all messages to return a response from the server when in fact match and party data messages are "fire and forget". This change makes sure that match data and party data message complete immediately when the message has been sent. The message callback handling has also been improved and moved from the engine specific code to the generic socket code.
Fixes #77

@britzl it's not just match and party socket messages that are fire and forget. Any public non-connection related socket methods that return a Task without a generic type parameter here are also "fire and forget": https://github.com/heroiclabs/nakama-dotnet/blob/master/Nakama/ISocket.cs#L138


add logo on readme 💅

💅💅💅💅💅

can be viewed here https://github.com/endel/TypeScriptToLua/tree/logo-readme

@Perryvw just fixed! ❤


http_11_proxy: fixing a bug with buggy proxies

By the HTTP/1.1 spec, all headers are supposed to end with CRLF (\r\n)
Turns out the HTTP/1.1 spec also call out some broken legacy servers only return LF (\n")
Removing a performance optimization that was breaking on proxies with this bug.
Risk Level: low
Testing: new unit test
Docs Changes: n/a
Release Notes: not included

cc @Augustyniak

@alyssawilk I have confirmed that this patch makes PAC file to work on my Samsung device - awesome!


[bug] hard reset does not clear nodes.json

Version
Build/Run method

[ ] Docker
[ ] PKG
[x] Manually built (git clone - npm install - npm run build )

Zwave2Mqtt version: master @ 20190805
Openzwave Version: 1.6.848
Describe the bug
An easy one for a change, when triggering a hard reset. The nodes.json file does not get cleared. After adding nodes again they have the same name as the node that was there before.
To Reproduce
Steps to reproduce the behavior:

name the node with id 2 'myoldname', 'myoldroom'
hard reset the controller
include a different node (as this will then become node 2)
name for the node with id 2 is now 'myoldname', 'myoldroon'

After hard resetting all nodes are no longer part of the network and the network ID also changes. So there might be an easy check to see if the controller was hard reset or not.
Expected behavior
Node names  to be forgotten on hard reset
Additional context
Add any other context about the problem here.

Hard reset is an action against the controller, nodes.json are managed by
the application
Il giorno gio 8 ago 2019 alle ore 14:57 Jorge Schrauwen <
<EMAIL_ADDRESS>ha scritto:

Assigned #86 https://github.com/OpenZWave/Zwave2Mqtt/issues/86 to
@robertsLando https://github.com/robertsLando.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/OpenZWave/Zwave2Mqtt/issues/86?email_source=notifications&email_token=ACXYHH743DJYQ7PL3CPEH43QDQJ2FA5CNFSM4IKKCTO2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOS6LOW4I#event-2543250289,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACXYHH4K6FYD5UHBACHSVTLQDQJ2FANCNFSM4IKKCTOQ
.

--
Daniel Lando - Ufficio Tecnico<EMAIL_ADDRESS>*Innovation System S.r.l. *
Via Motton, 83 36061 Bassano del Grappa (VI)
*Sede Operativa *
Via San Giovanni bosco, 2  36022 Cassola (VI)
La presente comunicazione, che potrebbe contenere informazioni riservate
e/o protette da segreto professionale, è indirizzata esclusivamente ai
destinatari della medesima qui indicati. Nel caso in cui abbiate ricevuto
per errore la presente comunicazione, vogliate cortesemente darcene
immediata notizia, rispondendo a questo stesso indirizzo di e-mail/fax, e
poi procedere alla cancellazione di questo messaggio dal Vostro sistema.
Grazie.
This communication, that may contain confidential and/or legally privileged
information, is intended solely for the use of the intended addressees. If
you have received this communication in error, please notify us immediately
by responding to this email /fax and then delete it from your system.
Thanks.  Rispetta l'ambiente: se non ti e' necessario, non stampare questa
mail. - Take care of the environment: do not print this mail if not
strengthly requested.

Correct after hard reset, all associations the controller had are lost.
I'll try go give a better example
network a:
* node 1 - controller (label = controller)
* node 2 - switch (label = lamp)
* node 3 - repeater ( label = )
* node 4 - sensor (label = door )

network b: (new network after reset, label are still read from
nodes.json)
* node 1- controller (label = controller)

If we then include the repeater again:
* node 1 - controller (label = controller)
* node 2 - reapter (label = lamp)

Node 2 now has the label from the network as it was before the hard
reset. This is most cerntainly not what most people woul expect.
I think there are 2 ways to solve this

delete node.json on a hard reset (easy)
include the network id in the filename for the labels so the file is
called nodes_0xXXXXXXXX.json

And the correct nodes.json is loaded depending on the current network.
But the later is more complex and probably not worth it.
On 2019-08-08 15:34, Daniel Lando wrote:

Hard reset is an action against the controller, nodes.json are managed by
the application
Il giorno gio 8 ago 2019 alle ore 14:57 Jorge Schrauwen <
<EMAIL_ADDRESS>ha scritto:

Assigned #86 https://github.com/OpenZWave/Zwave2Mqtt/issues/86 to
@robertsLando https://github.com/robertsLando.
--
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/OpenZWave/Zwave2Mqtt/issues/86?email_source=notifications&email_token=ACXYHH743DJYQ7PL3CPEH43QDQJ2FA5CNFSM4IKKCTO2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOS6LOW4I#event-2543250289,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACXYHH4K6FYD5UHBACHSVTLQDQJ2FANCNFSM4IKKCTOQ
.

--
Daniel Lando - Ufficio Tecnico<EMAIL_ADDRESS>*Innovation System S.r.l. *
Via Motton, 83 36061 Bassano del Grappa (VI)
*Sede Operativa *
Via San Giovanni bosco, 2 36022 Cassola (VI)
La presente comunicazione, che potrebbe contenere informazioni riservate
e/o protette da segreto professionale, è indirizzata esclusivamente ai
destinatari della medesima qui indicati. Nel caso in cui abbiate ricevuto
per errore la presente comunicazione, vogliate cortesemente darcene
immediata notizia, rispondendo a questo stesso indirizzo di e-mail/fax, e
poi procedere alla cancellazione di questo messaggio dal Vostro sistema.
Grazie.
This communication, that may contain confidential and/or legally privileged
information, is intended solely for the use of the intended addressees. If
you have received this communication in error, please notify us immediately
by responding to this email /fax and then delete it from your system.
Thanks. Rispetta l'ambiente: se non ti e' necessario, non stampare questa
mail. - Take care of the environment: do not print this mail if not
strengthly requested.
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub [1], or mute the thread [2].

--
~ sjorge
Links:
[1]
https://github.com/OpenZWave/Zwave2Mqtt/issues/86?email_source=notifications&email_token=AAC4WEI3Y6XODYZ52DIGILDQDQOFNA5CNFSM4IKKCTO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD33T7PI#issuecomment-519520189
[2]
https://github.com/notifications/unsubscribe-auth/AAC4WEKFESQQ5MUYUGUHW6DQDQOFNANCNFSM4IKKCTOQ


menu-title in d-menu cannot be like in v-menu?

so, use "divider" only?
menu-title in d-menu can trigger hover and click event. Should it be like in v-menu?

menu title not present in d-menu

You can use v-menu to create dropdown menu https://codepen.io/olton/pen/mxewyM

thank you. I copied the code, but not worked very well in app-bar-container. So I split one d-menu to mutiple menus -_-
https://github.com/olton/Metro-UI-CSS/issues/1002

I added support v-menu for app-bar in 4.1.1
https://codepen.io/olton/pen/BrpGbj


Event in tf2

bug
unable to import
tensorflow.core.util.event_pb2 import Event
Unresolved reference Event
Desktop :

OS: Windows 10
python version : 3.7
tensorflow version : 2.0
numpy version : 1.17.2

Probably something to do with tf itself.

@aakash94 Yes, tensorboard-aggregator was only tested and implemented for tensorflow 1.x
I currently don't have the time to write an updated version for tensorflow 2.x