Solved several issues discovered by me

Hello there! I've discovered your repo while I'm looking for a powerful template engine for my new PHP MVC Framework. I really appreciate your effort to develop something like this!
During my testing, I've opened 13 issues to fix. As a thanks for you, I decided to say it on my way; I forked it and pushed my fixes and my special touches and ideas, you may review the seven closed issues on your repo to see what I'd done.
At the end, I tried to do my best to solve my all opened issues but I couldn't for now. However, I'll be happy to participate for any new ideas and fixes that you may need in the future.
Thanks for your effort to present this powerful framework.
[PS]: I've linted all files to reduce file sizes for a better stability and light loading.

I've also fixed issue #11 and changed the behavior of parsing attributes: dashed attributes won't be camelCased anymore due to ability to user custom data attributes, also introduced $this->getAttributesParsed() passed through custom component by $attributesParsed.

For the commit id 7f140c8, this following case does not work anymore:
<x-alert :level="$message->type == 'error' ? 'danger' : 'info'">
    {{ $alertMessage }}
</x-alert>

The solution is in the $re regex parser in the code. I hope you help me solving this.

Okay I've solved an issue: passing object or array as attribute parameter value in the custom component.


Disable building uno samples

Disabled building the samples. There might be real problems underlying the fail. This needs to be fixed but we are far away from a release. The version overrides of the samples may need to be changed.


GitHub workflow to automatically build operators

The workflow checks changed files between runs using commit ids (saved in .github/build_operators_commits.txt).
Every changed .py and .ipynb file with a <file>.cfg in the directory operators is processed.
The <file>.cfg can be empty. Alternatively, the following settings can be specified:
gridwrapper=false
cos=false
process=false
repository=false
version=0.1
additional_files=path/to/file1.py path/to/file2.py

If a variable is not present, it is similar to variable=false.
The script executes the C3 compiler based on the settings of each file.

@romeokienzler Does to makes sense to allow changing the repository?
It is probably not working because docker is login to the default repository which is specified in the workflow.

Thanks @blumenstiel

[x] merged


[SMALLFIX] Share threads and use deamon threads for dynamic resource pools

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11524/
Test FAILed.

Merged build finished. Test FAILed.

LGTM

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11525/
Test PASSed.


Lite UI Feature Request

This feature request will be discussed in upcoming #sig-client discussions. It is hereby proposed to provide with a lite UI (lighter / less overwhelming).

Compact - Like calculator or Electrum wallet, so I don't have to fill the entire screen to run it, and I'm not overwhelmed with info I don't need. This may even help alleviate the color problem, as filling an entire screen with that much purple is overwhelming. - Yet the NEM wallet pro managed to use purple well.
Easy access to Send & Receive
Easy access to QR code - maybe even display on main wallet page
Ability to search transactions (EG: to pull all the transaction history from a specific address)
Ability to scroll through transaction history, instead of tabbing
Add something like a 1-click "refresh node", so beginners can just click it, and it auto tries a different node.

Next #sig-client call planned for July 22nd, 2020 - 13:00 GMT+2

I believe, this issue is not relevant anymore. Please feel free to create another one with up to date definition.


Remove inline CSS for flag images

With flagsImagePath commented out and this package's CSS not imported, the following is still added to the markup:
<div class="flag us" style="width: 16px; height: 11px; background-image:url("flags.png");">
This makes retheming the flag icons more difficult, as inline CSS needs !important overrides. Anyone using a custom spritesheet or other non-default solution will need to override these values.
I suggest moving the width and height to .flag inside the react-telephone-input default CSS and only inlining the background-image path if flagsImagePath has been passed in.

Thansk for the suggestions! Have incorporated in v4.5.8


Indexer triggers DB error "FATAL:  sorry, too many clients already" when doing too many sequential queries (no parallel queries)

Summary
Querying accounts with a previous round even sequentially make the DB display the following error:
FATAL:  sorry, too many clients already

and then a long list of
LOG:  unexpected EOF on client connection with an open transaction

The indexer returns the message:
{"message":"Indexer health error: %s"}

(error 500)
and sometimes completely crashes.
To try, run:
for i in $(seq 200)
do
  curl "$AF_IDX_ADDRESS/v2/accounts/GFIDQ2XIX2CMPJZ4DS3ISIOPOCJQDGRB5JQGCVHG63CACQF3OXXRBLOIDM?round=15049487"
done

against an indexer $AF_IDX_ADDRESS for TestNet.
(You may want to change the round to the current round.)
Note that this code does not make any parallel queries to the indexer, it waits for the previous query to end before making a new query. So this should almost create no load on the indexer and on the DB.
TestNet indexer does not seem to crash. MainNet indexer does.
Setup

algorand-indexer version:$ algorand-indexer -v
2.5.0 compiled at 2021-06-22T18:26:33+0000 from git hash 1f3fb466681dc0f025be504576e4632b83130e27 (modified)

OS: macOS BigSur 11.4

Version 2.3.4 of indexer did not have this issue.
Urgency/Relative Priority
Relatively urgent: Allows crashes of the indexer with very low load

Duplicate of #517

Two guesses (not tested/verified):

https://github.com/algorand/indexer/blob/8a73e917dc11f963b6c1ea52cce991d37e3c3190/idb/postgres/postgres.go#L1609
does not commit/rollback the transactions.
https://github.com/algorand/indexer/blob/8a73e917dc11f963b6c1ea52cce991d37e3c3190/idb/postgres/postgres.go#L1722 does not .Close the rows object when it early finishes the for loop (https://golang.org/pkg/database/sql/#Rows.Close)

@fabrice102, thanks for the suggestions! Please check if #554 fixes it.


Bad Link

There's a bad link in this paragraph.

The properties blob for the Diagnostic Setting follows the format described in this article

Thanks!

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

ID: b8f43189-3418-fd30-0528-550157d8366d
Version Independent ID: 049e3b0e-6f10-6985-c719-05fe43fc00b8
Content: Automatically enable Diagnostic Settings using a Resource Manager template
Content Source: articles/monitoring-and-diagnostics/monitoring-enable-diagnostic-logs-using-template.md
Service: monitoring-and-diagnostics
GitHub Login: @johnkemnetz
Microsoft Alias: johnkem

@joeizy
Thanks for the feedback! We are currently investigating and will update you shortly.

@joeizy  The bad link has been fixed . Thanks again for bringing this to our attention. We will now close this issue. please don't hesitate to re-open if you have any followup questions.

Awesome you rock!


Core: matchGrammar now uses a linked list

This changes the implementation of matchGrammar to use a linked list instead of an array to replace this O(n) (worst case) operation with an O(1) operation.
Prism.tokenize performance on the minified and dev source of Prism with all languages from the download page:

Code
Size
Array
Linked list
Gain

Prism JS lang
3.5kB
0.232ms +-0.304µs  10k samples
0.179ms +-0.262µs  10k samples
1.3x faster

Prism Core min
6kB
1.26ms +-3.08µs  1000 samples
0.818ms +-3.45ms  1000 samples
1.54x faster

Prism Core
13kB
2ms +-7µs  500 samples
1.45ms +-5.62µs  500 samples
1.38x faster

Minified  (Core + all languages)
317kB
98.2ms +-0.177ms  50 samples
73.9ms +-0.198ms  50 samples
1.33x faster

Dev  (Core + all languages)
403kB
111.5ms +-4.4ms  50 samples
66.5ms +-0.476ms  50 samples
1.68x faster

Dev²
806kB
3913ms +-53ms  10 samples
193ms +-0.432ms  50 samples
20.3x faster

Some big JSON  using JS grammar
39MB
142s  1 sample
1440ms +-33.5ms  5 samples
98.6x faster

Same JSON  using JSON grammar
39MB
214s  1 sample
876ms +-4.45ms  5 samples
244x faster

(Dev² is the code of dev concatenated with the code of dev)

Test code
const fs = require('fs');
const { performance } = require('perf_hooks');
const Prism = require('./components/prism-core');
const loadLanguages = require('./components/index');

loadLanguages(['javascript']);
const js = Prism.languages['js'];

// load the test code
const code = fs.readFileSync('./testCode.txt', 'utf-8');
console.log(`${code.length} characters`);

function measure(func, sampleCount = 20) {
	var samples = [];
	for (let i = 0; i < sampleCount; i++) {
		const start = performance.now();
		func();
		samples.push(performance.now() - start);
	}
	const e = samples.reduce((y, x) => x + y, 0) / samples.length;
	const std = Math.sqrt(samples.reduce((sum, x) => sum + (x - e) ** 2, 0)) / (samples.length - 1);

	return `${e}ms +-${std}ms`
}

console.log('Warm up');
measure(() => Prism.tokenize(code, js));

console.log('measure');
console.log(`tokenize: ${measure(() => Prism.tokenize(code, js), 50)}`);

Why it isn't always hugely faster
Before we start: Please note that n is not the number of characters in the text but the current number of tokens in the token array/list. This number increases over time and depends on both the text being highlighted and the grammar used.
The gain in performance is significant but less than I expected for switching from an O(n) operation to an O(1) operation.
The main reason for this, I think, is that splice will operate quite often in O(1) which is the case when as many tokens are deleted as inserted.
The easiest example of this is when a regex matches the whole string (not the whole text but a whole token string), in which case the entire string will be replaced with the created token making splice O(1). The more token there already are in the array, the more likely this is to happen because the strings get shorter and shorter.
This means that splice is very likely to operate in O(n) when n is small (there are few tokens compared to the overall text length) and it is very likely to operate in O(1) when n is large.
This is most likely the reason why the array implementation is faster for the minified code than for the dev code. Because all spaces are removed, the last regexes (which are punctuation and operators) will almost always match the entire string. This advantage is enough to combat the increase in greedy rematching which can be seen in the extra milliseconds of the linked list implementation.
Greedy rematching is also the main reason why the gain isn't as big for the minified code.
That being said. For a text large enough, the linked list implementation will always be significantly faster.
So, what now?
The performance gain is only really noticeable for large amounts of text and comes with some extras bytes (~700bytes minified). So this PR won't help the average user which just wants to highlight his/her ~200 lines of code. Half a millisecond faster or not just doesn't make a difference.
Another caveat is that this is technically a breaking change because I changed the parameters of matchGrammar. It's not even possible to use this function from the outside anymore because I don't expose the LinkedList class. Sure enough, the function isn't documented anywhere and could be seen as undefined behavior but this PR might still break someone's code.
(Why do we expose this function in the first place?)
The average user won't noticeable profit from this PR and it might even break some people's code but the performance gain for people who highlight large amounts of text is very real.
Please tell me what you think.

