text:
Hmm, css not loading on admin site?

@johnsonkuang, are you seeing this too?

@mechanicjay

Got this when I tried to click on person (from the admin site):

@aileenzeng, pretty sure that's unrelated. Works for me. CSS still not loading on admin site though.

Just checked again. Still a problem.

I think it's a permission issue that Docker is not allowing Django to access the static files folder inside the container. I get this error locally:
Collecting static files
Copying '/code/website/static/website/css/autocomplete.css'
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", line 371, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.7/site-packages/django/core/management/__init__.py", line 365, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", line 288, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.7/site-packages/django/core/management/base.py", line 335, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python3.7/site-packages/django/contrib/staticfiles/management/commands/collectstatic.py", line 189, in handle
    collected = self.collect()
  File "/usr/local/lib/python3.7/site-packages/django/contrib/staticfiles/management/commands/collectstatic.py", line 114, in collect
    handler(path, prefixed_path, storage)
  File "/usr/local/lib/python3.7/site-packages/django/contrib/staticfiles/management/commands/collectstatic.py", line 354, in copy_file
    self.storage.save(prefixed_path, source_file)
  File "/usr/local/lib/python3.7/site-packages/django/core/files/storage.py", line 49, in save
    return self._save(name, content)
  File "/usr/local/lib/python3.7/site-packages/django/core/files/storage.py", line 236, in _save
    os.makedirs(directory)
  File "/usr/local/lib/python3.7/os.py", line 211, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "/usr/local/lib/python3.7/os.py", line 211, in makedirs
    makedirs(head, exist_ok=exist_ok)
  File "/usr/local/lib/python3.7/os.py", line 221, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/code/static'

@aileenzeng, thoughts on this.

Hmm I haven't seen this before. Maybe we could add a line in our Dockerfile to make sure we have the correct permissions. I'd imagine the line would be something like this, but I haven't really looked into it yet: RUN chown <something> /code/static

I wonder what happened to cause this problem though since things were working before. It’s not like we had to mess around with permissions in the past for this. It’s notable that we’re experiencing this problem locally as well as on the server. Hopefully, that means it’ll be easier to track down and fix and verify that we fixed it
Sent from my iPhone

On Aug 30, 2018, at 11:06 AM, Aileen Zeng notifications@github.com wrote:
Hmm I haven't seen this before. Maybe we could add a line in our Dockerfile to make sure we have the correct permissions. I'd imagine the line would be something like this, but I haven't really looked into it yet: RUN chown  /code/static
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Here's the current permissions line in our Dockerfile:
##Our local user needs write access to a place
RUN chown apache /code/website

We could change it to this instead:
##Our local user needs write access to a place
RUN chown apache /code

This works locally for me -- I don't get the permissions error anymore. (/code is our working directory, so it's the root directory of our Django project).
I don't know if this is the best solution because there's all sorts of other stuff in the root directory (database, all of our media...) and I don't know if there's a reason we're not giving apache access to those right now.

Let's change it for now (so we can try to get css to load again on admin, so we can start filling content again). And we can loop back and ask @mechanicjay once he's back from vacation.
Sound good?

This issue is fixed now.

Thanks!

authors: aileenzeng johnsonkuang jonfroehlich


text:
Matt's UbiComp DC is listed twice...

fixed!

source: gharchive/issue

repo: jonfroehlich/makeabilitylabwebsite

license: mit

license_type: permissive

license_source: bigquery


text:
Mysql Implementation

Is it possible to use it with mysql?

For now the chat available only for mongo db. But if it needed I can implement mysql, postgres in soon future.


text:
Win10 19045(22H2) BSOD

Hey! im having a bsod issue when manually mapping (or loading thru sc start). works fine in vmware, but when loading on bare metal i end up with a CLOCK_WATCHDOG_TIMEOUT. ive ensured that im using the latest branch, have vtx enabled and vt-d enabled (also tried with vt-d disabled to the same effect). my processor is a 18050k if that helps at all

https://mega.nz/file/NIRiiACQ#nCpzx6tjBxYPW65ybdzG7C4qtZUeS-AP2EQCRZ-2Zuc
here's a link to the dmp with the driver built as debug

Weird... I really have no idea what could be the cause of the issue. I'm guessing that either the timing check preventions are causing the BSOD or something related to your processor is. I might include a flag that disables the timer stuff so that we can further pinpoint this when I get home.

The thing is it seems to hang when calling vmlaunch, not sure if the timer stuff would be before that but ill manually disable timer stuff and get back to you

Got it. You'll probably need to disable this as well.

i commented that out, still got a watchdog timeout. just to ensure it wasnt my processor only having the issue i sent the driver to three of my friends (11900k, 10850k & 10700F) and they also all got watchdog bluescreens after ~1-2 seconds

You also commented out the call to hide_vm_exit_overhead() right?

This is a problem I've encountered with virtual VTS I've written myself but only with E3 E5 I54 generation processors

This BUG happened in E3, E5, I5, 4

authors: 1813245997 copilotfreetrial jonomango

repo: jonomango/hv

license: MIT

license_source: github-api


text:
chore(deps): bump dependencies

Minor dependency updates

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

source: gharchive/pull-request


text:
updated seed.command.ts to use importUtils from typeorm

Updated loadDataSource function with import file utils from typeorm github repo, supports datasource promise from file

Currently seeing the owner is working on v6, so closing this pull request

repo: jorgebodega/typeorm-seeding


text:
Add virtuoso

This is a request to add my new plugin virtuoso. This is a quite simple Fish plugin extracted from my config.fish; I've found it to be quite useful myself, and am hoping it may be of interest to others too.
Basically, it's a convenience plugin for people that use Vi-like editors, which does the following:

Depending on what's in your $PATH, it sets your $EDITOR to either nvr, nvim, vim, or vi. This is useful for people who prefer using Neovim, but want to automatically fall back to vim or vi when they ssh into a host that does not have Neovim available (but does have fish).
If you start Fish inside Neovim (using :term), or start it inside tmux, then it automatically switches $EDITOR over to nvr if available. In practice, this means that opening files in $EDITOR reuses an existing Neovim instance that is currently visible on the screen. (Either a "surrounding" nvim instance if you run Fish in :term, or one instance per tmux window if you use tmux.)
The commands edit (e), vsplit (vs), split (sp), and tabedit (tabe) should behave roughly the same way in Fish as when you run them in the (Neo)Vim command mode. This reduces the context switching between opening files from within an editor or from inside Fish. All of these commands use the autoselected $EDITOR for portability between hosts/contexts.

Thank you, @jabirali. The documentation looks great. Now consider sharing your prompt with the community, e.g., r/fishshell and if there's community interest I'll merge here.

authors: jabirali jorgebucaran

repo: jorgebucaran/awesome-fish


text:
Use a single symlink that always points to the nodejs version being used

I find that it's useful:

In places you are not in fish shell but you still need to access the nodejs bin dir. Otherwise you need to do some gymnastics with the getting the version file and constructing the path.
Places you need to hardcode a path but you still want to point to the nodejs bin you are using day to day and not update it every time you start using a new version.
A bit simpler than cleaning fish_user_paths from previous paths every time you change version

I don't mind this not being merged. Just opening for clarity.

Hey! @antitoxic Is this a breaking change?

It's not but because I've removed the fish_user_paths cleanup it will not remove the last bin for from there. I can  add it back for better compatibility. Although it will be confusing to read in the future.

@antitoxic Do you mind elaborating a bit more? What happens after I merge this? From the standpoint of a regular user, what difference does this make / what's this feature about?

@antitoxic Is this a feature or a bug fix -- both?

Note that nvm had, but removed, this feature when it became apparent that implicitly doing this simply does not work when the node version can be different across multiple shells.
If i have one tab open on node 12, and one on node 10, which is “current”?

Is this a feature or a bug fix -- both

Feature

Note that nvm had, but removed, this feature when it became apparent that implicitly doing this simply does not work when the node version can be different across multiple shells.

Ok, i don't mind not being merged. I'm going to use my fork with which I'm satisfied. Running 2 different versions of node at the same time is not a use-case for me.
Thanks.

@antitoxic You can use your fork or do whatever you want. You can't expect people to merge a random PR without understanding from the maintainer and discussing things thoroughly.
Now, fish-nvm does not seek feature parity with the original nvm project. I don't monitor nvm-sh/nvm and have really no clue how it works. I have also never used 2 different Node.js versions at the same time, so I was rather interested in having this discussion and this PR. I'm usually quite positive about merging changes that simplify my tools, even if that means breaking backward compatibility or removing features.

@jorgebucaran absolutely agree you should understand. That's the level I can explain. You didn't hint you feel favourable of the PR even once, so why should I spend more energy explaining?
That's why I closed it. Feel free to reopen.
Maybe a useful note:

@antitoxic You can use your fork or do whatever you want. You can't expect people to merge a random PR without understanding from the maintainer and discussing things thoroughly.

This sounds aggressive. No need to. You can also do whatever you want. You can't expect PRs if I don't understand you are thinking of merging or not. Doesn't that sound agressive? Let's have less of this kinda words.

Sounds like you were impatient to merge this, and since that wasn't happening promptly enough, chose to run away instead, but not after issuing your proclamation that you'd use your own fork. Do whatever you want.

@antitoxic Sounds like you were impatient to merge this, and since that wasn't happening promptly enough, chose to run away instead, but not after issuing your proclamation that you'd use your own fork. Do whatever you want.

Sounds like you were impatient to merge this, and since that wasn't happening promptly enough, chose to run away instead, but not after issuing your proclamation that you'd use your own fork. Too bad.

authors: antitoxic jorgebucaran ljharb

repo: jorgebucaran/fish-nvm


text:
Bing service completely stopped

The Bing service within the extension has completely stopped working due to the full redesign of the Copilot/bing website

Please,fix copilot in Firefox....plzzzz