Here's an updated benchmark:

Benchmark
C:\Users\micha\Git\prism>npm run benchmark -- --maxTime=30 --remotesOnly

><EMAIL_ADDRESS>benchmark C:\Users\micha\Git\prism
> node benchmark/benchmark.js "--maxTime=30" "--remotesOnly"

Found 6 cases with 14 files in total.
Test 2 candidates with Prism.tokenize
Estimated duration: 14m 0s

------------------------------------------------------------

css

  ../../style.css (7 kB)
  | PrismJS@master                      1.18ms ±  0%  538smp 1.38x
  | RunDevelopment@core-linked-list     0.85ms ±  0%  541smp

------------------------------------------------------------

css!+css-extras (css)

  ../../style.css (7 kB)
  | PrismJS@master                      1.88ms ±  0%  529smp 1.38x
  | RunDevelopment@core-linked-list     1.37ms ±  0%  538smp

------------------------------------------------------------

javascript

  ../../components.json (26 kB)
  | PrismJS@master                      3.64ms ±  0%  493smp 2.13x
  | RunDevelopment@core-linked-list     1.71ms ±  0%  523smp
  ../../package-lock.json (196 kB)
  | PrismJS@master                     81.60ms ± 18%  131smp 7.19x
  | RunDevelopment@core-linked-list    11.35ms ±  2%  429smp
  ../../prism.js (27 kB)
  | PrismJS@master                      4.82ms ±  0%  498smp 1.54x
  | RunDevelopment@core-linked-list     3.14ms ±  0%  509smp
  ../../scripts/utopia.js (11 kB)
  | PrismJS@master                      1.80ms ±  0%  531smp 1.47x
  | RunDevelopment@core-linked-list     1.22ms ±  0%  533smp
  https://code.jquery.com/jquery-3.4.1.js (274 kB)
  | PrismJS@master                    590.68ms ± 34%   26smp 20.13x
  | RunDevelopment@core-linked-list    29.35ms ±  0%  331smp
  prism.min.js (13 kB)
  | PrismJS@master                      2.91ms ±  0%  521smp 1.62x
  | RunDevelopment@core-linked-list     1.79ms ±  0%  528smp

------------------------------------------------------------

json

  ../../components.json (26 kB)
  | PrismJS@master                      3.15ms ±  0%  506smp 2.77x
  | RunDevelopment@core-linked-list     1.14ms ±  0%  517smp
  ../../package-lock.json (196 kB)
  | PrismJS@master                     88.24ms ± 15%  115smp 12.42x
  | RunDevelopment@core-linked-list     7.11ms ±  0%  455smp

------------------------------------------------------------

markup

  ../../download.html (4 kB)
  | PrismJS@master                      0.51ms ±  0%  549smp 1.52x
  | RunDevelopment@core-linked-list     0.34ms ±  0%  549smp
  ../../index.html (19 kB)
  | PrismJS@master                      2.58ms ±  0%  531smp 1.46x
  | RunDevelopment@core-linked-list     1.77ms ±  0%  526smp

------------------------------------------------------------

markup!+css+javascript (markup)

  ../../download.html (4 kB)
  | PrismJS@master                      0.84ms ±  0%  541smp 1.44x
  | RunDevelopment@core-linked-list     0.58ms ±  0%  551smp
  ../../index.html (19 kB)
  | PrismJS@master                      3.23ms ±  0%  524smp 1.35x
  | RunDevelopment@core-linked-list     2.39ms ±  0%  524smp

------------------------------------------------------------

summary
                                   best  worst  relative
  PrismJS@master                      0     14     4.13x
  RunDevelopment@core-linked-list    14      0     1.00x

My initial thoughts are here. @RunDevelopment responded here.
I'd love to hear @Golmote's or @LeaVerou's thoughts on the trade-off between bundle size & performance and whether this trade-off is worth it in this case.

Regarding bundle size:
Right now, this will increase the size of prism-core.min.js by ~500Bytes (6446B -> 6962B).
(I can probably save another ~100Bytes by using gulp to rename the internal properties of the linked list implementation which uglify doesn't replace with single-character names. Kinda hacky and about the last thing I can do.)

This is pretty smart, I like this idea. This doesn't even add a whole lot of code, really.
Regarding BC, the function was never listed on https://prismjs.com/extending.html so I'd say it should be quite safe to break it. Or this PR can join the others for the 2.0 milestone.

Fair enough, let's do it.

Then I'll also make matchGrammar a private function since this will break it anyway.


Filemin in Usermin

If you install Filemin under Usermin it gives you an error:
: Module filemin is for Webmin, not Usermin
If you install Filemin manually - it just works perfectly!
Please fix, ok!?

Never used Usermin is it intended to install modules too?

Yes, it does! Try and see! ;)

Never tried it, AFAIK from dev documentation there're some differences between Usermin and Webmin modules. I'll look into it, but if adopting Filemin to be installable from Usermin will require it as a dependency it won't be done cause Filemin is designed to work from Webmin at first.

Usermin is Webmin but in usermode. Jamie can and should include it to Usermin! Tell him about this!;)

It should be easy to port this to Usermin as well - I'll do this today.

0.9.6 is out.


Include DevEUI in uplink message

This is a feature request for the Backend.
I'd like to have the DevEUI as part of the uplink message. Upstream components (e.g. IoT platforms) may use the DevEUIs to look up devices and may not be aware of a custom Dev ID. Currently, the advised way is to use the DevEUI as Dev ID, but I'd like to be able to use the Dev ID for human readable reference.

How would this work when we start supporting non-LoRaWAN devices? Or are we okay with being tied with LoRaWAN like this?

Put it in the metadata; that's already LoRaWAN specific. Also we're not tied to the term DevEUI there; it's more like a hardware serial


Fix for rows appearing out of order in attribute overview

Description
closes #2730
Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[x] Attached issue to pull request
[x] Changelog entry
[x] Code is clear and sufficiently documented
[x] Sufficient test cases (reproduces the bug/tests the requested feature)
[x] Correct, in line with design
[x] End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )

Reviewer Checklist:

[ ] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Code is clear and sufficiently documented
[ ] Correct, in line with design

Processing this pull request

Merged into branches iso5, master in 8e8ffdf729b079a2357f2d4600c3d973703f711b

Processing #2892.


about visualization

Hello,can you provide the visualization of segmentation on scannet dataset?

Hey, do you want code for visualization or some sample visualizations?

Hey, do you want code for visualization or some sample visualizations?

Thank you for your reply,I mean the visualization of segmentation result,how to generate .ply files and meshlab can open it.

The segmentations produced here are 2D, i.e. images. The task for active learning is 2D semantic segmentation, not 3D. Sorry!


Running goaws without a config file that defines AccountId will result in a ReceiveMessage returning invalid XML

I ran goaws as the compiled binary without passing in any config file.
When I received a message using the aws-sdk for node.js i got a cryptic XML parsing error which I traced back to the XML that goaws was returning was missing a <Value> for  SenderId:
<ReceiveMessageResponse xmlns="http://queue.amazonaws.com/doc/2012-11-05/">
      <ReceiveMessageResult>
          <Message>
              <MessageId>bb763f86-eddf-4217-90f5-857834d09e27</MessageId>
              <ReceiptHandle>bb763f86-eddf-4217-90f5-857834d09e27#71889a5d-720f-49fa-9019-f9b252106262</ReceiptHandle>
              <MD5OfBody>5eb63bbbe01eeed093cb22bb8f5acdc3</MD5OfBody>
              <Body>hello world</Body>
              <MD5OfMessageAttributes>96656da642fec3b345246d3753b407b8</MD5OfMessageAttributes>
              <MessageAttribute>
                  <Name>command</Name>
                  <Value>
                      <DataType>String</DataType>
                      <StringValue>compile</StringValue>
                  </Value>
              </MessageAttribute>
              <Attribute>
                  <Name>SenderId</Name>
              </Attribute>
              <Attribute>
                  <Name>ApproximateReceiveCount</Name>
                  <Value>1</Value>
              </Attribute>
              <Attribute>
                  <Name>SentTimestamp</Name>
                  <Value>1606344521</Value>
              </Attribute>
              <Attribute>
                  <Name>ApproximateFirstReceiveTimestamp</Name>
                  <Value>1606344521</Value>
              </Attribute>
          </Message>
      </ReceiveMessageResult>
      <ResponseMetadata>
          <RequestId>00000000-0000-0000-0000-000000000000</RequestId>
      </ResponseMetadata>
  </ReceiveMessageResponse>

I was super confused because when I used the AWS cli to interact with goaws per the examples at the bottom of the goaws README, the aws-cli would return a value for SenderId!:
{
    "Messages": [
        {
            "MessageId": "fa3f13bf-186a-41a6-9724-7580f06cab31",
            "ReceiptHandle": "fa3f13bf-186a-41a6-9724-7580f06cab31#feff7a77-1a0e-48a1-a7b7-5fc550a05935",
            "MD5OfBody": "5eb63bbbe01eeed093cb22bb8f5acdc3",
            "Body": "hello world",
            "Attributes": {
                "ApproximateFirstReceiveTimestamp": "1606346671",
                "SenderId": "1606346671",
                "ApproximateReceiveCount": "1",
                "SentTimestamp": "1606346671"
            },
            "MD5OfMessageAttributes": "96656da642fec3b345246d3753b407b8",
            "MessageAttributes": {
                "command": {
                    "StringValue": "compile",
                    "DataType": "String"
                }
            }
        }
    ]
}

A keen eye would notice that SenderId has the same value as ApproximateFirstReceiveTimestamp, so I assume that is a quirk of the XML => JSON process in the aws-cli.
Digging through the code, it appears as if there is an attempt to cover for this and set the AccountId to "queue" when not present in config.go. However, I think if you're not passing in any yaml file then this would not happen.
Once I created a config file that defined the account id, everything worked as expected:
Local:
  AccountId: "13371337"

Looking through other issues, I suspect this issue was caused by the same setup as well - as the slightly cryptic XML parsing error look equivalent.
I recommend either making the -config flag mandatory or properly setting the AccountId when the config file is not set

@tomtomau Thanks for bringing this up.  I did a change to sort out the default config file a little while ago.  Let me double check that and see if it resolved this issue by happen stance.  We'll see.  I'll look at it and get back to you.


Refactor wildcard matching

The main goal of this work is to unify code used for wildcard matching into one place. Currently, probe listing uses different code to resolve wildcards than probe attachment does, which results in possible discrepancies (such as in #565). The idea is that if some probes are listed, they can be attached with the same syntax.
There are two primary changes done:

all code related to probe matching is moved into a new class ProbeMatcher,
when listing probes, we use the standard Bison parser and AttachPointParser to parse the listing query. This required a change in the parser grammar: different rule for attach points for listing (when attach point is a listing query) and for probe attachement.

Some details worth mentioning:

Listing allows to use wildcards in probe type, while attachment originally doesn't. To cope with this, AttachPointParser tries to expand the probe type and when multiple types are matched, it creates new AttachPoint objects that replace the original AttachPoint object created by the Bison parser.
On the other hand, this PR allows to attach a single program to multiple attach points from different providers using a wildcard (e.g. k*:vfs_open). This should not break anything, though, since it was possible before by just simply enumerating the attach points (kprobe:vfs_open,kfunc:vfs_open).
One round of semantic analyser is run when listing probes to make the errors consistent for listing and attachement.
All usages of regular expressions should be now removed.

Resolves #565, resolves #1489, fixes #1581.
Checklist

[ ] Language changes are updated in docs/reference_guide.md
[x] User-visible and non-trivial changes updated in CHANGELOG.md
[x] The new behaviour is covered by tests

The PR is ready for review.
The remaining thing to decide is: how do we treat empty probe parts (both for listing and attachment)? Currently, probe listing allows empty probe parts (by treating them as '') but probe attachment doesn't. Since we want to unify this, we have to choose one of the approaches. I'd prefer treating empty probe parts as '', which will keep the compatibility and make the attach point/listing specs shorter. @fbs, @brendangregg WDYT?

I don't review the code yet but it seems something wrong with struct listing.
before:
% time sudo ./src/bpftrace -lv 'k:vfs_open'
BTF: using data from /sys/kernel/btf/vmlinux
kprobe:vfs_open
a0.10s user 0.33s system 91% cpu 0.473 total

after:
% time sudo ./src/bpftrace -lv 'struct path'
BTF: using data from /sys/kernel/btf/vmlinux
struct path {
        struct vfsmount *mnt;
        struct dentry *dentry;
};
struct path_cond {
        kuid_t uid;
        umode_t mode;
};
11.08s user 0.21s system 85% cpu 13.137 total  // too slow

Anther issuse:
% sudo ASAN_OPTIONS=detect_leaks=0 ./src/bpftrace -e 't*a:a{}'
FATAL: program type invalid\
zsh: abort      sudo ASAN_OPTIONS=detect_leaks=0 ./src/bpftrace -e 't*a:a{}'

The program shouldn't abort, should print an error.

I don't review the code yet but it seems something wrong with struct listing.
before:
% time sudo ./src/bpftrace -lv 'struct path'
BTF: using data from /sys/kernel/btf/vmlinux
struct path {
        struct vfsmount *mnt;
        struct dentry *dentry;
};
0.13s user 0.33s system 92% cpu 0.505 total

after:
% time sudo ./src/bpftrace -lv 'struct path'
BTF: using data from /sys/kernel/btf/vmlinux
struct path {
        struct vfsmount *mnt;
        struct dentry *dentry;
};
struct path_cond {
        kuid_t uid;
        umode_t mode;
};
11.08s user 0.21s system 85% cpu 13.137 total  // too slow

Thanks for noticing, this should be fixed now.

Anther issuse:
% sudo ASAN_OPTIONS=detect_leaks=0 ./src/bpftrace -e 't*a:a{}'
FATAL: program type invalid\
zsh: abort      sudo ASAN_OPTIONS=detect_leaks=0 ./src/bpftrace -e 't*a:a{}'

The program shouldn't abort, should print an error.

Yes, the problem here is that t*a doesn't match any probe type, which I don't handle properly (hence the abort). But this reveals another inconsistence in bpftrace - how should we handle wildcarded attach points that have no matches?
From the current master:
# bpftrace -e 't:*:nonsense {}'
stdin:1:1-13: ERROR: tracepoints not found: *:nonsense
t:*:nonsense {}
~~~~~~~~~~~~

but on the other hand:
bpftrace -e 'k:nonsense* {}'
No probes to attach

I'd say that this should be unified - either always print an error or always ignore that attach point.

I agree with you, it's better if the behavior is unified. But I guess the reason currently trying to attach nonexistent kprobe is allowed is to make the script work as much as possible because kernel function names can change from version to version. For example, in my environment (kernel 5.9), one of the kprobe in biostacks.bt does not exist.
% sudo ./src/bpftrace ../tools/biostacks.bt
Attaching 5 probes...
cannot attach kprobe, probe entry may not exist
WARNING: could not attach probe kprobe:blk_start_request, skipping.

or more simple example is
% sudo ./src/bpftrace -e "k:a,k:f {}"
Attaching 2 probes...
cannot attach kprobe, probe entry may not exist
WARNING: could not attach probe kprobe:a, skipping.

We also want no to break existing scripts as much as possible. So I think we should keep the current behavior, that means error if wildcard matches any probe type, error if wildcard attach point exists except kprobe (I'm not sure about other than kprobe and tracepoint, so we need check other probes)

We also want no to break existing scripts as much as possible. So I think we should keep the current behavior, that means error if wildcard matches any probe type, error if wildcard attach point exists except kprobe (I'm not sure about other than kprobe and tracepoint, so we need check other probes)

This sounds like a good way to go. I'd say that we shoudn't fail on non-existing probes for probe types that are not stable: kprobe, kfunc, uprobe, usdt. To sum it up:

error if probe type doesn't exist/match,
ignore non-existing attach points for non-stable probe types (kprobe, kfunc, uprobe, usdt),
error if attach point doesn't exist/match for all other probe types.

Looks like this works before: sudo ./src/bpftrace -lv "*:*:*"

I realized that now
% sudo ./src/bpftrace -l 'k:vfs_write,k:vfs_open'
kprobe:vfs_write
kprobe:vfs_open

works. It is good thing, but it seems -v option does not work. ./src/bpftrace -lv 'k:vfs_write,k:vfs_open' gives the same output as the above.

I'll check the remaining code when I have time.

I realized that now
% sudo ./src/bpftrace -l 'k:vfs_write,k:vfs_open'
kprobe:vfs_write
kprobe:vfs_open

works. It is good thing, but it seems -v option does not work. ./src/bpftrace -lv 'k:vfs_write,k:vfs_open' gives the same output as the above.

That's expected, kprobes do not list arguments with -v (neither they did before). It's kfuncs doing that:
# src/bpftrace -lv 'f:vfs_write,f:vfs_open'
kfunc:vfs_write
    struct file * file
    [...]
kfunc:vfs_open
    const struct path * path
    [...]

I realized that now
% sudo ./src/bpftrace -l 'k:vfs_write,k:vfs_open'
kprobe:vfs_write
kprobe:vfs_open

works. It is good thing, but it seems -v option does not work. ./src/bpftrace -lv 'k:vfs_write,k:vfs_open' gives the same output as the above.

That's expected, kprobes do not list arguments with -v (neither they did before). It's kfuncs doing that:
# src/bpftrace -lv 'f:vfs_write,f:vfs_open'
kfunc:vfs_write
    struct file * file
    [...]
kfunc:vfs_open
    const struct path * path
    [...]

my bad,  I forgot about it.

Looks like this works before: sudo ./src/bpftrace -lv "*:*:*"

Right, thanks. This should now work as before.

% sudo ./src/bpftrace -l "k*:vfs_open"
kfunc:vfs_open
kprobe:vfs_open
kretfunc:vfs_open

this is ok but
% sudo  ./src/bpftrace -l "f*:vfs_open"
stdin:1:1-12: ERROR: No probe type matched
f*:vfs_open
~~~~~~~~~~~

% sudo  ./src/bpftrace -lv "*:vfs_open"
stdin:1:1-1: ERROR: vfs_open is not a hardware probe
*:vfs_open

stdin:1:1-1: ERROR: vfs_open is not a software probe
*:vfs_open

% sudo  ./src/bpftrace -l "f*:vfs_open"
stdin:1:1-12: ERROR: No probe type matched
f*:vfs_open
~~~~~~~~~~~

This is intentional since f* does not match any probe type. I improved the error message, though:
stdin:1:1-12: ERROR: No probe type matched for f*

% sudo  ./src/bpftrace -lv "*:vfs_open"
stdin:1:1-1: ERROR: vfs_open is not a hardware probe
*:vfs_open
stdin:1:1-1: ERROR: vfs_open is not a software probe
*:vfs_open

This is now fixed:
# src/bpftrace -lv "*:vfs_open"
kfunc:vfs_open
    const struct path * path
    [...]
kprobe:vfs_open

I also removed kretfunc as it is just a duplicate of kfunc (similarly, kretprobe are not listed).

OK^
It seems listing can only work without other queries. This is not supported previously, but I think it would be useful. What do you think?
sudo  ./src/bpftrace -lv "f:vfs_open, struct path"
stdin:1:12-12: ERROR: Unrecognized probe type:
f:vfs_open, struct path

or
sudo ./src/bpftrace -lv "struct path,struct file"

It seems listing can only work without other queries. This is not supported previously, but I think it would be useful. What do you think?

Might be useful, but I'd rather not extend this PR with additional features, it's quite large already. We can add this later in a separate PR.

Overall looks good and good improvements to me, but definitely more reviewers are needed because of its size. Also, I wonder if we can have tests for ProbeMatcher.

I already thought about this, but then I realized that matching is already tested in tests/bpftrace.cpp, tests/parser.cpp, and in runtime tests. It might make sense to group these into a separate test class for ProbeMatcher (although I would, again, postpone it to another PR).

Overal it looks good to me, nice cleanup.
I'm not that happy with the way this hooks into semantic analysis. It's another thing bolted into the semantic analyser that makes it a bit more complex. A separate simpeler pass seems more appropriate to me. But as its a nice cleanup we shouldn't block on it imo

@danobi any feedback?
I want to merge this soon but it needs a rebase @viktormalik .

Rebased, ready to merge.
There's still an unresolved issue - how to treat empty probe parts? See this review and this comment for details. Currently, this PR requires that each probe part is specified, which is not backwards compatible with listing (previously, listing allowed to skip probe parts). I think that this is not a big issue (since it's only listing), I'd suggest merging this PR and then maybe adding a possibility to omit empty probe parts as another PR.

One embedded build test time-outed, but it passes on my fork branch (check here). I guess a restart could solve this.

Is this waiting for me? I think that the CI fail should be resolved by a restart and otherwise the PR should be ready for merge.

Looks ok to me :)

Needs a rebase

Rebased


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-2.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 348

Questions ?
Please refer to the Backport tool documentation


Magento 2.3 compatibility?

The module does not seem to be compatible with Magento 2.3 version.
As per dependency for magento/framework in composer.json
magento/framework: 100.0.*|100.1.*|101.0.*
Running composer require addressfinder/module-magento2 command breaks.

Hi Sudma,
Thanks for letting us know. We are looking into this currently and hope to have a solution soon.


add length() and is_empty() to Buffer

As required in the Markdown parser implementation.

Pull Request Test Coverage Report for Build 3254
Details

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.007%) to 83.17%