@brn0zika It was fixed in Google Chrome.
I'm curious why it worked when the extension hasn't been updated!

repo: josStorer/chatGPTBox


text:
How to add odbc for sqlsrv?

How to add odbc for sqlsrv?
I recive error This extension requires the Microsoft ODBC Driver for SQL Server - php 8.2

We just provide the sqlsrv extensions but you have to install the MS ODBC driver yourself.
The MS ODBC can be installed easily in Alpine. Follow these steps.

I already know why doesn't work, I need to install a good gpg package RUN apk add gnupg. Thanks!

repo: joseluisq/alpine-php-fpm


text:
flamegraphs for java with -e alloc and --interval  don't download (Checksum does not match) error

When I run with java async-profiler cpu events - all the flamegraphs are downloaded
--tool async-profiler -e cpu -l java -o flamegraph -t 2m --interval 60s
but with java async-profiler alloc events I get an error saying Checksum does not match
--tool async-profiler -e alloc -l java -o flamegraph -t 2m --interval 60s
Default profiling tool async-profiler will be used ... ✔
Verifying target pod ... ✔
Launching profiler ... ✔
Profiling ... ✔

Checksum does not match, retrying: /tmp/agent-flamegraph-1382909.html.gz...
Checksum does not match, retrying: /tmp/agent-flamegraph-1382909.html.gz...

with alloc events, when I remove --interval 60s a single flamegraph is produced and downloaded.
looks like a timing issue, I tried changing (perfDelayBetweenJobs) but it doesnt seem to introduce a delay at all as there is no delay between the jobs timestamps. I see the sleep in the code in ./internal/agent/profiler/jvm/async_profiler.go
{"type":"log","data":{"time":"2024-02-01T19:55:57.560460874Z","level":"debug","msg":"The target filesystem is: /run/containerd/io.containerd.runtime.v2.task/k8s.io/9207e89a6d90b33dc9082d185a43c82a20c217e5b42bf42dd1dc33409829e9dc/rootfs"}}
{"type":"log","data":{"time":"2024-02-01T19:55:57.560837314Z","level":"debug","msg":"pgrep -P 3327888"}}
{"type":"log","data":{"time":"2024-02-01T19:55:57.580797179Z","level":"debug","msg":"pgrep -P 3328340"}}
{"type":"log","data":{"time":"2024-02-01T19:55:57.598762725Z","level":"debug","msg":"pgrep -P 3328373"}}
{"type":"log","data":{"time":"2024-02-01T19:55:57.615486974Z","level":"debug","msg":"The PIDs to be profiled: [3328373]"}}
{"type":"log","data":{"time":"2024-02-01T19:55:57.615520289Z","level":"debug","msg":"cp -r /app/async-profiler /tmp"}}
{"type":"log","data":{"time":"2024-02-01T19:55:57.618155249Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 60 -f /tmp/agent-flamegraph-3328373.html -e alloc --fdtransfer 3328373"}}
{"type":"log","data":{"time":"2024-02-01T19:56:57.756881691Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-3328373.html.gz"}}
{"type":"result","data":{"time":"2024-02-01T19:56:57.757942168Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-3328373.html.gz","file-size-in-bytes":28507,"checksum":"2ddf9c65b8b12630eabfc2ffd6d9d61f","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-01T19:56:57.758313068Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 60 -f /tmp/agent-flamegraph-3328373.html -e alloc --fdtransfer 3328373"}}
{"type":"log","data":{"time":"2024-02-01T19:57:57.859065758Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-3328373.html.gz"}}
{"type":"result","data":{"time":"2024-02-01T19:57:57.860134251Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-3328373.html.gz","file-size-in-bytes":27931,"checksum":"385cf11bce4a902a073427e3b521f28b","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-01T19:57:57.860312937Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 60 -f /tmp/agent-flamegraph-3328373.html -e alloc --fdtransfer 3328373"}}
{"type":"log","data":{"time":"2024-02-01T19:58:57.961279147Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-3328373.html.gz"}}
{"type":"result","data":{"time":"2024-02-01T19:58:57.962588016Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-3328373.html.gz","file-size-in-bytes":34371,"checksum":"6673e8b7ae742ee567d29eb6dcc7d77c","compressor-type":"gzip"}}
{"type":"progress","data":{"time":"2024-02-01T19:58:57.962825035Z","stage":"ended"}}
{"type":"log","data":{"time":"2024-02-01T20:03:57.976570146Z","level":"warn","msg":"Maximum allowed time 5m0s surpassed. Cleaning up and auto-deleting the agent..."}}
{"type":"log","data":{"time":"2024-02-01T20:03:57.976643458Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh stop 3328373"}}
{"type":"log","data":{"time":"2024-02-01T20:03:57.990292613Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-3328373.html"}}
{"type":"log","data":{"time":"2024-02-01T20:03:57.990424459Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-3328373.html.gz"}}

maybe if the filename had a timestamp or an interval counter rather than the same file filename agent-flamegraph-1382909.html for each interval, it would help. Also the perfRecordOutputFileName and perfScriptOutputFileName ?

Checksum error can be experienced when some problem occurs downloading/copying the result file from the remote node. Maybe caused by an unexpected network problem.
I've unable to reproduce this case. I've been able to download all flamegraphs for any event type: alloc, cpu, itmer...
By the way, checksum is not related with manner of naming the result file.

experiment this also randomly on an aws cluster , independently of option

it happens for me every time I attempt to use alloc event with an interval
in retrieveFileOrRetry() I uncommented the debug line and added in filesize
-               //fmt.Printf("\nFile %s downloaded (local: %s | remote: %s)", remoteFile.FileName, checksum, remoteFile.Checksum)
+               fmt.Printf("\nFile %s downloaded (local: %s (%d bytes)| remote: %s (%d bytes))", remoteFile.FileName, checksum, len(fileBuff), remoteFile.Checksum, remoteFile.FileSizeInBytes)

File /tmp/agent-flamegraph-3328373.html.gz downloaded (local: 11678d5b6297b6e76b5b4eae90bdfda3 (36022 bytes)| remote: b032cfd534cb8a30e6a3c93eba2377a0 (36023 bytes))
Checksum does not match, retrying: /tmp/agent-flamegraph-3328373.html.gz...
File /tmp/agent-flamegraph-3328373.html.gz downloaded (local: 2fc118d516590948fbe14bd007fe79fa (72045 bytes)| remote: b032cfd534cb8a30e6a3c93eba2377a0 (36023 bytes))
Checksum does not match, retrying: /tmp/agent-flamegraph-3328373.html.gz...
File /tmp/agent-flamegraph-3328373.html.gz downloaded (local: e1d78beba971b5a7fe467d9365518b6d (108065 bytes)| remote: b032cfd534cb8a30e6a3c93eba2377a0 (36023 bytes))
Checksum does not match, retrying: /tmp/agent-flamegraph-3328373.html.gz...
File /tmp/agent-flamegraph-3328373.html.gz downloaded (local: a69629fbaea4c7f97934355cbd8ba4c6 (144087 bytes)| remote: b032cfd534cb8a30e6a3c93eba2377a0 (36023 bytes))
Checksum does not match, retrying: /tmp/agent-flamegraph-3328373.html.gz...❌
checksum does not match for file /tmp/agent-flamegraph-3328373.html.gz

and
type":"log","data":{"time":"2024-02-07T17:39:47.27282818Z","level":"debug","msg":"{\"Duration\":120000000000,\"Interval\":60000000000,\"UID\":\"e90460c6-a326-4a6b-bdfe-3b3bd0f8156f\",\"ContainerRuntime\":\"containerd\",\"ContainerRuntimePath\":\"/run/containerd\",\"ContainerID\":\"9207e89a6d90b33dc9082d185a43c82a20c217e5b42bf42dd1dc33409829e9dc\",\"PodUID\":\"f680eeab-f22b-4d8a-ae13-c3f76e8d85bd\",\"Language\":\"java\",\"Event\":\"alloc\",\"Compressor\":\"gzip\",\"Tool\":\"async-profiler\",\"OutputType\":\"flamegraph\",\"FileName\":\"\",\"HeapDumpSplitInChunkSize\":\"\",\"PID\":\"\",\"Pgrep\":\"\",\"AdditionalArguments\":null}"}}
{"type":"progress","data":{"time":"2024-02-07T17:39:47.27301402Z","stage":"started"}}
{"type":"log","data":{"time":"2024-02-07T17:39:47.273063807Z","level":"debug","msg":"The target filesystem is: /run/containerd/io.containerd.runtime.v2.task/k8s.io/9207e89a6d90b33dc9082d185a43c82a20c217e5b42bf42dd1dc33409829e9dc/rootfs"}}
{"type":"log","data":{"time":"2024-02-07T17:39:47.273335554Z","level":"debug","msg":"pgrep -P 3327888"}}
{"type":"log","data":{"time":"2024-02-07T17:39:47.296582217Z","level":"debug","msg":"pgrep -P 3328340"}}
{"type":"log","data":{"time":"2024-02-07T17:39:47.315742591Z","level":"debug","msg":"pgrep -P 3328373"}}
{"type":"log","data":{"time":"2024-02-07T17:39:47.384352887Z","level":"debug","msg":"The PIDs to be profiled: [3328373]"}}
{"type":"log","data":{"time":"2024-02-07T17:39:47.384379558Z","level":"debug","msg":"cp -r /app/async-profiler /tmp"}}
{"type":"log","data":{"time":"2024-02-07T17:39:47.390612301Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 60 -f /tmp/agent-flamegraph-3328373.html -e alloc --fdtransfer 3328373"}}
{"type":"log","data":{"time":"2024-02-07T17:40:47.463519037Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-3328373.html.gz"}}
{"type":"result","data":{"time":"2024-02-07T17:40:47.464583752Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-3328373.html.gz","file-size-in-bytes":36023,"checksum":"b032cfd534cb8a30e6a3c93eba2377a0","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-07T17:40:47.464847254Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 60 -f /tmp/agent-flamegraph-3328373.html -e alloc --fdtransfer 3328373"}}
{"type":"log","data":{"time":"2024-02-07T17:41:47.54847511Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-3328373.html.gz"}}
{"type":"result","data":{"time":"2024-02-07T17:41:47.549306282Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-3328373.html.gz","file-size-in-bytes":37935,"checksum":"7e9250b19d19ecf0cccec70016ab6e7c","compressor-type":"gzip"}}
{"type":"progress","data":{"time":"2024-02-07T17:41:47.549448578Z","stage":"ended"}}
{"type":"log","data":{"time":"2024-02-07T17:41:52.558181028Z","level":"debug","msg":"Received signal: terminated"}}
{"type":"log","data":{"time":"2024-02-07T17:41:52.558215876Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh stop 3328373"}}
{"type":"log","data":{"time":"2024-02-07T17:41:52.579639461Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-3328373.html"}}
{"type":"log","data":{"time":"2024-02-07T17:41:52.579771066Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-3328373.html.gz"}}
{"type":"log","data":{"time":"2024-02-07T17:41:52.579909625Z","level":"debug","msg":"Profiling finished properly. Bye!"}}