Totals

Change from base Build 3252:
0.007%

Covered Lines:
4077

Relevant Lines:
4902

💛  - Coveralls

related https://github.com/moonbitlang/core/pull/1084

@rami3l can you cherry pick these APIs into the new buffer package

@rami3l can you cherry pick these APIs into the new buffer package

Rebased.

May I ask what is blocking this PR from being merged? Many thanks in advance :)

lgtm @rami3l sorry for the delay

@bobzhang Thanks again! The PR is now rebased.


Auto-detecting latest tool versions

It seems like the list of versions is manually maintained. This seems hard to scale and already is at the point where it would be hard to blame you for failing to notice that a release happened.
I'm hoping to use install-action to replace some similar code (in an unreleased project). However, remembering to update to the latest version seemed impractical to me, so my code auto-detected it using the github API + jq (jq is pre-installed on GHA runners). The code was something like this:
api_url="https://api.github.com/repos/$repo/releases/latest"
query='.assets[] | select(.name | endswith("x86_64-unknown-linux-gnu.tar.gz")) | .browser_download_url'

tarball_url="$(curl --proto '=https' --tlsv1.2 --retry 5 --retry-delay 10 -sfSL "$api_url" | jq -r "$query")"
# then fetch the tarball was fetched with
# curl <same flags> "$tarball_url" | tar zxf -

This hard-codes several things which would need to not be hard-coded for install-action usage, but it may be useful as a starting point. (Also, I'm not good at sh, so this may do something that is not ideal in some way). But you get the picture.
Although, maybe it's not how you'd like to do it. There's an argument that auto-detecting the latest version in this way is fragile, both because it makes too many API requests, and because it breaks if a release happens without binaries. It also doesn't easily support usage with a checksum as required by #1.
So perhaps it would be better to instead automate the updates of install-action's version list in some manner. This seems harder to me though, but perhaps you have plans.
Anyway, sorry if my concern is misplaced and you do not think this will be a problem. I just felt a little bit bad adding to your workload by adding a new tool after I noticed that versions were hard-coded.
Thank you.

Thanks for writing this! I strongly agree that auto-detection of the latest version is necessary.
(Currently, I track the latest releases by watching the releases of these repositories, but I acknowledge that it is an easy-to-forget and non-scalable way.)

There's an argument that auto-detecting the latest version in this way is fragile, both because it makes too many API requests, and because it breaks if a release happens without binaries.

Yes. In the past, this action used the similar way that you mentioned (https://github.com/taiki-e/install-action/commit/56a03286dbf2186895b23d8966c0998292e19af6), but I have encountered both of these problems.

So perhaps it would be better to instead automate the updates of install-action's version list in some manner. This seems harder to me though, but perhaps you have plans.

The repository that manages homebrew tap for my project has a script that automates this (and CI to auto-create PR when the update is needed), so I'm considering porting it.

Currently, I track the latest releases by watching the releases of these repositories, but I acknowledge that it is an easy-to-forget and non-scalable way

Yeah, I figured as much (this is also how I'd do it too).

Yes. In the past, this action used the similar way that you mentioned (https://github.com/taiki-e/install-action/commit/56a03286dbf2186895b23d8966c0998292e19af6), but I have encountered both of these problems.

That makes sense, I had kinda assumed the window between the release creation and binary upload, but figured it would be too small for that to happen in practice, but given how frequently CI runs happen (especially as the number of all projects using the action increases), I'm not sure why I thought this.

The repository that manages homebrew tap for my project has a script that automates this (and CI to auto-create PR when the update is needed), so I'm considering porting it.

Ah, this is a better solution I think. Then you'd just need to run the CI that does the version check/PR on a cron. Or something like that, anyway. For some reason, I thought making automated PRs was somewhat more involved, and couldn't just be done from an action.

Rambling about prebuilt binaries and version update automation

Uh, I apologize in advance for this rambling mess. It started out as a reply to your comment in #4, but it... got out of hand. Much of this is me working it out for myself, and has not been really refined, although I think it's coherent? Maybe?
The basic idea is that you can get the benefits of them with less work by just putting a little more smarts in the hypothetical "version update detector / PR maker" code, also, note that there's a summary at the end.

It's hard to say what to do about prebuilt binaries. I think it would allow avoiding the version compat issues that mdbook has and would allow simplifying the main.sh quite a bit, but... it comes with a lot of pain. I suspect the lack of consistency for release formats, archive names, etc. is generally less difficult to address than inconsistencies between ecosystems, build systems, etc. (see the end for more here)
That is, IME there's really no limit to how annoying an arbitrary project can be to build (although it's not unthinkable to do this for stuff like rust, go, zig, <insert other modern portable compiled language here...>). To put it another way, I think it basically means you're taking on basically taking on a subset of the roles that packagers[^pkgmgr] are responsible for... which gets a lot harder when you start expanding focus to other build systems and ecosystems.
That said, it might be worth it sometimes, but probably only for packages without prebuilt binaries, and which have a sufficient ratio between usefulness and build complexity to justify the hassle.
Handling Unsupported Github Runner OS Versions
For stuff that has binaries like this, I think I'd want to handle it differently. Basically, I'd want to teach the install-action script about which github runner OS versions are supported by which packages.
This is a big pain to do manually, but if updates are automated, I think it's a lot easier -- the bot that does the update PR can also try on many different runners, see which ones are compatible, and automatically update information the script has about it.
Then, if a user tries to use the package on a runner that is not supported the script can produce a nicer error[^override]. For example, IMO an error like "No prebuilt binary available for mdbook that supports ubuntu-18.04. Please use ubuntu-20.04 or later" (wording can be bikeshedded ofc) would make it very clear how to address the problem as a user. Most of the time I think this would be actionable[^action].
A benefit of this approach is that it is still useful even if if it turns out you want to manage the binaries yourself. It's very likely that the binaries would still have some runners they don't work under, and this would help in that case.
Handling inconsistent URL/Tag/release formats
So, let's ignore OS/version compat issues like the one with mdbook, though, and just consider "the lack of uniform formats for URLs, archive names, ...". and try to solve that without performing the build ourselves. I think this is possible.
The thought is: use the code that automatically performs PRs for new releases (which I'm going to refer to as "the pr maker"[^maker]), and have it also be responsible for normalizing these differences and re-publishing the normalized version somewhere using a normalized/consistent[^consistent] scheme for tagging, versions, compression, naming, etc.
[^maker]: Yes, even though I'm all these responsibilities it might have in addition to making PRs about new releases.
Now, this would just be moving complexity from the install-action/main.sh script into the code for whatever makes the PRs on new releases, so is this better than just keeping that complexity in install-action/main.sh?
There are a couple reasons I see, but some of them may not be convincing for you, IDK.

(debatable) The pr maker has looser constraints around OS/version compat, can be written in any language (even one which is slow, or which has long compile times). This means it could be in a language that has better abstractions than sh. Maybe this is just my lack of skill at writing sh, so this one might be unconvincing.

Similarly, the PR maker can pretty much use whatever software it needs, even if that software would be impractically slow to build/use (either slower than just doing cargo install foobar, or close enough to not be worth using the action).

Most importantly (I think), the pr maker does not need to handle schemes which were used for past releases, but will not be used by any future releases.

A Hypothetical Case
To elaborate on the previous benefits, lets consider a hypothetical package foosmtime has decided to switch its prereleased packages from using .tar.xz to .tar.zstd in version 1.0.0, and evaluate the two[^two] following approaches:
[^two]: I'm leaving out the third approach of "do the build yourself", since it's a natural extension of approach 2, and is otherwise irrelevant for this problem (since you wouldn't use the prebuilt binaries, although you may have similar issues if you did the build yourself when some package overhauls the build system between two versions).

The "smart main.sh" approach, which is a lot like what you have now, where the main.sh (or more broadly, the code which runs as part of the action) has all the smarts for handling each version of each package.
In this world, the PR maker is largely irrelevant aside from being the thing that makes PRs.

The "smart pr maker" approach, where all the complexity lives in the PR maker, which rebundles and rehosts every package to normalize tagging scheme/compression format/filenames/download url/etc.
In this world, the main.sh code would be very very simple, and would handle basically every package identically.

So, the problem: foosmtime decided to switch from .tar.xz to .tar.zstd in version 1.0.0. How is this handled?
The "smart main.sh" approach:

First off, it leaves users who are on "latest" (the default) with broken CI until the install-action code is taught how to handle this change.

Then, it needs keep both the new .tar.zstd-handling code and the old .tar.xz-handling code. It also needs logic to determine which of these to use, based on what version is requested.
Alternatively, the old code can be removed, but this will break anybody who explicitly requrests an older tool, unless they also have pinned install-action.

If zstd is not supported on the github action runner (it is), some other way of decoding it must be found. This may require pulling down another binary, which is unfortunate.
That said, this case is unlikely, and as mentioned would not happen with zstd. I mention it mostly because the other approach handles it trivially.

The "smart pr maker" approach:

First off, most users will be unaware the update occurred. Critically: users who are on the "latest" version are not broken, and are instead left on the previous version until the PR maker is taught how to handle the new format, and the update to install-action occurs.

Then, the patch that updates the pr-maker code can immediately remove handling of tar.xz at the same time as it adds code to handle tar.zstd.
Critically, removing this will not break anyone, even if they're using an explicit version: all the releases which used tar.xz have already been normalized and reuploaded, and all the releases in the future will use tar.zstd.

If zstd is not supported on the github action runner, we can just add an external package, even if it has an annoying and slow installation process, or any other constraint that would be undesirable in the actual install-action github action.
(This is because the PR maker does not have strict performance constrants, beyond something like "run once per day")

That is to say, this approach seems much better.

Additionally, the flexability this approach has to install whatever software is needed (part 3) means that it's basically perfectly set up to perform the builds too, should that end up being necessary for some of the packages. It just is also able to get that same benefit without taking on that complexity in cases where the authors of the tool in question provide usable binaries themselves.
Which I suppose shouldn't be suprising, since this is just "do all the thing's you'd do if you did the build yourself, but reuse the prebuilt versions"...
Summary
Okay, that was honestly... quite rambling. I'm genuinely sorry. Most of it was talking through it for myself. Obviously this is your project, so you can take any approach you like.
Anyway, I guess the TLDR boils down to: IMO doing all the builds yourself sounds deceptively hard, but you can get a lot of the same benefits by sticking smarts into the tool that does version updates/PRs. Specifically:

The release updater/PR maker could detect which github runner OSes the tool supports, and provide that info in a way the install-action action can understand. Then, users will get a much better error than they'd get from a glibc version mismatch. IMO this could be made into a clear enough error message that the problem becomes fairly unimportant.

If you ignore the GHA runner OS support question (addressed by error messages IMO), and only consider tools which provide prebuilt binaries (for now) then you can handle the inconsistent release file/url/tag/formats by just reuploading them yourself to a new location in a known consistent way, while normalizing all that stuff.
Which is not trivial (but still strictly less than performing the builds yourslef) has a surprising number of benefits that I hadn't considered.

[^both]: At least for a while, although eventually you could say "we no longer support versions of $tool prior to x.y.z", at the cost of possibly breaking some users. (That said, this is not necessary with the suggested approach, as I describe)
[^consistent]: I'm imagining it could ensure that every package is at https://github.com/${some_repo}/releases/download/${tool}_${version}/${target}.tar.gz, or something like this. Where ${some_repo} could be something like taiki-e/install-action-binaries or whatever.
(That is is: the repo would be some new repo for this purpose -- since I suspect adding these release tags to the `install-action` repo would cause some confusion)

[^action]: Concretely, the actions they'd take is either change the runner os version or install via some other method, whereas if you get an error from the runtime binary loader, I imagine many users have no idea what to do, since that error is 100% jargon.
[^pkgmgr]: OTOH, I suppose it already is one, just with a very different focus than most.
[^override]: If this route is taken, it might be worth allowing the user to override this and try running it anyway, just in case install-action gets it wrong. Or not.

FYI, cargo-binstall actually supports automatically detecting the latest version.

This has been implemented in v2.0.0.
The implementation (#27) is basically an extension of the one described in https://github.com/taiki-e/install-action/issues/5#issuecomment-1087198391. The basic design/policy is something like "all the annoying stuff like gaps between tools is handled by the manifest generator" -- this allowed us to remove almost all package-specific code from main.sh.
As for the host OS version, mdbook has started distributing musl binaries, so it is not high on my priority list, but I think @thomcc's idea (better error messages) makes sense (thanks for the idea!), so I will try it.
Btw, the implementation I currently think of is as follows:

manifest generator: Extract binary from the archive, get the glibc version requirements (probably by objdump), and include it in the manifest.
main.sh: Check the host glibc version and the glibc requirement of the binary specified in the manifest, and emit an error or warning if the binary's glibc requirement is high. If the host is ubuntu lts, I think we could also suggest a specific version that meets the requirements.

For the latter, https://github.com/taiki-e/install-action/commit/bbbd8c89f25356b73d7b5320292906120b0f9752 that created for another purpose has a prototype of the code that handles the glibc version.


Cant find any data from android.dvfs and android.battery in moto g40 fusion(anddroid 12)

Hey,
Almost a week ago, I opened this issue https://github.com/google/perfetto/issues/730 , and was told that all the tables will be present, but they might just be empty if there would be no data available from the trace. So i dug deeper on what exactly I wanted, and there are 2 notable things, first being android's dvfs counters and the second is the monitor contention table.
I have multiple phones for testing, and one thing I noted is that these 2 tables were available when I was testing with a pixel7 running Android 14, but they were not in the moto g40 fusion running android 12. They both are running the same perfetto config which is
buffers: {
    size_kb: 522240
    fill_policy: DISCARD
}
buffers: {
    size_kb: 2048
    fill_policy: DISCARD
}
data_sources: {
    config {
        name: "android.packages_list"
        target_buffer: 1
    }
}
data_sources: {
    config {
        name: "android.gpu.memory"
    }
}
data_sources: {
    config {
        name: "android.power"
        android_power_config {
            battery_poll_ms: 1000
            battery_counters: BATTERY_COUNTER_CAPACITY_PERCENT
            battery_counters: BATTERY_COUNTER_CHARGE
            battery_counters: BATTERY_COUNTER_CURRENT
            collect_power_rails: true
        }
    }
}
data_sources: {
    config {
        name: "linux.process_stats"
        target_buffer: 1
        process_stats_config {
            scan_all_processes_on_start: true
            proc_stats_poll_ms: 1000
        }
    }
}
data_sources: {
    config {
        name: "android.log"
        android_log_config {
            log_ids: LID_EVENTS
            log_ids: LID_CRASH
            log_ids: LID_KERNEL
            log_ids: LID_DEFAULT
            log_ids: LID_RADIO
            log_ids: LID_SECURITY
            log_ids: LID_STATS
            log_ids: LID_SYSTEM
        }
    }
}
data_sources: {
    config {
        name: "android.surfaceflinger.frametimeline"
    }
}
data_sources: {
    config {
        name: "linux.sys_stats"
        sys_stats_config {
            meminfo_period_ms: 1000
            meminfo_counters: MEMINFO_ACTIVE
            meminfo_counters: MEMINFO_ACTIVE_ANON
            meminfo_counters: MEMINFO_ACTIVE_FILE
            meminfo_counters: MEMINFO_ANON_PAGES
            meminfo_counters: MEMINFO_BUFFERS
            meminfo_counters: MEMINFO_CACHED
            meminfo_counters: MEMINFO_CMA_FREE
            meminfo_counters: MEMINFO_CMA_TOTAL
            meminfo_counters: MEMINFO_COMMIT_LIMIT
            meminfo_counters: MEMINFO_COMMITED_AS
            meminfo_counters: MEMINFO_DIRTY
            meminfo_counters: MEMINFO_INACTIVE
            meminfo_counters: MEMINFO_INACTIVE_ANON
            meminfo_counters: MEMINFO_INACTIVE_FILE
            meminfo_counters: MEMINFO_KERNEL_STACK
            meminfo_counters: MEMINFO_MAPPED
            meminfo_counters: MEMINFO_MEM_AVAILABLE
            meminfo_counters: MEMINFO_MEM_FREE
            meminfo_counters: MEMINFO_MEM_TOTAL
            meminfo_counters: MEMINFO_MLOCKED
            meminfo_counters: MEMINFO_PAGE_TABLES
            meminfo_counters: MEMINFO_SHMEM
            meminfo_counters: MEMINFO_SLAB
            meminfo_counters: MEMINFO_SLAB_RECLAIMABLE
            meminfo_counters: MEMINFO_SLAB_UNRECLAIMABLE
            meminfo_counters: MEMINFO_SWAP_CACHED
            meminfo_counters: MEMINFO_SWAP_FREE
            meminfo_counters: MEMINFO_SWAP_TOTAL
            meminfo_counters: MEMINFO_UNEVICTABLE
            meminfo_counters: MEMINFO_VMALLOC_CHUNK
            meminfo_counters: MEMINFO_VMALLOC_TOTAL
            meminfo_counters: MEMINFO_VMALLOC_USED
            meminfo_counters: MEMINFO_WRITEBACK
            stat_period_ms: 1000
            stat_counters: STAT_CPU_TIMES
            stat_counters: STAT_FORK_COUNT
        }
    }
}
data_sources: {
    config {
        name: "android.heapprofd"
        target_buffer: 0
        heapprofd_config {
            sampling_interval_bytes: 4096
            process_cmdline: "com.google.android.youtube"
            continuous_dump_config {
                dump_phase_ms: 1000
                dump_interval_ms: 1000
            }
            shmem_size_bytes: 8388608
            block_client: false
            all_heaps: true
        }
    }
}
data_sources: {
    config {
        name: "android.java_hprof"
        target_buffer: 0
        java_hprof_config {
            process_cmdline: "com.google.android.youtube"
            continuous_dump_config {
                dump_phase_ms: 0
                dump_interval_ms: 1000
            }
        }
    }
}
data_sources: {
    config {
        name: "linux.ftrace"
        ftrace_config {
            ftrace_events: "binder/*"
            ftrace_events: "block/*"
            ftrace_events: "clk/*"
            ftrace_events: "ext4/*"
            ftrace_events: "f2fs/*"
            ftrace_events: "fastrpc/*"
            ftrace_events: "i2c/*"
            ftrace_events: "irq/*"
            ftrace_events: "kmem/*"
            ftrace_events: "memory_bus/*"
            ftrace_events: "mmc/*"
            ftrace_events: "oom/*"
            ftrace_events: "power/*"
            ftrace_events: "regulator/*"
            ftrace_events: "sched/*"
            ftrace_events: "sync/*"
            ftrace_events: "task/*"
            ftrace_events: "vmscan/*"
            ftrace_events: "sched/sched_switch"
            ftrace_events: "power/suspend_resume"
            ftrace_events: "sched/sched_wakeup"
            ftrace_events: "sched/sched_wakeup_new"
            ftrace_events: "sched/sched_waking"
            ftrace_events: "power/gpu_frequency"
            ftrace_events: "gpu_mem/gpu_mem_total"
            ftrace_events: "power/gpu_work_period"
            ftrace_events: "regulator/regulator_set_voltage"
            ftrace_events: "regulator/regulator_set_voltage_complete"
            ftrace_events: "power/clock_enable"
            ftrace_events: "power/clock_disable"
            ftrace_events: "power/clock_set_rate"
            ftrace_events: "mm_event/mm_event_record"
            ftrace_events: "kmem/rss_stat"
            ftrace_events: "ion/ion_stat"
            ftrace_events: "dmabuf_heap/dma_heap_stat"
            ftrace_events: "kmem/ion_heap_grow"
            ftrace_events: "kmem/ion_heap_shrink"
            ftrace_events: "sched/sched_process_exit"
            ftrace_events: "sched/sched_process_free"
            ftrace_events: "task/task_newtask"
            ftrace_events: "task/task_rename"
            ftrace_events: "lowmemorykiller/lowmemory_kill"
            ftrace_events: "oom/oom_score_adj_update"
            ftrace_events: "sched/sched_blocked_reason"
            ftrace_events: "ftrace/print"
            atrace_categories: "am"
            atrace_categories: "adb"
            atrace_categories: "aidl"
            atrace_categories: "dalvik"
            atrace_categories: "audio"
            atrace_categories: "binder_lock"
            atrace_categories: "binder_driver"
            atrace_categories: "bionic"
            atrace_categories: "camera"
            atrace_categories: "database"
            atrace_categories: "gfx"
            atrace_categories: "hal"
            atrace_categories: "input"
            atrace_categories: "network"
            atrace_categories: "nnapi"
            atrace_categories: "pm"
            atrace_categories: "power"
            atrace_categories: "rs"
            atrace_categories: "res"
            atrace_categories: "rro"
            atrace_categories: "sm"
            atrace_categories: "ss"
            atrace_categories: "vibrator"
            atrace_categories: "video"
            atrace_categories: "view"
            atrace_categories: "webview"
            atrace_categories: "wm"
            atrace_apps: "*"
            symbolize_ksyms: true
        }
    }
}
duration_ms: 60000

and the 2 traces can be found in Moto g40 Fusion and Pixel7
Thanks

The DVFS tables being unavailable does not surprise me as that's very closely tied to the hardware of the device. If the Moto device is using a different method for handling dvfs, that system might not be instrumented or might be instrumented in a different way meaning we don't have any insight into that system.
The monitor contention talbe being missing is a bit more surprising and likely because of something subtle which changed between Android 12 and more recent versions. I've forwarded to the author of that table to see if there's an easy fix.

https://r.android.com/3000578 adds support for monitor contention slices on old versions of Android. This should be available on the autopush UI and will make its way to other builds of trace processor/UI over the next several weeks.


Update tracelogging-record-and-display-tracelogging-events.md

Fix typo

@jogo- : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


Updating the autest version pin to 1.7.4.

(cherry picked from commit 60e6ace5c4c6908a0081bcbb2d5af197ab8a30c0)
I was seeing the issue locally during our autest runs of comparison tests on stderr being checked against stdout. This has been fixed in 1.7.4

[approve ci autest]

[approve ci autest]

[approve ci autest]

[approve ci autest]

[approve ci autest]


Ability to avoid sending dependency messages

Feature request
Firstly, thanks for this excellent project!
I am using tsx in a setup where there's other worker communication happening, and the {type: 'dependency'} message that is sent by the ESM and CJS loaders is causing failures because of an unknown message. Although this could be considered a bug with those tools, I am opening an issue here to request a mode where the loaders do not send messages.
The code has a comment saying these messages are for watch-mode, perhaps those messages can only be sent if watch mode is known to be active? Alternatively an environment variable could work.
Why?
I am experimenting with using tsx and its CJS and ESM loaders together with jest-light-runner to achieve a Jest setup without any Jest transforms, which results in an incredible performance improvement over using stock Jest and its isolated module system. Using Jest workers however results in failures because of the unknown message from tsx's loaders.
Alternatives
The issue is avoided if you first run Jest using --runInBand because this populates all caches after which multiple workers do work, because the {type: 'dependency'} message would no longer be sent.
Additional context
https://github.com/esbuild-kit/esm-loader/blob/d50ddacab0c0df8ee3ccafc75272d28889fb90fd/src/loaders.ts#L212-L217
https://github.com/esbuild-kit/cjs-loader/blob/e7ba7caf42cb1bdceacb0bcafd2db3fd747931c0/src/index.ts#L54-L59
I am willing to work on this myself, but would like to discuss the possibilities here before spending any time on it.

You should file a bug with the tool that's throwing the error.
Especially if it's a tool that's designed to run user-code, it should create it's own IPC namespace instead of expecting to be the only one on it.

Closing as the error is thrown by another tool, and there's no further discussion.


S3 Access Denied Error during CloudFormation Template Deployment

I encountered an S3 Access Denied error while attempting to deploy a CloudFormation template in a source account. Despite following the steps outlined in the CUDOS
I'm able to proceed step 1 without any issues. However, during step 2, when deploying the CloudFormation template, the error persists.
I've made multiple attempts to deploy the CloudFormation template after waiting for a certain period, but the issue persists. Any insights on resolving this would be appreciated.

Please make sure you follow the guidance and double check the parameters of the stack
Typically this error happen if the destination bucket in destination account is not yet created (stack not created in source account) or not configured to accept replication from source account (source account is not listed in parameters of the stack)
also prefix parameter should be the same

can you confirm that SourceAccountIds is set correctly in the stack of Destination account?

please can you write to our feedback email  https://catalog.workshops.aws/awscid/en-US/feedback-support we can set up a quick call to review.


Ambient light sensor integration / hyperiond configuration change realtime

I have an ambient light sensor and I want to change whiteLevel or valueGain parameters depending on the sensor data.
Is it possible to make hyperion re-read configuration file without a restart?
Ir it possible to make a json request with new settings to hyperiond ?

You can set the values temporarely (until the next restart of hyperion) via the hyperion-remote app (https://github.com/tvdzwan/hyperion/wiki/Command-line-utility#usage) or sending requests to the json server.


Incorrect cursor positioning in context menus in firefox

Hyprland Version
0.30.0
Bug or Regression?
Bug
Description
When I click “open link in a new tab” in the context menu, I am shown the “save object as” dialog box, I also select one site in the bookmarks and go to the one 5 lines below. The bug is not always reproduced, sometimes it is gone for a long time but then it returns. I tried to reproduce it in sway-git but this bug is not there.
How to reproduce
Described above
Crash reports, logs, images, videos
No response

+1 on bookmarks problem in firefox:

create folder with multiple bookmarks in bookmarks toolbar
click on folder and click on first bookmark from the list
Result: bookmark number 4 in the list gets opened (instead of first one)

There is a problem, but it doesn’t always appear, I’ll try to record a video.

but... firefox doesn't use sdl...?

I don't have SDL_VIDEODRIVER variable, but issue is reproducible for me. Feels like it might be the result of more generic problem: I cannot drag any bookmarks inside a folder. Folders are "draggable" but bookmarks inside a folder are not.

Worth noting I am on -git. Can anyone check -git?

I can't check git but on hyprland 0.30.0 in librewolf 118.0.1 i experience Menus opening in the wrong place (the right click context menu even has a variable offset to the mouse cursor depending on its position on screen) and in differing sizes/zoom states. So e.g. if i open the same menu multiple times it might open enlarged/zoomed in a few times and a few times in its correct zoom state, seemingly on random.
Also my mouse cursor is not working in librewolf and a default one is shown. I have set
env = XDG_CURRENT_DESKTOP,Hyprland
env = XDG_SESSION_DESKTOP,Hyprland
env = XDG_SESSION_TYPE,wayland
env = SDL_VIDEODRIVER,wayland
env = CLUTTER_BACKEND,wayland
env = _JAVA_AWT_WM_NONREPARENTING,1

env = GTK_THEME,Flat-Remix-GTK-Grey-Darkest
env = XCURSOR_THEME,Bibata-Modern-Amber
env = XCURSOR_SIZE,28
env = NIXOS_OZONE_WL,1
env = MOZ_ENABLE_WAYLAND,1

env = GDK_BACKEND,wayland
#env = GDK_DEBUG,gl-fractional
#env = GDK_SCALE,2
# deaktiviert das Vergrößern des Texts
# export GDK_DPI_SCALE=0.5

env = QT_QPA_PLATFORM,wayland
env = QT_AUTO_SCREEN_SCALE_FACTOR,1
#env = QT_SCREEN_SCALE_FACTORS=2
env = QT_WAYLAND_DISABLE_WINDOWDECORATION,1

Yes, the problem is still reproducible

I found the reason for my problems: i set widget.wayland.fractional-scale.enabled to true in librewolf about:config yesterday. I just remembered and when reverting to false the problems are gone.
Sorry for the trouble.

that's a nice clue. Sway-git also supports fractional scale iirc, can you check there?

that's a nice clue. Sway-git also supports fractional scale iirc, can you check there? Fractional scale seems completely broken for me on firefox-developer-edition atm.

I'm happy with the way things are, everything is working. Just wanted to update you so that you don't follow red herrings.
Thank you for your great work!

Here's a video.
https://github.com/hyprwm/Hyprland/assets/52626363/ebf8f7f0-c319-4ae9-ab69-cfb27f1f12a8

I just compiled hyprland-git because for some reason archlinux is still version 0.30.0 and the problem seems to have gone away. I will test for a few more days and if the problem does not return, I will close the issue.

In version 0.32.3 the problem is resolved.


Not working anymore? iOS 11.3 (Safari, Chrome, Firefox)

It doesn't seem to be working anymore?
I tried it in iOS 11.3 on Safari, Chrome and Firefox. All of them have the error. The bouncing takes place.
I noticed it today. Is this something perhaps that has to do with the last iOS update?

Way to reproduce it:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Test</title>
    <meta name="Resource-type" content="Document" />

    <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>

    <script type="text/javascript">
    $(document).ready(function() {
        $('body').on('touchmove', preventBouncing);

        function preventBouncing(event){
            var e = event.originalEvent;
            console.log("prevengo....");
            //preventing the easing on iOS devices
            event.preventDefault();
        }
    });
    </script>

    <style>
        body,html{
            overflow: hidden;
            height: 100%;
            margin: 0;
        }
        .demo{
            width: 100%;
            height: 100%;
            background: blue;
        }
    </style>
</head>
<body>

<div class="demo">
</div>

</body>
</html>

Also in the index.html page you provide on the repo.

You can add {passive: false} , try like this:
document.body.addEventListener('touchmove', function(evt) {
  //In this case, the default behavior is scrolling the body, which
  //would result in an overflow.  Since we don't want that, we preventDefault.
  if(!evt._isScroller) {
    evt.preventDefault()
  }
},{passive: false})

Yeah I noticed that afterwards.
It would be nice to see this project modified. I've just added a pull request.

this issue can be closed?


ts-jest fails to import .ts modules from outside project root

Issue

ts-jest throws an error whenever a test utilizes a module from outside the project root.
ReferenceError: Unknown plugin "transform-es2015-modules-commonjs" specified in "base" at 0, attempted toresolve relative to "/home/colin/localdev/ts-jest-error/common"

      at node_modules/babel-core/lib/transformation/file/options/option-manager.js:180:17
          at Array.map (<anonymous>)

Expected behavior

TS files should be correctly imported even from outside the project.

Link to a minimal repo that reproduces this issue

https://github.com/colinskow/ts-jest-transform-error
cd main && npm install && npm test

I was able to reproduce this issue but I'm not sure if this is a bug in ts-jest.
What's happening is that when ts-jest tries to process common/index.ts, it can't find the dependencies because the context for the execution is set to the common directory.
Here are a few quick workarounds:

Create a symlink to the main/node_modules directory in either a common parent directory or in the common directory
Install the dev dependencies in either a common parent directory or in the common directory

Is  this a viable option for you?

I would expect ts-jest to behave exactly as a project that is compiled with TSC and tests run on the JS version. The tests run fine when I run build and run JS.
Should the execution context not be the cwd the command is run from instead of the directory of each file?
In my case "common" is shared by several projects, and I prefer to use the node_modules of whatever project I am building at the time. I could use symlinks as a temporary workaround but it is not ideal.

I would expect ts-jest to behave exactly as a project that is compiled with TSC and tests run on the JS version

I would too. It's just that I'm not sure what's causing this. ts-jest doesn't do anything explicitly to modify the default tsc behavior.

The tests run fine when I build and run the generated JS.

It would be very helpful if you could have this version as a branch on the linked repo. Would that be possible?

In my case "common" is shared by several projects, and I prefer to use the node_modules of whatever project I am building at the time.

I understand this use case as I do it too! I just do it the reverse way - I create symlink to the common directory in each of my project that uses it.

I updated the repo on the same branch so you can run npm run build && npm test to test the ts and JavaScript build at the same time. JS passes, TS fails.
I did some research and figured out this is a known bug in Babel which has been fixed, but since it is a breaking change will be available in Babel 7. The choices are to upgrade to<EMAIL_ADDRESS>now or wait for the stable release.

Interestingly enough, babel 7 has built-in typescript support which might make ts-jest obsolete. Let's keep this open and see what happens.

By the way, is there a specific reason that ts-jest uses Babel instead of vanilla TSC? Or was that a decision made within Jest?

We use both. Babel is not used to transpile type-script but as a postprocessing step, to handle some import stuff and e.g. hoist "jest.mock" calls.

Hi: I also meet this issue today and finally find that set "allowSyntheticDefaultImports": false, solved it for me.

@lyy011lyy Works for me too.
I also had to set moduleDirectories in my jest config to something like this:
"moduleDirectories": [
	"node_modules",
	"main/node_modules"
],

@LogansUA I think your issue is not related to this. Problem is probably with importing from .d.ts files, because it works when you rename it to index.ts

@josduj Should I create new issue? Or maybe you can suggest some way to fix it?

@colinskow updating jest and ts-jest (nmp i jest ts-jest) in your minimal repo does fix the issue

@huafu npm i jest ts-jest


I received following error in basic angular app deployment

Does this occur consistently?
Repro steps:

Action: appService.Deploy
Error type: ETIMEDOUT
Error Message: request to https://pmsdemowebapp.scm.azurewebsites.net/deployments/1cd6bf5a3d6d4b2f85c2468c5ba0231b failed, reason: connect ETIMEDOUT <IP_ADDRESS>:443
Version: 0.20.0
OS: win32
OS Release: 10.0.19042
Product: Visual Studio Code
Product Version: 1.51.1
Language: en

Call Stack
ClientRequest.<anonymous> extension.bundle.js:166:16389
ClientRequest.emit events.js:228:7
TLSSocket.socketErrorListener _http_client.js:406:9
TLSSocket.emit events.js:223:5
emitErrorNT destroy.js:92:8
emitErrorAndCloseNT destroy.js:60:3
processTicksAndRejections task_queues.js:81:21

Does this happen consistently? Sometimes trying another deploy will fix these types of errors. If that doesn't resolve it, please leave detailed repro steps.


Attribute should be case insensitive / lowercase

We should lowercase all attributes so that they are valid variable names.

I think this is done


Fix for: Bareword "GetItemTypes" not allowed

When doing a search, I was getting this error:

Software error:
Bareword "GetItemTypes" not allowed while "strict subs" in use at /var/lib/koha//plugins/Koha/Plugin/EDS/opac/eds-search.pl line 394.
Execution of /var/lib/koha//plugins/Koha/Plugin/EDS/opac/eds-search.pl aborted due to compilation errors.
For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error.

This patch should fix the problem.

Thanks @MagnusEnger, this function is no longer used 😄


Updated caption

Samyuktha PR
DONE

Created a branch
Modified the caption in the slide
Executed a pull request

TO DO

[ ]  Merge the changes to main branch
[ ]  Documentation

Merging done.


Allow tests to run against URLs not matching "nuget.org" pattern

Addresses https://github.com/NuGet/NuGetGallery/issues/3483.
When testing the staging instance before deploying the gallery, the URL being tested is some random string (dot) cloudapp (dot) .net. This URL does not match the SSL certificate so nuget.exe rejects pushing.
This change adds a custom build of nuget.exe based off of this branch:
https://github.com/NuGet/NuGet.Client/tree/dev-jver-trust-https
This nuget.exe has a feature to trust the fingerprint (a.k.a. thumbprint) of specific certificates.
In short, this PR:

Uses this custom nuget.exe for functional tests.
Removes code that was causing some P0 tests to no-op (!!!).
Fix one test that depended on a package being in the first page of search results.

As a side note, the feature request for nuget.exe supporting this certificate trust option is here:
https://github.com/NuGet/Home/issues/4387

Hi @joelverhagen, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;


How I can  get started on the approval for Amazon Music

IMPORTANT: Before you create an issue, please take a look at our Issue Reporting Guide.
Briefly summarize your issue:
I can`t play any music! my company is a product alexa-enable of screen! Wo need to test some music !
What is the expected behavior?
I say: play bye bye bye !
What behavior are you observing?
Amazon Music is not supported on this device
I have send a email to<EMAIL_ADDRESS>but haven't got any responses!
I  follow the website :https://forums.developer.amazon.com/articles/59778/launch-with-avs.html
Provide the steps to reproduce the issue, if applicable:
Tell us about your environment:

What version of the AVS Device SDK are you using?
  <x.y.z>

Tell us what hardware you're using:
a device like echo show
Tell us about your OS (Type & version):
android

Hi FengXMGeek,
I am very sorry to hear that your request has not been responded to.  I will see if I can find out why that occurred, and get that corrected.  In the mean time, please contact us privately here.
Thank you,
-SWH

@scotthea-amazon  Hi Im used android. and dont use avs sdk. can  sdk play Amzon music?

@scotthea-amazon  please tell me how can I used some music to test! Im developer a devices like echo show! Its system is android! pelase help me!!! and I want to play music just like echo show! I say "play nobody"!  It returns "Amazon Music is not supported on this device". I must use sdk to play amzon music?

Hi FengXMGeek,
Yes, the SDK can play amazon music, for commercial devices.  You will need to contact us about enabling it.  If you are interested in using the SDK on android please contact privately.  You can use this link for both requests.
Thank you,
-SWH

May I ask why was it decided to no allow music playing with the SDK on personal projects? With the low price of the echo dot, I'm sure this wouldn't undermine sales. Was there any other reason? I'm already paying for amazon prime, it would have been nice to be able to use this feature here.

@cucubits Amazon Music is not allowed on AVS personal projects due to licensing restrictions. We’re sorry for the inconvenience.


change the dark mode icons

I think the current toggle style is retro-looking and no further changes is required. The pull request #26 fixed the alignment of the toggle!


market trade history doesn't load when refreshing when logged out.

how to repro:
nav to market trading page not logged in
refresh page, notice that market trade history doesn't load

@Chwy5 need to work this in v1.13, imo

approved

i also noticed that if i am logged in on a market trading page and then i log out, then a lot of the market info disappears

fixed - closing


Drop Null Values In Json Outputs To HTTP Requests

We automatically derive Circe encoders and decoders for the case classes in our generator. While for any input to the API server, Circe will allow undefined as well as null value fields in JSON in place of optional/default values.
This is okay since both cases are valid inputs to our APIs. However, we have noticed that the end-user of the API sometimes matches on null or undefined. While we can ask our users to match on both, it's convenient to always have a single case.
This PR ensures that the optional fields with no values are not included in the output JSON. This has the added advantage of reducing the data on the wire.

We can test that the code is generated but testing the generated code is harder unless we start testing the sample projects too.
Circe can be trusted as far as this PR is concerned, but we should definitely make sample project compile with the generator too.


[GLUTEN-7860][CORE] In shuffle writer, replace MemoryMappedFile with ReadableFile to avoid OOM

What changes were proposed in this pull request?
This pr fixed https://github.com/apache/incubator-gluten/issues/7860 by replacing mmap with read to read spill file.
How was this patch tested?

cc @kecookier

@jinchengchenghh, what's the way Velox used to merge spill file?
Most efficient way should be mmap + MADV_SEQUENTIAL + manually munmap

/Benchmark Velox

/Benchmark Velox

/Benchmark Velox

I am triggering a benchmark manually.

@zhztheplayer There's no shuffle spill on jenkins.  The change won't be tested.

Is it because the spill will be triggered on other operators in the pipeline? Like a sort + shuffle. Will the sort be triggered or shuffle?

@zhztheplayer @marin-ma can we create a query and config to test it?

@FelixYBW @zhztheplayer I added MmapFileStream in this pr. MmapFileStream will invoke MADV_DONTNEED to release previous memory when reading next range of data. Test approach and result has updated in PR description.

Thank you. Looks good solution!

Is it because the spill will be triggered on other operators in the pipeline? Like a sort + shuffle. Will the sort be triggered or shuffle?

So far the spill will be triggered on components holding more memory no matter it's Velox operator or shuffle. We have a basic priority setting in Spiller API and in future we can extend and use it to implement some fixed spill order.

Is it because the spill will be triggered on other operators in the pipeline? Like a sort + shuffle. Will the sort be triggered or shuffle?

So far the spill will be triggered on components holding more memory no matter it's Velox operator or shuffle. We have a basic priority setting in Spiller API and in future we can extend and use it to implement some fixed spill order.

So now once spill is called, all operator's spill is triggered, right?

Is it because the spill will be triggered on other operators in the pipeline? Like a sort + shuffle. Will the sort be triggered or shuffle?

So far the spill will be triggered on components holding more memory no matter it's Velox operator or shuffle. We have a basic priority setting in Spiller API and in future we can extend and use it to implement some fixed spill order.

So now once spill is called, all operator's spill is triggered, right?

We pass a target spill size to Velox API so usually the spill procedure stops when enough memory space is reclaimed.

We pass a target spill size to Velox API so usually the spill call stops when enough memory space is reclaimed. So a portion of the operators can be omitted in the procedure.

Will it still call shuffle's writer's spill anyway?

can you resolve conflict?

can you resolve conflict?

Rebased to latest main.

We pass a target spill size to Velox API so usually the spill call stops when enough memory space is reclaimed. So a portion of the operators can be omitted in the procedure.

Will it still call shuffle's writer's spill anyway?

yes exactly


wideparen feature requests

I know wideparen is not supported in amsmath. It comes from package yhmath.
And mathjax has overparen which is not in amsmath either. But it's not what I imaged.
Here is overparen by mathjax

And it's wideparen by yhmath

The latter is what we use in handwrite.
So could it be possible to add wideparen in mathjax?That would be great help!
PS: I tried with adding wideparen: ['UnderOver','2322'],,  in maros config and the source js file. Both failed. '2322' is frown (oh god, I found this) which looks like `wideparen' .
Thanks for reading this.

The MathJax TeX fonts don't include the needed characters for the over parenthesis like in your screenshot.  But the STIX fonts do, so if you configure MathJax to use STIX instead of the default MathJax fonts, you will get something more like what you want.

add fonts: [["STIX",]](https://docs.mathjax.org/en/latest/options/output-processors/HTML-CSS.html#configure-html-css) , overparen is working well.
thank u


LogViewer::auth not working behind proxy

Not sure why it is the case, but when Laravel runs with Octane as reverse proxy (in production),
\LogViewer::auth(fn () => auth()->check());

does not work and always leads to a 403 error, while
\Gate::define("viewLogViewer", fn () => auth()->check());

works fine.
PHP-FPM did not have this issue. I tested if it is a remote_addr related thing, by mapping it to the real IP instead of the Docker IP (real_ip_header X-Forwarded-For;), but it didn't help.

I faced the same issue, but even with Gate, I am able to access the viewer but not see the list of log files

I faced the same issue, but even with Gate, I am able to access the viewer but not see the list of log files

Here is actually the problem I am describing, it seems to have already been fixed. I will the proposed solution a try

This might be due to configuration of the proxy. You must forward authorisation and host headers, otherwise Laravel might deny the request.
Dump your request headers in any controller, and make sure you still receive the "Authorization" header, as well as the Host is set to the same as your "APP_URL" variable, or at least the host is added to the "LOG_VIEWER_STATEFUL_DOMAINS" variable


Otakudesu not working

Steps to reproduce

Open otakudesu extension
Select the title you want to play
After that wait a while and the title will not be able to play. Almost all titles are like this

Expected behavior
Normal as usual

Actual behavior
In fact this is what happened

Crash logs
--------- beginning of system
--------- beginning of main
07-21 17:00:07.056 32358 32358 E libc    : Access denied finding property "ro.vendor.pref_scale_resolution"
07-21 17:00:07.079 32358 32358 E libc    : Access denied finding property "ro.vendor.pref_scale_resolution"
07-21 17:00:07.081 32358 32358 E libc    : Access denied finding property "ro.vendor.pref_scale_resolution"
07-21 17:00:07.159 32358 32358 E ir.tachiyomi.m: Invalid ID 0x00000000.
07-21 17:00:07.161 32358 32358 E ir.tachiyomi.m: Invalid ID 0x00000000.
App version: <IP_ADDRESS> (standard, 24c1ba6, 72, 2022-07-09T09:48Z)
Android version: 11 (SDK 30)
Android build ID: RP1A.200720.011
Device brand: Redmi
Device manufacturer: Xiaomi
Device name: merlin
Device model: M2003J15SC
Device product name: merlin_id
Aniyomi version
Aniyomi <IP_ADDRESS>
Android version
Android 11
Device
Redmi Note 9
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have tried the troubleshooting guide.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I have updated all installed extensions.
[X] I will fill out all of the requested information in this form.

To add/fix extensions, make a github issue here if it does not exist already
https://github.com/aniyomiorg/aniyomi-extensions


Can't create shortcut options with only one character

What is the current behavior?
Creating an shortcut option with only one characters makes the Yarn Importer thrown an error, without message.
Adding a second character makes the error go away
This throws an error
-> A
This is OK
-> AB
Please provide the steps to reproduce, and if possible a minimal demo of the problem:
Fresh Yarn installation via git url
What is the expected behavior?
Being able to create shortcut options with only one character
Please tell us about your environment:

Yarn Spinner Version: 1.2.7
Unity Version: 2020.1.2f1

This is now fixed, as of a recent beta!


Add Comments data structure

Summary

Test Plan

Current dependencies on/for this PR:

main

PR #4639

PR #4641   👈

PR #4642

This comment was auto-generated by Graphite.


fix links

The Jekyll template links to the company websites and GitHub accounts aren't working. The company websites appeared to just be a typo.
The GitHub links are broken because the template appears to be expecting a GitHub username. I used the following regex pattern in the company list to verify that all of the :github fields are currently URLs.
github: ((?!http))

It might make sense to convert them all over and display the usernames instead of just GitHub. For now though, this should fix the links and that could be done in a separate PR.

Looks like I was too slow with my PR and you beat me to it with #289

Dang!  Sorry @dnsbty 😞
Thank you though!


Update synced-cron across a maintainer change

The synced-cron package was stuck on an old version (1.1.0, late 2014) because when it changed maintainers, it also changed package name. The newer versions include some somewhat important bug fixes; so, upgrade.
This is a breaking change! If you're using Vulcan, you will need to replace imports of percolatestudio:synced-cron with imports of littledata:synced-cron.

Thanks! Didn't know about this change.

But actually I now just use https://www.npmjs.com/package/cron. Are there good reasons to use a Meteor package for this? I guess the ability to rely on the db to avoid running a job twice, but I don't know how useful that is…?

Yes, LW runs on multiple servers and needs to avoid running the same job twice. Or, more precisely speaking: it needs to avoid starting the same job twice simultaneously, because that risks creating lots of subtle race conditions even in things that would theoretically be idempotent.

Just to give some feedback on my experience on crons+Vulcan.
I now tend to separate cron jobs from my apps because they feel like very separate technical problem. For example, I tried to run a database backup cron, and I couldn't because the most common Meteor images won't let you install mongodump due to some issues in Debian. I ended up writing a shell script.
Also when the cron run in the Vulcan app, it may affect the app performance as far as I understand, since they "pollute" the Node thread loop (except if they run in a separate process or smth)?
Seperating crons from apps makes them annoying to write because I can't access Vulcan features, or even write them in JS (I could but that mean a more complex install and I did not find existing comprehensive solution for this).
So for example sending a newsletter would be very difficult outside of Vulcan.
Regarding the database connection, I guess we could move toward using the npm package without breaking changes, we would simply need to improve the Vulcan provided crons with the same database/race conditions functionalities.
Also just a note but when updating, we need to remove percolatestudo: version from .meteor/package, otherwise it stays active and tries to create a cronHistory collection confliting with littledata: version


DMG2305UX

Hello, I'm not finding the DMG2305UX for sale easily. Is there any other direct equivalent with the same pinout? Could you use BSS84 for example?

I selected the DMG2305UX based on the recommendation in section 4.5 of the
Pico datasheet:
"An example of a suitable P-MOSFET for most situations is Diodes DMG2305UX
which has a maximum Vt of 0.9V and
Ron of 100mΩ (at 2.5V Vgs)."
https://datasheets.raspberrypi.com/pico/pico-datasheet.pdf
On Tue, Jun 4, 2024 at 5:14 AM amazingcobrazil @.***>
wrote:

Hello, I'm not finding the DMG2305UX for sale easily. Is there any other
direct equivalent with the same pinout? Could you use BSS84 for example?
—
Reply to this email directly, view it on GitHub
https://github.com/swetland/appleii-vga/issues/1, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAXDJGHTRUBBFG7BXE6LSTZFWVR5AVCNFSM6AAAAABIYMMJOCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMZTGMZXG4ZTCOI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


feat: Select multiple resources to act on

Discussed in https://github.com/Ramilito/kubectl.nvim/discussions/433
I would love to select multiple pods and then delete all of them. Is that possible?

nice feature idea


replace hound-tools with newer RuboCop version

remove hound-tools
add fresh RuboCop config
fix offenses

Coverage remained the same at 95.547% when pulling a56f8b170b9d372dcb342ab732677ad00da2b8d7 on update_rubocop into c6b4cf633928c31a76bbebd33da92c1a00ecbd47 on master.


Improved Code and Documentation

Changelog 🎉
This PR intends to simplify the code so more customers can understand, by making the logic simpler to read and commenting every step that the script does. We make it the code with more functionality with fewer lines and fewer files, so now we have just one script file and one manifest with all the necessary permissions.
We've also removed the dependency of jq and specific bash versions, to allow even more customers to get started.
This PR additionally added support for the following:

Automatically Grant Admin Consent for App Registration.
The ability for customers to choose their App Registration name.
Update README.md to show an end-to-end example on how to run the tool.
Templates for bug reports and feature requests.

From @felipecosta09 and Tom Ryan

@felipecosta09 I have created a new branch in this upstream repo called combined. I was thinking that if you point this PR to that new branch that it could get merged into that branch which can then be collaborated on by all of us.
What do you think?

That's fine, we can do it this way...

I'm going to merge this so we can continue to work on the solution.


Placeholder opacity in FireFox

Is your feature request related to a problem? Please describe.
FireFox (latest version as of posting) has a slightly lower opacity for input placeholders. See my screenshot below. You fix this with:
I suggest adding it to reseter.css.
Describe the solution you'd like
Fix The Issue By Adding input::placeholder { opacity: 1; } to reseter.css
Additional context

Originally Publish By @starkana in sindresorhus/modern-normalize#46

Thanks For Contributing To Reseter.css. Make sure you follow our contributing guidelines. Our Maintainers Will Review Your Issue Soon! Happy Hacking!

Waiting For Some One To Grab This Good First Issue! Well if anyone is interested kindly comment here (I'll Assign It You And Only You)

I would like to work on this issue!!

Wonderful I have assigned it to you!

@all-contributors please add @starkana for bug, code