So I see a few problems

the file downloaded is 1 byte too short. What is the reason for the n += out.Len() + 1 each time?
for each target.RetrieveFileRetries the fileBuff is not cleared and the buffer is accumulating.

I'll check it again. Seems you're right

The only way I can see it worked for you, is if you downloaded the files with a single call to the loop with tail command in retrieveFileOrRetry().
Also the files do get overwritten - due to having the same name each time, so if they are been downloaded slower in chunks, a new file (same name, with different data and different checksum) overwrites the previous one, and the tail command is downloading from this new file - so the contents of the file downloaded will never match up and neither will checksum == remoteFile.Checksum

There was a problem calculating the offset of the remaining file to download when it couldn't be downloaded all at once. I'm going to publish a new release 1.2.1 which fix this one.

I have pulled the latest changes but I still have the same underlying issue as described in the ticket.
which is caused by having the same filenames e.g. /tmp/agent-flamegraph-3328373.html for each interval and the files get overwritten with the output for the next interval.
Notice the download for the first file failing and the 3 retries for the first file have the same file size and checksum for the 2nd file 47460 bytes and checksum "7ec5eb445db99e1abe5352b48d6e3806" because the first output was overwritten by the 2nd output with filename /tmp/agent-flamegraph-3328373.html.
File /tmp/agent-flamegraph-3328373.html.gz downloaded (local: b92a264e90f5b87044fab8ab7fe7da28 (47444 bytes) | remote: bf98cfe0ada19dfd919d09d48a91ef07 (34041 bytes))
Checksum does not match, retrying: /tmp/agent-flamegraph-3328373.html.gz...
File /tmp/agent-flamegraph-3328373.html.gz downloaded (local: 7ec5eb445db99e1abe5352b48d6e3806 (47460 bytes) | remote: bf98cfe0ada19dfd919d09d48a91ef07 (34041 bytes))
Checksum does not match, retrying: /tmp/agent-flamegraph-3328373.html.gz...
File /tmp/agent-flamegraph-3328373.html.gz downloaded (local: 7ec5eb445db99e1abe5352b48d6e3806 (47460 bytes) | remote: bf98cfe0ada19dfd919d09d48a91ef07 (34041 bytes))
Checksum does not match, retrying: /tmp/agent-flamegraph-3328373.html.gz...
File /tmp/agent-flamegraph-3328373.html.gz downloaded (local: 7ec5eb445db99e1abe5352b48d6e3806 (47460 bytes) | remote: bf98cfe0ada19dfd919d09d48a91ef07 (34041 bytes))
Checksum does not match, retrying: /tmp/agent-flamegraph-3328373.html.gz...❌
checksum does not match for file /tmp/agent-flamegraph-3328373.html.gz

File /tmp/agent-flamegraph-3328373.html.gz downloaded (local: 7ec5eb445db99e1abe5352b48d6e3806 (47460 bytes) | remote: 7ec5eb445db99e1abe5352b48d6e3806 (47460 bytes))
Remote profiling file downloaded in 3.520464 seconds. ✔
The profiling result file [agent-flamegraph-3328373-2024-02-08T17_41_31Z.html] was obtained in 137.597947 seconds.

{"type":"log","data":{"time":"2024-02-08T17:39:30.91778076Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 60 -f /tmp/agent-flamegraph-3328373.html -e alloc --fdtransfer 3328373"}}
{"type":"log","data":{"time":"2024-02-08T17:40:31.049361339Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-3328373.html.gz"}}
{"type":"result","data":{"time":"2024-02-08T17:40:31.050328465Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-3328373.html.gz","file-size-in-bytes":34041,"checksum":"bf98cfe0ada19dfd919d09d48a91ef07","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-08T17:40:31.050601405Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 60 -f /tmp/agent-flamegraph-3328373.html -e alloc --fdtransfer 3328373"}}
{"type":"log","data":{"time":"2024-02-08T17:41:31.144286931Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-3328373.html.gz"}}
{"type":"result","data":{"time":"2024-02-08T17:41:31.145361315Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-3328373.html.gz","file-size-in-bytes":47460,"checksum":"7ec5eb445db99e1abe5352b48d6e3806","compressor-type":"gzip"}}
{"type":"progress","data":{"time":"2024-02-08T17:41:31.145509373Z","stage":"ended"}}
{"type":"log","data":{"time":"2024-02-08T17:41:50.355762225Z","level":"debug","msg":"Received signal: terminated"}}
{"type":"log","data":{"time":"2024-02-08T17:41:50.355802413Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh stop 3328373"}}
{"type":"log","data":{"time":"2024-02-08T17:41:50.384676912Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-3328373.html"}}
{"type":"log","data":{"time":"2024-02-08T17:41:50.384779901Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-3328373.html.gz"}}
{"type":"log","data":{"time":"2024-02-08T17:41:50.38489262Z","level":"debug","msg":"Profiling finished properly. Bye!"}}

Ok. The problem is with the continuous mode. I got it. The file should be renamed according the iteration.

Hi, @jlynch1. Now, for continuous mode the result file is renamed after each iteration. It should resolve the issue experienced by you. Release: https://github.com/josepdcs/kubectl-prof/releases/tag/1.2.2
Default profiling tool async-profiler will be used ... ✔
Verifying target pod ... ✔
Launching profiler ... ✔
Profiling ... ✔
⚠Detected more than one PID to profile: [2737 2738]. It will be attempt to profile all of them. Use the --pid flag specifying the corresponding PID if you only want to profile one of them.
Profiling ... ✔
Remote profiling file downloaded in 0.137480 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2737-1-2024-02-10T12_32_24Z.html] was obtained in 8.954445 seconds. 🔥
Remote profiling file downloaded in 0.132550 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2738-1-2024-02-10T12_32_26Z.html] was obtained in 10.931881 seconds. 🔥
Remote profiling file downloaded in 0.122825 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2737-2-2024-02-10T12_32_36Z.html] was obtained in 21.000285 seconds. 🔥
Remote profiling file downloaded in 0.099868 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2738-2-2024-02-10T12_32_38Z.html] was obtained in 22.954586 seconds. 🔥
Remote profiling file downloaded in 0.101791 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2737-3-2024-02-10T12_32_48Z.html] was obtained in 33.056469 seconds. 🔥
Remote profiling file downloaded in 0.111962 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2738-3-2024-02-10T12_32_50Z.html] was obtained in 35.015531 seconds. 🔥
Remote profiling file downloaded in 0.143081 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2737-4-2024-02-10T12_33_00Z.html] was obtained in 45.084805 seconds. 🔥
Remote profiling file downloaded in 0.086301 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2738-4-2024-02-10T12_33_02Z.html] was obtained in 47.103090 seconds. 🔥
Remote profiling file downloaded in 0.149004 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2737-5-2024-02-10T12_33_12Z.html] was obtained in 57.280298 seconds. 🔥
Remote profiling file downloaded in 0.194645 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2738-5-2024-02-10T12_33_14Z.html] was obtained in 59.319846 seconds. 🔥
Remote profiling file downloaded in 0.122635 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2737-6-2024-02-10T12_33_24Z.html] was obtained in 69.356782 seconds. 🔥
Remote profiling file downloaded in 0.125325 seconds. ✔
The profiling result file [/home/josepdcs/tmp/k-prof/agent-flamegraph-2738-6-2024-02-10T12_33_26Z.html] was obtained in 71.343668 seconds. 🔥

The agent logs:
{"type":"notice","data":{"time":"2024-02-10T12:32:14.48979419Z","msg":"Detected more than one PID to profile: [2737 2738]. It will be attempt to profile all of them. Use the --pid flag specifying the corresponding PID if you only want to profile one of them."}}
{"type":"log","data":{"time":"2024-02-10T12:32:14.489957799Z","level":"debug","msg":"The PIDs to be profiled: [2737 2738]"}}
{"type":"log","data":{"time":"2024-02-10T12:32:14.489968979Z","level":"debug","msg":"cp -r /app/async-profiler /tmp"}}
{"type":"log","data":{"time":"2024-02-10T12:32:14.492197107Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2737-1.html -e alloc --fdtransfer 2737"}}
{"type":"log","data":{"time":"2024-02-10T12:32:16.49441983Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2738-1.html -e alloc --fdtransfer 2738"}}
{"type":"log","data":{"time":"2024-02-10T12:32:24.528072629Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2737-1.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:32:24.539385288Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2737-1.html.gz","file-size-in-bytes":3076,"checksum":"f53920b5bd81ef10234746b432bed775","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:32:26.518939778Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2738-1.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:32:26.522493738Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2738-1.html.gz","file-size-in-bytes":3218,"checksum":"ce70ecf8952a954321dd011aa0c46222","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:32:26.527058575Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2737-2.html -e alloc --fdtransfer 2737"}}
{"type":"log","data":{"time":"2024-02-10T12:32:28.549467094Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2738-2.html -e alloc --fdtransfer 2738"}}
{"type":"log","data":{"time":"2024-02-10T12:32:36.596948528Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2737-2.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:32:36.599764961Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2737-2.html.gz","file-size-in-bytes":3185,"checksum":"ccc87dcf06a25b7277acac65034da77a","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:32:38.57433443Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2738-2.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:32:38.577940702Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2738-2.html.gz","file-size-in-bytes":3185,"checksum":"ccc87dcf06a25b7277acac65034da77a","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:32:38.580316165Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2737-3.html -e alloc --fdtransfer 2737"}}
{"type":"log","data":{"time":"2024-02-10T12:32:40.594551181Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2738-3.html -e alloc --fdtransfer 2738"}}
{"type":"log","data":{"time":"2024-02-10T12:32:48.674746878Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2737-3.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:32:48.67783395Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2737-3.html.gz","file-size-in-bytes":3166,"checksum":"5c37d8aae7d291840b8c119c9eb0f494","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:32:50.623320299Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2738-3.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:32:50.626918772Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2738-3.html.gz","file-size-in-bytes":3118,"checksum":"c53dd29e105b836fb698decacc626aa5","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:32:50.628412168Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2737-4.html -e alloc --fdtransfer 2737"}}
{"type":"log","data":{"time":"2024-02-10T12:32:52.651552765Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2738-4.html -e alloc --fdtransfer 2738"}}
{"type":"log","data":{"time":"2024-02-10T12:33:00.660429899Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2737-4.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:33:00.664559186Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2737-4.html.gz","file-size-in-bytes":3253,"checksum":"75a240f19803150475b484165d70297a","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:33:02.737658938Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2738-4.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:33:02.740126511Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2738-4.html.gz","file-size-in-bytes":3195,"checksum":"5de9ab43240b91e7cdd0485b8d5a230d","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:33:02.743609828Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2737-5.html -e alloc --fdtransfer 2737"}}
{"type":"log","data":{"time":"2024-02-10T12:33:04.766144545Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2738-5.html -e alloc --fdtransfer 2738"}}
{"type":"log","data":{"time":"2024-02-10T12:33:12.84812847Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2737-5.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:33:12.853989111Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2737-5.html.gz","file-size-in-bytes":3184,"checksum":"3065ab4aa8efe399ca5d27d8e4a0fe04","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:33:14.835274652Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2738-5.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:33:14.847132353Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2738-5.html.gz","file-size-in-bytes":3208,"checksum":"2ae11334dec8c20bce1f9f2eb15fe977","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:33:14.860894343Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2737-6.html -e alloc --fdtransfer 2737"}}
{"type":"log","data":{"time":"2024-02-10T12:33:16.875963017Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh -o flamegraph -d 10 -f /tmp/agent-flamegraph-2738-6.html -e alloc --fdtransfer 2738"}}
{"type":"log","data":{"time":"2024-02-10T12:33:24.947702205Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2737-6.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:33:24.957726514Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2737-6.html.gz","file-size-in-bytes":3202,"checksum":"1c55274763d3a007def56a41732f39db","compressor-type":"gzip"}}
{"type":"log","data":{"time":"2024-02-10T12:33:26.936852816Z","level":"debug","msg":"stat -c%s /tmp/agent-flamegraph-2738-6.html.gz"}}
{"type":"result","data":{"time":"2024-02-10T12:33:26.941434454Z","result-type":"flamegraph","file":"/tmp/agent-flamegraph-2738-6.html.gz","file-size-in-bytes":3239,"checksum":"02e6ea273dd403ff15fe55bdea107282","compressor-type":"gzip"}}
{"type":"progress","data":{"time":"2024-02-10T12:33:26.941530821Z","stage":"ended"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.132676216Z","level":"debug","msg":"Received signal: terminated"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.132727844Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh stop 2737"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.175661715Z","level":"debug","msg":"/tmp/async-profiler/profiler.sh stop 2738"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.267339459Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-1.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.2675347Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-1.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.267589655Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-2.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.267686007Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-2.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.267737353Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-3.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.267829135Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-3.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.267871652Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-4.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.267907182Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-4.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.267939422Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-5.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.267978649Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-5.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268011715Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-6.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268046987Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2737-6.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268097433Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-1.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268448036Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-1.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268562686Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-2.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268603807Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-2.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268639829Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-3.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268686509Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-3.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268730626Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-4.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268824059Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-4.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.268867889Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-5.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.269103104Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-5.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.269617293Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-6.html"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.269771517Z","level":"debug","msg":"Trying to remove file: /tmp/agent-flamegraph-2738-6.html.gz"}}
{"type":"log","data":{"time":"2024-02-10T12:33:27.271571119Z","level":"debug","msg":"Profiling finished properly. Bye!"}}

Hi @josepdcs, I can confirm it is now downloading correctly the flamegraphs for me in normal and continuous mode. Thanks for all your work in maintaining this project.

authors: jlynch1 josepdcs killbulle

repo: josepdcs/kubectl-prof


text:
Non-roundtrip push to josh branch when a commit has a . as the last character of the author name

The commit https://github.com/rust-lang/rust-analyzer/commit/5af51fa47610d0f88dcab99aaaff2ee4fca17c00 does not properly round-trip through a push to josh.
Original commit info (git show --format=raw):
commit 5af51fa47610d0f88dcab99aaaff2ee4fca17c00
tree 5cf661188e20157ffab5d742ce22d5fa44d18bd1
parent 4a91453409aaf58eba0a91e4b62a35f49814b394
author Winston H. <56998716+winstxnhdw@users.noreply.github.com> 1721814140 +0100
committer GitHub <noreply@github.com> 1721814140 +0100

After a round-trip through josh:
commit fc919994d0759bca7423444e0d0bc044df80359a
tree 5cf661188e20157ffab5d742ce22d5fa44d18bd1
parent 4a91453409aaf58eba0a91e4b62a35f49814b394
author Winston H <56998716+winstxnhdw@users.noreply.github.com> 1721814140 +0100
committer GitHub <noreply@github.com> 1721814140 +0100

The . after Winston H went missing. Seems like somewhere josh is normalizing usernames and doesn't like the trailing .?

Seems like git used to prevent a . from even existing at the end of a username, but this got changed last year. So probably whatever git library josh is using needs to get the same kind of update?

This change was mirrored in libgit2 via https://github.com/libgit2/libgit2/commit/cf320cc125e589a4de109de9098d54098f03b31b, which was included in libgit2 1.8. That needs version 0.19 of the git2 Rust crate.

repo: josh-project/josh


text:
Linting should not check anything past the git cleanup scissors marker

When using a prepare-commit-msg hook to duplicate the logic of git commit --verbose, The initial commit message will contain a commit diff after a special marker of # ------------------------ >8 ------------------------, which is stripped out of the commit message.
The extension should also honor this cleanup and ignore anything past this line.
How to reproduce:

Stage a git change.
In vscode, Click commit with empty message to bring up the commit msg in an editor
Paste in this content.

feat(core): add a thing

# On branch mybranch
# Your branch is ahead of 'origin/main' by 3 commits.
#   (use "git push" to publish your local commits)
#
# Changes to be committed:
#   (use "git restore --staged <file>..." to unstage)
#       modified:   packages/mypackage/lib/naming.ts
#
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.

This is a very long line that would fail commitlint if it were part of the body xxxxxxxxxxxxxxxxxxxxxx

Extension will report the last line failing commit lint because it is over 100 characters

Ref: https://git-scm.com/docs/git-commit#Documentation/git-commit.txt-scissors

One way to reproduce this easily is to set the gitconfig option:
git config --global commit.verbose true

This results in a commit message with a unified diff below the scissor marker:

authors: idwagner rcdailey

repo: joshbolduc/vscode-commitlint


text:
archivesBaseName should not contain a space character.

The archivesBaseName in build.gradle is later used to generate the .jar files, etc. Eventually, to make it easy for others to build against this library, you'll want to publish it to Maven. According to the Maven naming guidlines, you'll want only alpha-numeric numbers in those file names.
I have been helping people with builds and maven for a bit, and spaces and special characters cause all sorts of bothersom problems with the Java toolchain. Please rename it to "enchiridion2" or "Enchiridion2" without spaces.
You can safely use a more human readable name with spaces in the name field of the mcmod.info, and that's what will be displayed in info screens.

I have no intention to ever use maven.

Ok.
I hope you'll reconsider. You're already benefitting from Maven for your build environment, and it would be really great if you would use the same tools. I'm in the process of writing a tutorial on publishing with Maven on GitHub Pages, and having Enchiridion available to use with a 1-line change to build.gradle would be awesome.

authors: joshiejack kylev

repo: joshiejack/Enchiridion


text:
Better syntax highlighting for JavaScript

I’m slinging a ton of JavaScript these days and I feel like my current color scheme and/or syntax file is falling short. Most of the file is the generic text color (white) and it’s just a bore to look at. Same deal with handlebars templates, I’ve tried some stuff and nothing has really worked that well.

Switched back to jellybeans and I think everything is looking great. Fixed issues with handlebars and dust templates. Closing

repo: joshtronic/dotfiles

license: WTFPL


text:
update to bevy 0.5

Update dependencies to eliminate lib duplicates.

Thanks, there needs to be a bit more fixes though involved to get clippy and others to pass though :)

Actually, this might be an issue with a new clippy nightly lint and totally unrelated.

authors: joshuajbouw solarsail


text:
[BUG] Failed to send registration request subsystem=hass error="code : Unavailable"

Go Hass Agent Version
Go Hass Agent: v10.1.0
Describe the bug
I just set up a new Linux distro on a machine that was running Go Hass Agent previously (KDE Neon -> Bazzite, based on Fedora Kinoite).
Kinoite/Bazzite is an immutable distribution, but you can layer in packages using rpm-ostree, so I set up the latest Go Hass Agent that way.
Everything seemed to work okay for several reboots. I was able to see my sensors as expected within Home Assistant on the new distro, and they all updated as I would expect.
Then after a while I noticed that Go Hass Agent wasn't reporting any sensors. I believe it started after I changed my hostname, but I can't actually be sure.
Checking the logs, I saw:
Unable to retrieve sensors. worker=abrt_problems_sensor worker_type=polling error="unable to retrieve the list of ABRT problems: SystemBus: unable to get data org.freedesktop.problems.GetProblems from org.freedesktop.problems: The name is not activatable"
Followed by a bunch of spam in the format:
Sensor not found in registry. sensor_id:<Sensor ID here>
Process sensor failed. error="failed to send sensor update request: code <nil>: Unavailable"
Process sensor failed. error="%!v(PANIC=Error method: runtime error: invalid memory address or nil pointer dereference)"
Rinse and repeat.
If I move .config/go-hass-agent to .config/go-hass-agent-bak and try to redo setup from a "fresh start", I am able to register okay (Sep  1 15:09:04.760 INFO Agent registered.), and I see the machine in Home Assistant - but trying to run it gives the same issue.
I get the same result whether I run via GUI or via terminal. I did notice that sensorRegistry is empty except for sensor.reg which is 0 bytes. Trying the backed-up sensor.reg doesn't resolve the issue.
I'm a little mystified as to what could be causing this behavior.  I'm going to try an older build and see if the issues persist there, but wanted to raise this for now.
To Reproduce
Steps to reproduce the behaviour:

Install Bazzite (might be able to reproduce on Kinoite)
Install + register go-hass-agent
Change machine hostname??
Notice sensors aren't working

Expected behaviour
Go-Hass-Agent runs without issue
Screenshots

Logs
agent.log
go-hass-agent.zip
(While I have made efforts to not log sensitive information, please check the log before uploading to GitHub and remove any information you do not want to share).
Desktop (please complete the following information):

OS: Linux
Distribution: Bazzite (Fedora Kinoite fork)
Version: 3.7.0

Additional context
I've also tried the container approach, although that doesn't seem to work for a different reason:
jay@Bomu-Bazzite:~$ podman run --rm --hostname go-hass-agent-container   --network host   --volume go-hass-agent:/home/ubuntu   ghcr.io/joshuar/go-hass-agent register   --server http://192.168.86.223:8123   --token <snip>
2024/09/01 22:41:37 ERROR go-hass-agent should not be run with additional privileges or as root.

Although that seems to be a different bug altogether :)
Thanks!

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

Hey there, thanks for trying out Go Hass Agent! That's no good that it isn't working, this is odd!
Can you try the following:

Stop Go Hass Agent.
Remove ~/.config/go-hass-agent.
In Home Assistant, go to Settings->Devices & Services->Mobile App and locate the Go Hass Agent entry for your machine (it should be the same as the current hostname).
Click the three dots at the right of the entry and choose Delete.
Back on your machine, re-register Go Hass Agent.

Let me know how the above steps work out.
This is an interesting problem. The hostname change shouldn't stop Go Hass Agent from working correctly. But it will likely result in multiple entries in the Mobile App integration in Home Assistant (Step 3 above), or a doubling up of sensor entities in a single entry (with the new sensors prefixed with the new hostname that report values and old sensors with the old hostname no longer reporting values).
Its very odd for Go Hass Agent to successfully register but then not write anything to its local registry (the sensor.reg file) without reporting errors. But before digging in on that, I am curious about the results of the steps above for resetting the agent locally and in Home Assistant then re-registering.
Thanks also for reporting that issue with the container images. It looks like I need to make some changes after the recent releases for the container builds!

Hi, yes, hello!
I tried that earlier - it's the same result. Completely clearing the entire Mobile App device and redoing everything from scratch didn't seem to affect anything.
Full console:
jay@Bomu-Bazzite:~$ go-hass-agent version
Go Hass Agent: v10.1.0
jay@Bomu-Bazzite:~$ go-hass-agent register --token <snip> --server http://192.168.86.223:8123 --log-level debug
Sep  3 12:53:48.351 DEBUG Setting language. lang=[en-US]
Sep  3 12:53:48.715 INFO Agent registered.
jay@Bomu-Bazzite:~$ go-hass-agent run
Sep  3 12:54:38.222 DEBUG Setting language. lang=[en-US]
Sep  3 12:54:38.222 DEBUG Read sensor registry from disk. file=sensor.reg
Sep  3 12:54:38.225 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor location updates: unsupported hardware"
Sep  3 12:54:38.225 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor laptop sensors: unsupported hardware"
Sep  3 12:54:38.225 DEBUG Processing sensor updates.
Sep  3 12:54:38.226 WARN Sensor not found in registry. sensor_id=agent_version
Sep  3 12:54:38.226 WARN Sensor not found in registry. sensor_id=agent_version
Sep  3 12:54:38.226 WARN Unable to retrieve sensors. worker=abrt_problems_sensor worker_type=polling error="unable to retrieve the list of ABRT problems: SystemBus: unable to get data org.freedesktop.problems.GetProblems from org.freedesktop.problems: The name is not activatable"
Sep  3 12:54:38.226 WARN Sensor not found in registry. sensor_id=memory_free
Sep  3 12:54:38.226 WARN Sensor not found in registry. sensor_id=memory_corrupted
Sep  3 12:54:38.226 WARN Sensor not found in registry. sensor_id=memory_corrupted
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=memory_buffered
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=memory_buffered
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=memory_cached
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=memory_cached
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=memory_free
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=swap_total
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=swap_total
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=zram0_disk_reads
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=zram0_disk_reads
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=swap_cached
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=swap_cached
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=zram0_disk_write_rate
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=zram0_disk_write_rate
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=swap_free
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=swap_free
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=core_0_cpu_usage
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=core_0_cpu_usage
Sep  3 12:54:38.227 WARN Sensor not found in registry. sensor_id=cpufreq_core1_frequency
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=core_4_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=core_6_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=core_6_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=cpufreq_core10_frequency
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=cpufreq_core10_frequency
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=processes_blocked
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=processes_blocked
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=core_11_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=core_11_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=total_processes_created
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=total_processes_created
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=core_2_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=core_2_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=core_9_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=core_9_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=total_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=total_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=core_4_cpu_usage
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=cpufreq_core2_frequency
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=cpufreq_core2_frequency
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=zram0_disk_writes
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=zram0_disk_writes
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=zram0_disk_read_rate
Sep  3 12:54:38.228 WARN Sensor not found in registry. sensor_id=zram0_disk_read_rate
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=core_1_cpu_usage
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=core_1_cpu_usage
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core0_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core0_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=core_3_cpu_usage
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core3_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core4_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=core_5_cpu_usage
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core5_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core6_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=core_7_cpu_usage
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core7_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=core_8_cpu_usage
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core8_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=core_10_cpu_usage
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core9_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=total_cpu_context_switches
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core11_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=processes_running
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=processes_running
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core1_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=core_3_cpu_usage
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core3_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core4_frequency
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=core_5_cpu_usage
Sep  3 12:54:38.229 WARN Sensor not found in registry. sensor_id=cpufreq_core5_frequency
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=cpufreq_core6_frequency
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=core_7_cpu_usage
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=cpufreq_core7_frequency
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=core_8_cpu_usage
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=cpufreq_core8_frequency
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=core_10_cpu_usage
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=enp_9_s_0_connection_state
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=enp_9_s_0_connection_state
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=cpufreq_core9_frequency
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=lo_connection_state
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=lo_connection_state
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=total_cpu_context_switches
Sep  3 12:54:38.230 WARN Sensor not found in registry. sensor_id=cpufreq_core11_frequency
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_sysroot
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_sysroot
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_sysroot_ostree_deploy_default_var
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_sysroot_ostree_deploy_default_var
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_run_media_jay_Data
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_run_media_jay_Data
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_usr
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_usr
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_run
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_run
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_var_home
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_var_home
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_dev_shm
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_dev_shm
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_var
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_var
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_etc
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_etc
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_boot
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_boot
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_tmp
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_tmp
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_var_home_jay_.steam
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_var_home_jay_.steam
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_run_user_1000
Sep  3 12:54:38.233 WARN Sensor not found in registry. sensor_id=mountpoint_run_user_1000
Sep  3 12:54:38.234 WARN Sensor not found in registry. sensor_id=mountpoint_run_media_jay_Server
Sep  3 12:54:38.234 WARN Sensor not found in registry. sensor_id=mountpoint_run_media_jay_Server
Sep  3 12:54:38.234 WARN Sensor not found in registry. sensor_id=mountpoint_run_media_jay_HomeAssistant
Sep  3 12:54:38.234 WARN Sensor not found in registry. sensor_id=mountpoint_run_media_jay_HomeAssistant
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_3
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_3
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_5
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_5
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_2
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_2
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_4
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_4
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_7
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_7
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_1
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_1
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_6
Sep  3 12:54:38.238 WARN Sensor not found in registry. sensor_id=hwmon_4_zenergy_energy_6
Sep  3 12:54:38.651 ERROR Process sensor failed. error="%!v(PANIC=Error method: runtime error: invalid memory address or nil pointer dereference)"
...
Sep  3 12:54:43.348 ERROR Process sensor failed. error="%!v(PANIC=Error method: runtime error: invalid memory address or nil pointer dereference)"
^CSep  3 12:54:44.524 WARN Websocket connection closed with error. error="gws: close normal"

Once I was writing this message, I realized that I didn't have the actual log file for you. I tried that one more time just to make sure that I didn't miss anything in the logs during the registration step (I didn't)... but then...
Sep  3 12:58:48.351 DEBUG Setting language. lang=[en-US]
Sep  3 12:58:48.715 INFO Agent registered.
jay@Bomu-Bazzite:~$ go-hass-agent run
Sep  3 13:01:06.955 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor location updates: unsupported hardware"
Sep  3 13:01:06.955 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor laptop sensors: unsupported hardware"
Sep  3 13:01:06.956 WARN Sensor not found in registry. sensor_id=agent_version
Sep  3 13:01:06.956 WARN Sensor not found in registry. sensor_id=agent_version
Sep  3 13:01:06.956 WARN Sensor not found in registry. sensor_id=uptime
Sep  3 13:01:06.956 WARN Sensor not found in registry. sensor_id=uptime
Sep  3 13:01:06.956 WARN Sensor not found in registry. sensor_id=distribution_name
Sep  3 13:01:06.956 WARN Sensor not found in registry. sensor_id=distribution_name
Sep  3 13:01:06.956 WARN Sensor not found in registry. sensor_id=distribution_version
Sep  3 13:01:06.956 WARN Sensor not found in registry. sensor_id=distribution_version
Sep  3 13:01:06.957 WARN Sensor not found in registry. sensor_id=cpu_load_average_(1_min)
Sep  3 13:01:06.957 WARN Sensor not found in registry. sensor_id=cpu_load_average_(1_min)
Sep  3 13:01:06.957 WARN Sensor not found in registry. sensor_id=bytes_received
Sep  3 13:01:06.957 WARN Sensor not found in registry. sensor_id=bytes_received
Sep  3 13:01:06.957 WARN Sensor not found in registry. sensor_id=last_reboot
Sep  3 13:01:06.957 WARN Sensor not found in registry. sensor_id=last_reboot
Sep  3 13:01:06.958 WARN Sensor not found in registry. sensor_id=cpu_load_average_(15_min)
Sep  3 13:01:06.958 WARN Sensor not found in registry. sensor_id=cpu_load_average_(15_min)
Sep  3 13:01:06.958 WARN Sensor not found in registry. sensor_id=bytes_sent_throughput
Sep  3 13:01:06.958 WARN Sensor not found in registry. sensor_id=bytes_sent_throughput
Sep  3 13:01:06.958 WARN Unable to retrieve sensors. worker=abrt_problems_sensor worker_type=polling error="unable to retrieve the list of ABRT problems: SystemBus: unable to get data org.freedesktop.problems.GetProblems from org.freedesktop.problems: The name is not activatable"
Sep  3 13:01:06.958 WARN Sensor not found in registry. sensor_id=power_state
Sep  3 13:01:06.958 WARN Sensor not found in registry. sensor_id=power_state
...

Sep  3 13:01:07.089 WARN Sensor not found in registry. sensor_id=external_ipv4_address
Sep  3 13:01:07.089 WARN Sensor not found in registry. sensor_id=external_ipv4_address
Sep  3 13:03:17.492 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:03:17.496 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:03:31.253 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:03:58.014 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:04:01.859 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:04:01.861 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:04:01.863 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:04:07.439 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:04:07.441 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:07:02.592 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:07:02.593 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:07:43.153 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:08:14.217 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:09:00.559 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:09:00.561 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:09:17.617 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:09:58.168 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:09:58.449 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:09:58.454 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:10:01.855 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:10:02.279 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:10:02.280 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:10:02.284 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:10:02.285 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:10:02.502 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:10:02.502 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:11:02.225 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:11:02.225 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:11:06.739 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "
Sep  3 13:11:28.170 ERROR Process sensor failed. error="failed to send sensor update request: code <nil>: "

And it seems to be working?
Mind you, I changed nothing. Not even a computer reboot. You can see in the timestamps that I spent 4 minutes writing this message, decided to try again to grab the actual log files... and it worked? (Kind of, there's those errors at the end.)
Here's the files from the working setup:
go-hass-agent-working.zip
Considering I had this working and it randomly failed during a boot, it makes me wonder if there is a race condition somewhere.
Literally the only thing I did between runs is type in this comment window and delete the folder to get clean log files for you at each step!

Thank you for the additional data and confirmation of the steps!.
That is very odd. It could be a race condition. I have made a fair few changes since I last looked for potential race conditions, I will do some more digging. I've hopefully fixed the logging so that those "ERROR Process sensor failed" messages will show more details in the next release (another regression after some changes). Are you noticing any missing sensors or incorrect data in Home Assistant? The first two warnings are expected at least for deskop hardware and the third warning about abrt just means you don't have that configured or being used.
If you are still getting a lot of those messages "ERROR Process sensor failed" messages while running for a while, you could try turning on trace logging by adding --log-level trace to the command-line. That logging should show more details about any responses from Home Assistant, though the messages may contain more private information (endpoints, tokens, any private information in actual sensor details), so please ensure you check and sanitize them if you wish to share them.
I'm glad it is working though!
I will spin up a Bazzite VM and see if I can reproduce anything similar. It'd be interesting if it was specific to Bazzite or atomic-based distros.

The one I have right now seems to have all its sensors and has been holding up thus far.
When I originally set it up on this distro, it was missing the sensors in my scripts directory. I had assumed this was my fault at the time and had intentions to poke at it and verify that the scripts were working in the new distro.
When I was clearing out old entries in the Mobile App integration to try from scratch, I noticed one of the setups was missing roughly half the sensors (it had about 60ish). I don't know which run it was from.
This is my first time seriously using an atomic distro, so it might be something weird with the atomicity of it for sure. Things about this distro continue to surprise (and occasionally frustrate) me.
That said, I had used an older version of Go-Hass-Agent on my Steam Deck without issue, and that's also atomic (although Arch-based and not Fedora-based). I don't remember that having issues - but again, there are a number of different variables there.

Thanks for the update @Jay2645 and that's cool to see it working on the steam deck. I'd be curious, is there any other sensors or controls that would be useful on that hardware?

So the main challenge with Steam Deck is that Valve will periodically install a new image when you do a system update, and that wipes the /usr folder.
The suggested solution is to only use Flatpaks, but of course since that's sandboxed it means we don't have access to as much as we could. I believe AppImage might also work (using the Gear Lever Flatpak to run it). And of course if everything is inside your user directory that prevents any issues to begin with.
Otherwise you can install it, but next time the OS updates it will re-image /usr and everything will be wiped (either installed via package or Docker). So a way to manage everything from the user folder, Flatpak, or AppImage would be fantastic.
As far as sensors go - I have a handful of ones I wrote myself. I'll hop on the Deck and upload my scripts shortly. Other than the aforementioned update issues, there's not much different from a "regular" Linux install at the end of the day - except for Game Mode (gamescope) which allows the OS to start games without a Desktop Environment (saving resources). I wrote a script to detect Game Mode, although really I haven't done anything useful with this stuff.
Since it can be hooked up to the big screen, being able to turn it on and off is neat - although I enabled ssh and just use the shell_command integration instead of MQTT (simply because I never bothered to set up MQTT on the Deck).

The process using the most CPU (presumably a game, handles non-Steam games):
#!/bin/bash

# Get the process ID of the process using the most CPU
top_process=$(ps -eo pid,%cpu --sort=-%cpu | awk 'NR==2 {print $1}')

# Get the name of the process using the most CPU
top_process_name=$(ps -p "$top_process" -o comm=)

# Create the JSON output
json_output='{
  "schedule": "@every 5s",
  "sensors": [
    {
      "sensor_name": "Top CPU Process",
      "sensor_icon": "mdi:expansion-card",
      "sensor_state": "'"$top_process_name"'"
    }
  ]
}'

# Output the JSON
echo "$json_output"

Game Mode active:
#!/bin/bash

output=$(pgrep gamescope-wl)

# Initialize variables
sensor_state="false"

# Check the length of the output string
if [ ${#output} -gt 0 ]; then
  sensor_state="true"
fi

# Create the JSON output
json_output='{
  "schedule": "@every 5s",
  "sensors": [
    {
      "sensor_name": "Game Mode",
      "sensor_type": "binary",
      "sensor_device_class": "power",
      "sensor_icon": "mdi:controller",
      "sensor_state": '"$sensor_state"'
    }
  ]
}'

# Output the JSON
echo "$json_output"

Process started by Steam (Steam game):
#!/bin/bash

# Find the PID of the steam process
steam_pid=$(pgrep -x steam)

# Function to find the last child process started by reaper
find_last_child_process_of_reaper() {
    local parent_pid="$1"
    local last_child_pid=""

    # Find all child processes of the parent PID in /proc
    child_pids=$(pgrep -a -P "$parent_pid" | awk '{print $1}')

    for pid in $child_pids; do
        # Check if the child process is reaper
        if [[ $(cat /proc/"$pid"/comm) == "steam" ]] || [[ $(cat /proc/"$pid"/comm) == "sh" ]] || [[ $(cat /proc/"$pid"/comm) == "reaper" ]] || [[ $(cat /proc/"$pid"/comm) == "pv-bwrap" ]] || [[ $(cat /proc/"$pid"/comm) == "pressure-vessel" ]]; then
          # If it's reaper, continue searching in its children
          last_child_pid=$(find_last_child_process_of_reaper "$pid")
          if [ -n "$last_child_pid" ]; then
              # Found a child process started by reaper, so return it
              echo "$last_child_pid"
              return
          fi
          break
        elif [[ $(cat /proc/"$pid"/comm) != "steamwebhelper" ]] && [[ $(cat /proc/"$pid"/comm) != "steam-runtime-l" ]] && [[ $(cat /proc/"$pid"/comm) != "gameoverlayui" ]]; then
          echo "$pid"
        fi
    done
}

# Call the function to find the last child process of reaper
child_pid_list=$(find_last_child_process_of_reaper "$steam_pid")

last_child_pid=0

# Iterate through each number in the list
for number in $child_pid_list; do
    # Compare the current number with the maximum value
    if [ "$number" -gt "$last_child_pid" ]; then
        last_child_pid="$number"
    fi
done

result=""

if [ "$last_child_pid" -gt 0 ]; then
  result=$(cat /proc/"$last_child_pid"/comm)
fi

# Create the JSON output
json_output='{
  "schedule": "@every 5s",
  "sensors": [
    {
      "sensor_name": "Current Steam Game",
      "sensor_icon": "mdi:steam",
      "sensor_state": "'"$result"'"
    }
  ]
}'

# Output the JSON
echo "$json_output"

Hey @Jay2645 thank you for the details, that is so cool and interesting! I'm so glad Go Hass Agent is useful to you!
I'll close this issue off for now, as I believe the problem is fixed. If that is not the case, please re-open and we can continue troubleshooting!

authors: Jay2645 goncastrum joshuar

repo: joshuar/go-hass-agent


text:
Fix path in production environment

Related Issue:
#317
Summary:

There's been some issues with path and @AWolf81 had some suggestions in Gitter, so I've been playing around with it.

it wasn't working because there was no .bashrc or .bash_profile in my setup.

Hm 🤔 Do you think it's a common case to not have a .[shell]rc or even a .bash_profile? I'm wondering if we should create a .bash_profile if an rc file cannot be found, and output export PATH=$PATH. Or do you think it's not good to force the .bash_profile and we should provide a good error message/let the user decide what to use?
To the other stuff - tbh the whole path stuff confuses me so I'll have to do some reading. But as long as there's a .bash_profile then it was finding the Node path for you right? I think if you're going to test nvm then you will need to either remove your system Node or comment this out:
if (nodePath) {
  // Node found
  return resolve();
}

Because I have both system + nvm default running and it was finding the path early and returning due to the above, so I had to comment it out to test the rest of the logic in the file.

This wouldn’t work for fish, which doesn’t support && (; might be more portable) and reads from ~/.config/fish/config.fish.

@j-f1 Ah, good point. I'll do a check for it, do you know if echo $SHELL will produce a result like /bin/fish? I guess I can install it and run it as my shell temporarily for testing (or do you know an easier way?).
It looks like && is getting added in 3.0, do you think we have to modify the command?

I think using the ; is a good idea, especially since our target audience may not have the latest versions of everything.
You should definitely try fish :)

So I've run into an issue with $SHELL, it seems that Fish doesn't set the SHELL env variable so echo $SHELL is returning Zsh for me (despite installing and setting Fish as default).
This comment has a command that is more accurate (it successfully returns the correct shell for me):
dscl . -read /Users/${username} UserShell

@j-f1 @AWolf81 What do you think?

@melanieseltzer you should be able to just use fix-path when the Electron app launches, it uses the built-in binary env to log out all environment variables on the host and then grab the $PATH from there, or use a sensible set of defaults ('./node_modules/.bin', '/.nodebrew/current/bin','/usr/local/bin').
fix-path is just a small abstraction on top of shell-path that calls the sync export from shell-path and then appends the result to process.env.PATH. Here's the entire source:

'use strict';
const shellPath = require('shell-path');

module.exports = () => {
	if (process.platform !== 'darwin') {
		return;
	}

	process.env.PATH = shellPath.sync() || [
		'./node_modules/.bin',
		'/.nodebrew/current/bin',
		'/usr/local/bin',
		process.env.PATH
	].join(':');
};

I'm confused because it seems like we're already using it? See this note here about it in the main Electron process file (it's called in production?).
But it's failing according to this line which is the file that's being edited in this PR.

Ah you're right, I totally missed that. Thanks for the clarification.
So with this build, everything works alright on Mac in production? Since fix-path relies on env under the hood, it's possible that env also doesn't load the correct shell config files in a production environment for whatever, in which case this PR is the correct solution.
I'll try and test sometime tomorrow on Mac and see how much I can replicate.

It's building from this branch (other than the issue from #370 but that's a separate thing) and I don't see the missing Node error that appears for me in production 0.3.0 otherwise.
But I think I agree with @AWolf81 that this PR seems a little convoluted - he even encountered an edge case (documented above) where he had no .bashrc or .bash_profile so my sourcing code failed until he added one.
Maybe we should investigate why fix-path is not working in the production distribution only, I don't know too much about it so I could only play around a bit. No combination of fix-path, shell-path, or shell-env was working for me (I played around with adding it to this block). I'm stumped! Appreciate the extra eyes on this :)

@melanieseltzer Maybe it's related to our webpack env handling in config/env.js.
I think we could check if there is something happening with the filtering or we could add the path fix for production there. I haven't tried anything here as I think this path issue is just happening on Mac with production build.

Alright, after lots of experimenting I think I've found a solution using shell-path. I think fix-path is not working in our case due to Mac apps not getting access to env variables if launched from GUI. When launched from terminal everything is fine, so that's why things worked in dev here (since running Guppy in dev launches it from terminal via yarn start).
@superhawk610 let me know what you think. It's building with yarn dist for me and I'm no longer receiving the Node missing error (I'm using NVM). All Node related things seem to be working fine (create new project, dev server, etc).

Hmm, I'm getting Node not found in both dev and prod builds. My Node installation is at ~/n/bin and $PATH configuration is done in my .zshrc with this script:
export N_PREFIX="$HOME/n"; [[ :$PATH: == *":$N_PREFIX/bin:"* ]] || PATH+=":$N_PREFIX    /bin"  # Added by n-install (see http://git.io/n-install-repo).

Here's the path listed in the alert:
// DEV
/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/aaronross/code/guppy/node_modules/.bin:/Users/aaronross/code/node_modules/.bin:/Users/aaronross/node_modules/.bin:/Users/node_modules/.bin:/node_modules/.bin:/Users/aaronross/code/guppy/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS

// PROD
/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/node_modules/.bin:/Users/aaronross/code/guppy/dist/mac/Guppy.app/Contents/Frameworks/Guppy Helper.app/Contents/MacOS

It's interesting that the paths are absolute in dev and relative in prod, perhaps that's something that also needs to be investigated?

Huh. Darn it! Well, there was actually one other thing that was also working for me, but I wasn't sure what to think of it. It's spawning an interactive shell and running echo $PATH. Actually the more I'm reading, the more I think this might be the issue for you:
https://github.com/sindresorhus/fix-path/issues/3#issuecomment-120547010:

I have a feeling this might be that you have those $PATH additions exported in .zshrc and not .zshenv. Is this the case? The .zshrc file is only loaded in interactive terminals, which exec isn't, and you should not be used for exporting environment variables, like $PATH.

I did a test and added your n-install stuff into my own .zshrc, and used the above method like so (note the TEST verbiage):
export N_PREFIX="$HOME/n"; [[ :$PATH: == *":$N_PREFIX/bin:"* ]] || PATH+=":$N_PREFIX/bin/TEST"
# Added by n-install (see http://git.io/n-install-repo).

Modified the code to be:
const fixedPath = shellPath.sync();
const fixedPathFromInteractiveShell = childProcess
  .execFileSync(window.process.env.SHELL, ['-i', '-c', 'echo $PATH'])
  .toString()
  .trim();

window.process.env.PATH = fixedPath + fixedPathFromInteractiveShell;

resolve();

I successfully get the n-install stuff from my .zshrc into my path in dev and prod:
dev: /usr/local/git/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/melleh/Sites/guppy/node_modules/.bin:/Users/melleh/Sites/node_modules/.bin:/Users/melleh/node_modules/.bin:/Users/node_modules/.bin:/node_modules/.bin:/Users/melleh/Sites/guppy/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Helper.app/Contents/MacOS:/usr/local/go/bin/Users/melleh/bin:/usr/local/bin:/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/Users/melleh/Sites/guppy/node_modules/.bin:/var/folders/m9/rh39vf_j4s3gr52kcqtfcc5h0000gn/T/yarn--1554486651248-0.5182929671326244:/Users/melleh/Sites/guppy/node_modules/.bin:/Users/melleh/.config/yarn/link/node_modules/.bin:/Users/melleh/Sites/guppy/node_modules/.bin:/Users/melleh/.config/yarn/link/node_modules/.bin:/usr/local/libexec/lib/node_modules/npm/bin/node-gyp-bin:/usr/local/lib/node_modules/npm/bin/node-gyp-bin:/usr/local/bin/node_modules/npm/bin/node-gyp-bin:/Users/melleh/bin:/usr/local/bin:/usr/local/git/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/melleh/n/bin/TEST
prod: /usr/local/git/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/node_modules/.bin:/Users/melleh/Sites/guppy/dist/mac/Guppy.app/Contents/Frameworks/Guppy Helper.app/Contents/MacOS:/usr/local/go/bin/Users/melleh/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/melleh/n/bin/TEST
I'm not sure if using both shellPath and spawning the interactive shell is overkill, it seems to return a lot in dev compared to prod, and I'm really confused why that is.
But nevertheless, does the above code work for you? I didn't want to commit it in case it's another dead end.

Nice, yeah this works for me. shellPath uses shell-env under the hood, which in turn just wraps the output from env in a non-interactive shell, so I wonder if just using echo $PATHin an interactive shell like you've proposed wouldn't be a sufficient solution on its own?

Ah! I see what it's doing now, took a bit to wrap my head around. Yes, I think it should be sufficient on its own since it catches everything, including stuff exported from dotfiles.
Just not sure why there's so much stuff getting inserted into PATH in the dev environment, is that just some Electron dev specific stuff?
dev:
/Users/melleh/bin:/usr/local/bin:/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/Users/melleh/Sites/guppy/node_modules/.bin:/var/folders/m9/rh39vf_j4s3gr52kcqtfcc5h0000gn/T/yarn--1554580655799-0.4203236455267696:/Users/melleh/Sites/guppy/node_modules/.bin:/Users/melleh/.config/yarn/link/node_modules/.bin:/Users/melleh/Sites/guppy/node_modules/.bin:/Users/melleh/.config/yarn/link/node_modules/.bin:/usr/local/libexec/lib/node_modules/npm/bin/node-gyp-bin:/usr/local/lib/node_modules/npm/bin/node-gyp-bin:/usr/local/bin/node_modules/npm/bin/node-gyp-bin:/Users/melleh/bin:/usr/local/bin:/usr/local/git/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/melleh/n/bin/TESTINGZSHRC
prod (system node):
/Users/melleh/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/melleh/n/bin/TESTINGZSHRC
prod (nvm node):
/Users/melleh/.nvm/versions/node/v11.4.0/bin:/Users/melleh/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/melleh/n/bin/TESTINGZSHRC

Yeah I'm fairly certain the extra junk in dev is coming from Electron, I get some warning about the Node version in that /var/folders/m9/... not matching every time I launch with yarn start.

repo: joshwcomeau/guppy

license: ISC


text:
Torch api14+

Torch in api14+

Could you expand on what you want to achieve with the pull request?
The latest version is compatible with API 14+ (just have to downgrade zxing:core), and contains the torch methods.

authors: jdruedaq rkistner

repo: journeyapps/zxing-android-embedded


text:
AGIMUS Twitter Integration

Post when AGIMUS is restarting, maybe send drops/clips over to it when requested by users?

research/context to simple tweet bot action: https://github.com/mathew-fleisch/blog/blob/main/blog/2021-04-04/tweet-via-github-actions.md

authors: mathew-fleisch zmattingly


text:
A segmentation fault

#11 0x0000561c765115db in Midi_Synth_Instrument::audio_callback(float*, unsigned int, void*)
    (output=0x40, nframes=2348887296, user_data=0x7fda8c03ab80) at sources/player/instrument.cc:284
#12 0x0000561c76514c64 in Audio_Device::process_cycle(float*, unsigned int)
    (this=0x7fda8c0021b0, output=0x7fda8c012010, nframes=512) at sources/player/adev/adev.cc:45
#13 0x0000561c76515201 in Audio_Device_Jack::jack_audio_callback(unsigned int, void*) (nframes=512, user_data=0x7fda8c0021b0)
    at sources/player/adev/adev_jack.cc:81

It happened while opening another JACK client as the synth played in the background.

repo: jpcima/midiplay


text:
Update vim.org package.

...it's fairly outdated now.

Updated with the 1.5 release.

repo: jpetrie/vim-counterpoint


text:
Is it possible to use mixed Java/PHP classes in a JPHP project?

I've had this question for some time now. It would be awesome to work almost seamlessly with both Java and PHP code, since most useful classes are already written in Java (and rewriting some of them takes some effort) and it's the JVM we're using here.

There are a lot of difficulties to implement this. It is especially difficult to implement anonymous classes and lambdas from Java, for this you need to compile the code at runtime. And this, in turn, will create another problem, the inability to compile for Android, because it should already have only compiled code. On Android, another virtual machine is Dalvik VM, which has completely different standards and formats compared to Open/Oracle JDK.

The current work scheme of the JPHP allows you to run any JPHP code on the Dalvik VM, because it is precompiled in bytecode.
For the same reason, the eval function doesn;t work on Android, because it requires compilation at runtime.

I didn't mention inline java code on PHP sources because I sort of knew it was difficult. I was referring specifically to having distinct java and PHP source files that can interact with each other.

It's possable now, you can write own extension. You need write wrapper classes for java classes and register the all in extension.  The jphp-gui-ext (javafx extension) was written in the same way (https://github.com/jphp-group/jphp-gui-ext/tree/master/jphp-gui-ext/src-jvm/main/java/org/develnext/jphp/ext/javafx/classes - wrapper classes).

It is also possible to write a package for jppm, which will combine both the php code and java via Gradle plugin. An example of such a package - https://github.com/jphp-group/jphp-dffi-ext.

https://github.com/jphp-group/java-reflection-ext - Java Reflection package allows you to work with java reflection.

@dim-s i have opened a issue about that its easy to do that we will start from the graal simple lang implamentation and add each php function look into https://github.com/jphp-group/jphp/issues/379

authors: AryToNeX dim-s frank-dspeed

repo: jphp-group/jphp


text:
Allow to deserialize to Option<Vec>

Ran into this whilst trying to deserialize an optional list of choices in a web app.

Thanks for the PR! I guess it doesn't hurt, but I recommend writing #[serde(default)] value: Vec<String> instead.

authors: jplatte thomaseizinger


text:
🛑 HCIL Code is down

In 0b4c9db, HCIL Code (hcilcode.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: HCIL Code is back up in 682918d after 9 minutes.


text:
🛑 Tandoori RTP is down

In ca2eae5, Tandoori RTP (https://Tandoorinrtp.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Tandoori RTP is back up in 7b55e69 after 49 minutes.


text:
🛑 OBSN is down

In 65ec386, OBSN (https://obsn.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: OBSN is back up in ccd8a20 after 21 days, 3 hours, 42 minutes.


text:
Possible stack overflow during deepcopy of CancellationTokenSource property ?

To be verified.
Not entirely sure if I should deepcopy something tied to a thread lifetime, but it should not crash in any case.

Update, I can't reproduce this, deepcloning the following doesn't crash:
        public class SomethingWithCTS
        {
            public int Value { get; set; } = 10;
            public CancellationTokenSource CancellationTokenSource { get; set; } = new CancellationTokenSource(0);
        }

Many thanks for looking into it, I appreciate it. I confirm that simple fresch CTS is cloned successfully, Problematic case was more complex, with registered callback and cancelled CTS. Sorry, I tried but can't recall specific circumstances for the error. Perhaps, a callback was an issue because delegate is pulled with an entire context?

Okay, I was able to reproduce an error. This object structure leads to the non-catchable stack overflow and VS exiting with "access violation" error during deep copying but only when TCS and CTS are initialized. Interesting, if debug and pause the code, it works without error.
public partial class ClassA
{
    private CancellationTokenSource _cts;
    public ClassB ClassB { get; set; }
}

public class ClassB
{
    public TaskCompletionSource<ClassB> Tcs { get; set; }
    public Task<ClassB> AwaitedResult => Tcs?.Task;
}

still no crash here :/ does the tcs return an instance of itself in your case?

TCS returns itself like this:
ClassB.Tcs.TrySetResult(ClassB);

It must be somehow tied to concurrency rather to an object structure, maybe all together.
Consider the following scenario (using ClassA and ClassB from example above):

ClassA is initialized, ClassB is not.
MethodC, where deep copying is occuring, is called from MVC controller, and is DI-managed transient service.
If manually call MethodC. it works. But if call controller simultaneously, causing rising few instances of MethodC, DeepCopy causes overflow, even though ClassA is just independent object (at least. at the first glance).

I actually gave up and switched to TinyMapper, it works as expected.

Yeah and I can't reproduce the problem. Anyway, for you and anyone else reading this, I would very much recommend you don't try clone object trees that have threads associated with them.

authors: jpmikkers nikriaz


text:
Perspective node runtime

When trying to use the node build of perspective the javascript errors out on initialization:
const perspective = = require("@jpmorganchase/perspective").default
Object.keys(perspective)
/*
[ 'worker',
  'TYPE_AGGREGATES',
  'TYPE_FILTERS',
  'AGGREGATE_DEFAULTS',
  'FILTER_DEFAULTS',
  'SORT_ORDERS' ]
*/
const worker = perspective.worker()
/*
ReferenceError: window is not defined
    at Object.worker (/Users/f608687/dev/scratch/node_modules/@jpmorganchase/perspective/build/perspective.umd.js:1:8192)
*/

Would it be best to remove the webpack build for node and maybe spend time later on writing a proper node-gyp binding the perspective C++ runtime ala #212 ?

Thanks for the report!
This certainly needs better documentation and some code cleanup.  The node.js runtime does not support a worker implementation currently, due to

The API differences between WebWorkers and Node's child_process module made this not free (unless there is a better way).
There is no renderer process in node.js, so I was originally unclear that subprocess instantiation of the node.js was even warranted.

The intention of the documentation was to show the 2 separate ways to access the the perpsective module symbol, In The Browser for using the worker() method to get a perspective module symbol, and In Node.js for acquiring the same symbol simply by importing it.  This is wildly insufficient, so I'll be cleaning up the documentation to make this easier to understand and will close this issue once it is merged.
Separately, I am completely open to adding a subprocess API to the node.js runtime as well.  If you're interested in contributing such a change, PRs are always welcome - if you would just like to request and track progress on this, feel free to open a separate issue detailing your use case so we can better understand how best to implement it.

Regarding node-gyp - I think we'd need some clear explanation of what this would bring to the project over the WebAssembly runtime.  From my (albeit limited) scope, node-gyp would seem to add quite alot of additional build complexity, potentially a separate c++ API for binding, and a loss of portability;  while the performance gain has at best not been explored, and I have reason to suspect it is minimal in Perspective's case.

authors: LukeSheard texodus

repo: jpmorganchase/perspective


text:
Combo Box v2 (popper + free text support)

### Checklist
- [ ] Density (HD, MD, LD, TD)
- [ ] Mode (Light, Dark)
- [ ] Fill (Primary, Secondary, Tertiary)
- [ ] State (Default, Hover, Selected/Active, Disabled, Read-only, Other)
- [ ] Controlled API
- [ ] UITK accessibility parity (screen reader + keyboard interactions)

### Deliverables
- [ ] Characteristics spec
- [ ] Interactions spec, where necessary
- [ ] In Code & Figma (Component + Guide)
- [ ] Supporting site documentation

### Features
- [ ] Create dependency: Popper, for dynamic overlay list positioning
- [ ] Free text entry

Replaced by #2409 and #2763

authors: joshwooding origami-z

repo: jpmorganchase/salt-ds