Debian 11: hangs on Setup cronjob step

I've migrated from AlmaLinux to Debian 11 and AdGuardHome sync works with the exception that if configured to setup a cron task, it will hang up indefinitely.
Snippet from my .adguardhome-sync.yaml file
# cron expression to run in daemon mode. (default; "" = runs only once) cron: "*/10 * * * *"
Then upon running the command to run adguard home it'll hang
~/work/bin/adguardhome-sync run
Once it gets to this line it'll hang indefinately;
2022-08-11T23:12:19.211-0700    INFO    sync    sync/sync.go:50 Setup cronjob   {"cron": "*/10 * * * *"}
Go was installed using the process on this page,
https://www.digitalocean.com/community/tutorials/how-to-install-go-on-debian-10
Is perhaps the path throwing things off?
I've commented the cron line out of the config file and manually setup a crontab for the time being but would like to figure out what the root issue is.

Hi @gawainXX

adguardhome-sync is built as a static  binary, therefore you do not need go to be installed.
please provide more information. How is the config, what are the logs.

I'm seeing the same behavior with ubuntu 20.04 using the static binary
I've created the ~/.adguardhome-sync.yaml file as instructed,
Here was how I installed adguardhome-sync (was placed into root of ~
`
cd ~
wget --no-check-certificate --content-disposition https://github.com/bakito/adguardhome-sync/releases/download/v0.4.5/adguardhome-sync_0.4.5_linux_x86_64.tar.gz
tar -xf adguardhome-sync_0.4.5_linux_x86_64.tar.gz
chmod +x ~/adguardhome-sync
`
2022-08-12T17:32:06.786-0700    INFO    root    cmd/root.go:118 Using config file:/home/adguardhome-sync/.adguardhome-sync.yaml 2022-08-12T17:32:06.788-0700    INFO    sync    sync/sync.go:30 AdGuardHome sync        {"version": "0.4.5", "build": "2022-08-12T07:20:12Z"} 2022-08-12T17:32:06.789-0700    INFO    sync    types/features.go:70    Disabled features       {"features": ["DHCP.ServerConfig", "DHCP.StaticLeases"]} 2022-08-12T17:32:06.789-0700    INFO    sync    sync/sync.go:50 Setup cronjob   {"cron": "*/10 * * * *"}

PLEASE provide your config file!

PLEASE provide your config file!
Username and PW omitted
Works fine if I comment out the cron line.

`# cron expression to run in daemon mode. (default; "" = runs only once)
cron: "*/10 * * * *"
runs the synchronisation on startup
runOnStart: true
origin:
url of the origin instance
url: http://<IP_ADDRESS>
apiPath: define an api path if other than "/control"
insecureSkipVerify: true # disable tls check
username: myusername
password: password
replica instance (optional, if only one)
replica:
url of the replica instance
url: http://<IP_ADDRESS>
username: myusername
password: password
Configure the sync API server, disabled if api port is 0
api:
Port, default 8080
port: 0
if username and password are defined, basic auth is applied to the sync API
username: myusername
password: password
Configure sync features; by default all features are enabled.
features:
generalSettings: true
queryLogConfig: true
statsConfig: true
clientSettings: true
services: true
filters: true
dhcp:
serverConfig: false
staticLeases: false
dns:
serverConfig: true
accessLists: true
rewrites: true
'

Hi @gawainXX
I was not able to reproduce your issue.
I started a debian:11.4 docker container and started adguardhome-sync with your configuration.
The synchronization got started the next time the cron expression matches.
Since your config hast the cron expression  "*/10 * * * *", this will be every 10 minutes. (x:00, x:10, x:20, ...)

If you want to start it immediately, you need to add the following parameter:
runOnStart: true


Fix dev setup instructions in contributing guide

Hi, I was just setting up Ghost for local development and found the Contributing guide to be slightly out-dated. The shell:ember:init task failed because bower was not found. The PR fixes that.
The recommended Node version for development could also be updated from 0.10.x to 4.2.x, but I wasn't sure if you'd want that - just let me know!

@vickychijwani thanks for pointing out the docs issue! It's something that's slipped through the cracks after the recent split of the admin client into it's own repo.
It was never our intent to start requiring a global bower install, I've opened a pair of PRs (#7006, and https://github.com/TryGhost/Ghost-Admin/pull/79) that together will mean that the client's bower dependency is used and the install docs will be correct again.

Ok, I'll close this one then :smile:


feat: add environment data to control tab visibility in the application

Task linked: CU-8695jh2cm Hide tabs in application by request

Not actual, implemented  by https://github.com/WebTrit/webtrit_phone/pull/233


v6.5+: java.lang.Exception: response content-type is not XML

Hi Yannick,
I'm running into a problem with lein-ancient 6.5+ (6.5 and 6.6). Running lein ancient :all at the command line produces:
(warn)  [central] - Δ 2112ms - failure when checking com.cemerick/clojurescript.test: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [central] - Δ 2115ms - failure when checking org.clojure/tools.reader: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [clojars] - Δ 2364ms - failure when checking lein-autoexpect/lein-autoexpect: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [clojars] - Δ 2377ms - failure when checking lein-expectations/lein-expectations: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [clojars] - Δ 2382ms - failure when checking com.cemerick/clojurescript.test: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [clojars] - Δ 2412ms - failure when checking lein-pprint/lein-pprint: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [clojars] - Δ 2436ms - failure when checking lein-ancient/lein-ancient: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [clojars] - Δ 2447ms - failure when checking codox/codox: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [sonatype-oss-public] - Δ 2571ms - failure when checking com.cemerick/clojurescript.test: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [sonatype-oss-public] - Δ 2631ms - failure when checking org.clojure/tools.reader: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [clojars] - Δ 1584ms - failure when checking expectations/expectations: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
(warn)  [clojars] - Δ 1586ms - failure when checking com.cemerick/double-check: java.lang.Exception: response content-type is not XML (#{"text/xml" "application/xml"}): null
all artifacts are up-to-date.

This happens reliably on my end, so a little surprised no one else has reported this yet? Any ideas?
Thanks a lot! Cheers :-)

Hi Peter,
do you have any :mirrors set up? Or are you behind a proxy?
Maybe it's some dependency conflict in the plugins - could you do lein deps :plugin-tree and paste the output?
Thanks!
Yannick

Hi Yannick,

do you have any :mirrors set up?

Not as far as I'm aware (not intentionally); how would I confirm?

Or are you behind a proxy?

No proxy. And have tried a few different connections with the same results: WiFi, 3G, landline - all different providers.

Maybe it's some dependency conflict in the plugins - could you do lein deps :plugin-tree and paste the output?

encore's output is:
(Possibly confusing dependencies found:)
([com.cemerick/clojurescript.test "0.3.3"] -> [org.clojure/clojurescript "0.0-2411"])
( overrides)
([com.keminglabs/cljx "0.6.0"] -> [com.cemerick/piggieback "0.1.5"] -> [org.clojure/clojurescript "0.0-2665"])
(
Consider using these exclusions:)
([com.keminglabs/cljx "0.6.0" :exclusions [org.clojure/clojurescript]])
nil
 [codox "0.8.11"]
   [codox/codox.leiningen "0.8.11"]
 [com.cemerick/clojurescript.test "0.3.3"]
   [org.clojure/clojure "1.6.0"]
   [org.clojure/clojurescript "0.0-2411"]
     [com.google.javascript/closure-compiler "v20140625"]
       [args4j "2.0.26"]
       [com.google.code.findbugs/jsr305 "1.3.9"]
       [com.google.guava/guava "17.0"]
       [com.google.javascript/closure-compiler-externs "v20140625"]
       [com.google.protobuf/protobuf-java "2.5.0"]
       [org.json/json "20090211"]
     [org.clojure/data.json "0.2.3"]
     [org.clojure/google-closure-library "0.0-20140718-946a7d39"]
       [org.clojure/google-closure-library-third-party "0.0-20140718-946a7d39"]
     [org.mozilla/rhino "1.7R4"]
 [com.keminglabs/cljx "0.6.0"]
   [com.cemerick/piggieback "0.1.5"]
   [net.cgrand/sjacket "0.1.1" :exclusions [[org.clojure/clojure]]]
     [net.cgrand/parsley "0.9.2"]
     [net.cgrand/regex "1.1.0"]
   [org.clojure/core.match "0.2.0"]
   [watchtower "0.1.1"]
 [lein-ancient "0.6.4"]
   [ancient-clj "0.3.1"]
     [clj-aws-s3 "0.3.10" :exclusions [[joda-time] [org.clojure/clojure]]]
       [com.amazonaws/aws-java-sdk "1.7.5"]
         [com.fasterxml.jackson.core/jackson-annotations "2.1.1"]
         [com.fasterxml.jackson.core/jackson-core "2.1.1"]
         [com.fasterxml.jackson.core/jackson-databind "2.1.1"]
         [org.apache.httpcomponents/httpclient "4.2"]
           [org.apache.httpcomponents/httpcore "4.2"]
     [clj-time "0.9.0" :exclusions [[joda-time] [org.clojure/clojure]]]
     [commons-codec "1.10" :exclusions [[joda-time] [org.clojure/clojure]]]
     [commons-logging "1.2" :exclusions [[joda-time] [org.clojure/clojure]]]
     [http-kit "2.1.19" :exclusions [[joda-time] [org.clojure/clojure]]]
     [joda-time "2.7" :exclusions [[joda-time] [org.clojure/clojure]]]
     [org.clojure/data.xml "0.0.8" :exclusions [[joda-time] [org.clojure/clojure]]]
   [commons-io "2.4"]
   [jansi-clj "0.1.0"]
     [org.fusesource.jansi/jansi "1.11"]
   [potemkin "0.3.11"]
     [clj-tuple "0.1.7"]
     [riddley "0.1.7"]
   [rewrite-clj "0.4.12"]
     [org.clojure/tools.reader "0.8.13" :exclusions [[org.clojure/clojure]]]
   [version-clj "0.1.2"]
 [lein-autoexpect "1.4.2"]
   [jakemcc/clojure-gntp "0.1.1" :exclusions [[org.clojure/clojure]]]
   [leinjacker "0.4.2" :exclusions [[org.clojure/clojure]]]
     [org.clojure/core.contracts "0.0.1"]
       [org.clojure/core.unify "0.5.3"]
   [org.clojure/tools.namespace "0.2.8" :exclusions [[org.clojure/clojure]]]
 [lein-cljsbuild "1.0.5"]
   [fs "1.1.2"]
     [org.apache.commons/commons-compress "1.3"]
   [lein-cljsbuild/cljs-compat "1.0.0-20150219.215334-32"]
 [lein-expectations "0.0.8"]
   [expectations "1.4.5"]
 [lein-pprint "1.1.2"]

Note that I get the same results with every project, even if I pull out all plugin dependencies besides lein-ancient. I.e. doesn't look like a dep conflict to me.
Just let me know if any other details would be handy.
Cheers :-)

Hi Peter,

how would I confirm?

If neither your profiles.clj nor your project.clj contain the :mirrors key, none should be used. I assume that you'd have seen that key if it were used anywhere.

I.e. doesn't look like a dep conflict to me.

Maybe with Leiningen's own dependencies? Which version (of Leiningen) are your using?
Cheers! :)

More thoughts:
The major change between 0.6.4 and 0.6.5+ is switching from http-kit's client to clj-http which should be the reason for what you're observing. - but it's more than curious that there seems to be nobody else with that issue...
Also, I don't think I'm trying to read the content-type header using the wrong key since clj-http's README explicitly states:

Response headers can be read as keywords or strings of any case. If the server responds with a “Date” header, you could access the value of that header as :date, “date”, “Date”, etc.

If neither your profiles.clj nor your project.clj contain the :mirrors key, none should be used. I assume that you'd have seen that key if it were used anywhere.

Okay, definitely no mirrors then.

Maybe with Leiningen's own dependencies? Which version (of Leiningen) are your using?

That's it, you found the problem: Lein 2.4.2 consistently produces the error, 2.5.1 works fine.
I'm avoiding the latest Lein releases lately due to some unresolved bugs with them, so I'll just hold back on lein-ancient releases for a while.

switching from http-kit's client to clj-http

May I ask what your motivation for the change was? Just curious.
Thanks again for your help with this! Feel free to close the issue if you'd like.
Cheers :-)

May I ask what your motivation for the change was?

There was an issue (#50) using http-kit's client and a proxy. Apparently, http-kit does neither use the system's proxy settings nor allow for manual specification of one.
Anyways, could you try the latest SNAPSHOT?
[lein-ancient "0.6.7-SNAPSHOT"]

I think I managed to get the plugin compatible with Leiningen >= 2.4.0 again.

Anyways, could you try the latest SNAPSHOT?

Snapshot is working with lein 2.4.2

Release Notes

Thanks Yannick, much appreciated! Cheers :-)

We ran into this problem after an older s3 wagon polluted our company repo with artifacts with the wrong content type.  Beware.


RSpec 3 - Migration specs conversion

Converts all migration specs to RSpec 3 expect syntax.
No troubles at all with this one.

@miq-bot add_label test

@Fryguy @jrafanie

@chrisarcand another multi-line whitespace removed problem? There are a few places where the expected values are not separated by a space.
-- to_ary()
  1) FixReplicationOnUpgradeFromVersionFour#up handles replication for renamed tables in rr_pending_changes
     Failure/Error: migrate
       AwesomeSpawn received :run! with unexpected arguments
         expected: ("bin/rake evm:db:environmentlegacykey evm:dbsync:uninstalldrift_states miq_cim_derived_metrics miq_request_tasksmiq_storage_metrics storages_vms_and_templates")
              got: ("bin/rake evm:db:environmentlegacykey evm:dbsync:uninstall drift_states miq_cim_derived_metrics miq_request_tasks miq_storage_metrics storages_vms_and_templates")
     # ./db/migrate/20131216214850_fix_replication_on_upgrade_from_version_four.rb:167:in `block in up'
     # ./db/migrate/20131216214850_fix_replication_on_upgrade_from_version_four.rb:166:in `up'
     # ./spec/support/migration_spec_helper.rb:67:in `migrate_under_test'
     # ./spec/support/migration_spec_helper.rb:32:in `block (2 levels) in migrate'
     # ./spec/support/migration_spec_helper.rb:78:in `suppress_migration_messages'
     # ./spec/support/migration_spec_helper.rb:32:in `block in migrate'
     # ./spec/support/migration_spec_helper.rb:54:in `clearing_caches'
     # ./spec/support/migration_spec_helper.rb:28:in `migrate'
     # ./spec/migrations/20131216214850_fix_replication_on_upgrade_from_version_four_spec.rb:69:in `block (4 levels) in <top (required)>'
     # ./spec/support/migration_spec_helper.rb:54:in `clearing_caches'
     # ./spec/support/migration_spec_helper.rb:10:in `block (2 levels) in migration_context'

Yeah same exact issue; forgot to add a space for the multiline string. Fixed!

@miq-bot add_label rspec3

Looks good!

@miq-bot add_label cleanup/rubocop


Implement automatic PR validation using GitHub Actions

This pull request implements basic PR validation for new PRs coming in against SaaS Boost. For any new Pull Request opened against SaaS Boost, two checks will be started: "Build-Java" and "Build-Webclient". If these checks fail, the PR will not be able to be merged and new commits should be added to the PR to alleviate the issues and automatically rerun the checks.
For example, look at this PR I opened against my own fork: https://github.com/PoeppingT/aws-saas-boost/pull/3
You can see that three commits were added to this pull request:
Thomas Poepping added 3 commits 34 minutes ago
Change docs to install correct maven version using cloud9. f9fcc0f
merge compile and test action, add install so spotbugs and checkstyle… 322440c
Raise allowed checkstyle violations to 156 to pass checkstyle. 0364c12

Next to each of these commits (by the commit id) is either a red ❌  or a green ✅ . To view details on the checks run, you can click on each of those to discover what went wrong.
For example, if you click on the red ❌ next to 322440c, you will see that the "Build-Java" job failed. Clicking through to details, you can inspect the stages of the job that ran and see that the "Code Style Check" failed because there were too many violations in the installer.
The third commit on the PR raises the allowed violations, and the automatic checks are shown to have passed by a green ✅ .
This PR will close https://github.com/awslabs/aws-saas-boost/issues/96

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

Looks like yarn can't combine the download of dependencies with the invocation of the build. You have to do it in 2 steps. First, yarn install -- or just yarn and second, yarn run build or just yarn build. This GitHub action doesn't have anything to do with the installer logic, it's just making sure we can successfully build the React app before posting the PR for review.
Looks good as is!


Custom_openai is the only chat model provider

Describe the bug
I cannot choose another Chat model provider than Custom_openai. This is giving me an error upon loading localhost:3000, which makes me unable to use Perplexica.
To Reproduce
Install Perplexica by git cloning the repo, edit sample.config.toml into config.toml, and then run sudo docker compose up -d.

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

Additional context
I'm using Ubuntu. Going to localhost:11434 gives me Ollama is running, so I'm using localhost:11434 as my Ollama API URL. Going to localhost:32768 gives me SearXNG's homepage. I'm using Ollama as a service using systemctl.
My config.toml:
[API_KEYS]
OPENAI = ""
GROQ = ""
ANTHROPIC = ""

[API_ENDPOINTS]
OLLAMA = "http://localhost:11434"
SEARXNG = "http://localhost:32768"

[GENERAL]
PORT = 3001
SIMILARITY_MEASURE = "cosine"

https://github.com/ItzCrazyKns/Perplexica?tab=readme-ov-file#ollama-connection-errors

I followed that guide and added Environment="OLLAMA_HOST=<IP_ADDRESS>" and ran systemctl restart ollama already, but I'm still seeing the same problem. I also tried using hostname -I to get my IP address, which I then used for http://<private_ip_of_host>:11434, but it's still not working.


Add padding in account deserialization

According to Solana's C SDK, there is a padding between accounts: https://github.com/solana-labs/solana/blob/427ad7b5bde27fe71cff13a1ed0a6a3f26302ed4/sdk/bpf/c/inc/sol/deserialize.h#L50-L68

Needs a testcase

I've added two test cases


NextJS getServerSideProps() missing cookies

Before opening, please confirm:

[X] I have searched for duplicate or closed issues and discussions.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

JavaScript Framework
Next.js (tried with both 11 and 12)
Amplify APIs
Not applicable
Amplify Categories
No response
Environment information

  System:
    OS: macOS 11.6.2
    CPU: (8) x64 Intel(R) Core(TM) i5-1038NG7 CPU @ 2.00GHz
    Memory: 56.79 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.14.0 - /usr/local/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 8.3.1 - /usr/local/bin/npm
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 99.0.4844.51
    Firefox: 97.0.2
    Safari: 15.2
  npmGlobalPackages:
    @aws-amplify/cli: 7.6.4
    corepack: 0.10.0
    eas-cli: 0.4.3
    expo-cli: 4.0.13
    expo: 39.0.5
    gatsby-cli: 3.7.1
    graphql: 15.4.0
    lerna: 4.0.0
    mocha: 9.1.3
    n: 7.5.0
    npm: 8.3.1
    ts-node: 10.4.0
    tslint: 6.1.3
    typescript: 4.5.2

Describe the bug
When using getServerSideProps() in my NextJS project, I am unable to grab the cookies from the header.
When doing a clientside request with fetch() the cookies work fine.
This also works fine on my local machine through yarn dev.
Is there something special I have to do to use cookies in getServerSideProps()?
context.req.headers.cookies and context.req.cookies are both undefined.
Expected behavior
On getServerSideProps() we should be able to retrieve the cookies of the user
Reproduction steps

Attach cookies to the url
Go to a route that uses getServerSideProps(). This should automatically send the cookies with the request.
Try to read the cookies in getServerSideProps() but shows up as undefined

Code Snippet
// Put your code below this line.

Log output

// Put your logs below this line

aws-exports.js
No response
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response

Although my solution allowed for cookies to be passed, these cookies are then cached, causing unexpected responses.
So it is not a valid solution.
Using Amplify to deploy I am unable to get cookies on getServersideProps or inside any API call.

Also experiencing this issue.

+1

@joaopgsilva's answer fixed the issue for me. The problem was actually the Cloudfront cache, after fixing it the API responses were just fine.

Go to Cloudfront, open the distribution auto-created by Amplify
Click Behaviors
Edit the behaviors with the path pattern api/* and Default (*), set Cookies to All

While @0xNoxETH's solution works, the distribution's behaviors config seems to reset on every deployment...

Having the same issue with amplify not sending cookies server side. We use cookies to store information about the user, and update our UI with appropriate texts. But since this is information is not being sent, it's resulting in a minified react error #418, which states that "Hydration failed because the initial UI does not match what was rendered on the server." I've also been able to go to Cloudfront to update the cookies settings manually. But this is overriden on every deployment, and is not a maintainable deal solution...Any ideas on how we should proceed?

Having the same issue. Any progress on this?

+1


Incorrect next_time for cron that is supposed to run every 3 hours for America/New_York

Issue description
next_time in correct for cron that is suppose to run every 3 hours.
How to reproduce
The simplest piece of code that reproduces the issue, for example:
Time.now.utc
=> 2023-10-03 18:17:37.566578 UTC

Fugit::Cron.parse("0 */1 * * * America/New_York").next_time.to_utc_time
=> 2023-10-03 19:00:00 UTC

pry(main)> Fugit::Cron.parse("0 */2 * * * America/New_York").next_time.to_utc_time
=> 2023-10-03 20:00:00 UTC

pry(main)> Fugit::Cron.parse("0 */3 * * * America/New_York").next_time.to_utc_time
=> 2023-10-03 19:00:00 UTC

Error and error backtrace (if any)
None
Additional context
I would have expected it to be the same as without the time zone
Fugit::Cron.parse("0 */1 * * *").next_time.to_utc_time
=> 2023-10-03 19:00:00 UTC

 pry(main)> Fugit::Cron.parse("0 */2 * * *").next_time.to_utc_time
=> 2023-10-03 20:00:00 UTC

pry(main)> Fugit::Cron.parse("0 */3 * * *").next_time.to_utc_time
=> 2023-10-03 21:00:00 UTC

Add any other context about the problem here.

Hello,
I guess your machine TZ is set to "UTC".
require 'fugit'

#ENV['TZ'] = 'America/New_York'
ENV['TZ'] = 'UTC'

#Time.now.utc
#=> 2023-10-03 18:17:37.566578 UTC
  #
t = Fugit.parse('2023-10-03 18:17:37 UTC').to_local_time
#t = Time.now

p t.to_s

puts "---"

[ 1, 2, 3 ].each do |n|
  s = "0 */#{n} * * *"
  t1 = Fugit::Cron.parse(s).next_time(t)
  t1t = t1.translate(ENV['TZ']).to_s
  t1u = t1.to_utc_time
  p [ s, t1.to_s, '>>>', t1t, t1u ]
end

puts "---"

[ 1, 2, 3 ].each do |n|
  s = "0 */#{n} * * * America/New_York"
  t1 = Fugit::Cron.parse(s).next_time(t)
  t1t = t1.translate('America/New_York').to_s
  t1u = t1.to_utc_time
  p [ s, t1.to_s, '>>>', t1t, t1u ]
end

Gives on my machine:
"2023-10-04 03:17:37 +0900"
---
"2023-10-03 18:17:37 +0000"
---
["0 */1 * * *", "2023-10-03 19:00:00 Z", ">>>", "2023-10-03 19:00:00 Z", 2023-10-03 19:00:00 UTC]
["0 */2 * * *", "2023-10-03 20:00:00 Z", ">>>", "2023-10-03 20:00:00 Z", 2023-10-03 20:00:00 UTC]
["0 */3 * * *", "2023-10-03 21:00:00 Z", ">>>", "2023-10-03 21:00:00 Z", 2023-10-03 21:00:00 UTC]
---
["0 */1 * * * America/New_York", "2023-10-03 19:00:00 Z", ">>>", "2023-10-03 15:00:00 -0400", 2023-10-03 19:00:00 UTC]
["0 */2 * * * America/New_York", "2023-10-03 20:00:00 Z", ">>>", "2023-10-03 16:00:00 -0400", 2023-10-03 20:00:00 UTC]
["0 */3 * * * America/New_York", "2023-10-03 19:00:00 Z", ">>>", "2023-10-03 15:00:00 -0400", 2023-10-03 19:00:00 UTC]

The time that matters is the one following ">>>". 19 is a multiple of 1, 20 is a multiple of 2, 21 is a multiple of 3. The America/New_York sees 15 as a multiple of 1, 16 as a multiple of 2, and 15 as a multiple of 3, then you translate to UTC.
When you give a time zone to fugit, it computes in the time zone you give, not in the default timezone.
Best regards.

ah! thank you for clarifying. I have ENV["TZ"] to nil, but I guess the usage of timezone wasn't correct here. I can confirm the right right results now. Thanks
Fugit::Cron.parse("0 */3 * * *").next_time(t).translate('America/New_York').to_utc_time
=> 2023-10-03 21:00:00 UTC

You're welcome!


There's something wrong with Roboto-Regular.woff2

When using the file bundled with Materialize, I was getting the following error from Firefox:
downloadable font: GSUB: too large substitute: 65535 (font-family: "Roboto" style:normal weight:normal stretch:normal src index:1) source: ...

I reconverted Roboto Regular.ttf to woff2 and replaced the file and now it's working fine. I've also seen other people mentioning this on Stack Overflow.

Actually I lie, it's not fixed by regenerating the woff2 file, at least by using this tool: https://everythingfonts.com/ttf-to-woff2
I've tried several different methods of conversion, and various downloads from the web and every one shows the same issue with Roboto Regular and Roboto Light...

I get kind of the same error, when using a "™" with ALT+0153 .
downloadable font: GSUB: too large substitute: 65535 (font-family: "Roboto" style:normal weight:300 stretch:normal src index:1) source: http://localhost:64806/font/roboto/Roboto-Light.woff2 site.sass.css:5584:12 downloadable font: Layout: Failed to parse lookup subtable 0 (font-family: "Roboto" style:normal weight:300 stretch:normal src index:1) source: http://localhost:64806/font/roboto/Roboto-Light.woff2 site.sass.css:5584:12 downloadable font: Layout: Failed to parse subtable 0 (font-family: "Roboto" style:normal weight:300 stretch:normal src index:1) source: http://localhost:64806/font/roboto/Roboto-Light.woff2 site.sass.css:5584:12 downloadable font: Layout: Failed to parse lookup 0 (font-family: "Roboto" style:normal weight:300 stretch:normal src index:1) source: http://localhost:64806/font/roboto/Roboto-Light.woff2 site.sass.css:5584:12 downloadable font: GSUB: Failed to parse lookup list table, table discarded (font-family: "Roboto" style:normal weight:300 stretch:normal src index:1) source: http://localhost:64806/font/roboto/Roboto-Light.woff2

It's possible the font was updated by Google  to fix this. We'll look into updated it for next release.

I'm seeing this error also. Can I ignore it until a new version of Materialize comes out, or is this a big problem? I have no idea what the error means :)

still have bug

Still have this problem

Still have this problem

@Dogfalo I'm on the latest meteor bundle. Firefox cannot load roboto at all, it's falling back to open sans.
Here are some logs:
downloadable font: rejected by sanitizer (font-family: "Roboto" style:normal weight:normal stretch:normal src index:1) source: http://localhost:3000/packages/materialize_materialize/fonts/roboto/Roboto-Regular.woff2

downloadable font: rejected by sanitizer (font-family: "Roboto" style:normal weight:normal stretch:normal src index:2) source: http://localhost:3000/packages/materialize_materialize/fonts/roboto/Roboto-Regular.woff

downloadable font: rejected by sanitizer (font-family: "Roboto" style:normal weight:normal stretch:normal src index:3) source: http://localhost:3000/packages/materialize_materialize/fonts/roboto/Roboto-Regular.ttf

What worked for me was adding this line to main.css
@import url('https://fonts.googleapis.com/css?family=Roboto:100,400');
*Pay attention to the weights you need, like 100, 400 etc.

I´m still having this problem in my production server, but not in loca enviroment.
I tried the @keyscores  answer but still have this problem.
I'm using v 0.97.8

Fixed in 5f8b46c7de5b8ce0b11e929a271495e1806b9eb0. Update Roboto files from upstream, should have proper hinting which was causing the warnings.


Allow the specification of multiple --context flags on the command line

Codecov Report

Merging #170 into master will increase coverage by 15.82%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           master     #170       +/-   ##
===========================================
+ Coverage   76.85%   92.68%   +15.82%
===========================================
  Files          40       40
  Lines        7009     7026       +17
===========================================
+ Hits         5387     6512     +1125
+ Misses       1622      514     -1108

Impacted Files
Coverage Δ

src/main.c
74.20% <100.00%> (+63.59%)
:arrow_up:

src/string_list.c
100.00% <100.00%> (ø)

tests/check_string_list.c
100.00% <100.00%> (ø)

src/selint_config.c
78.84% <0.00%> (+0.96%)
:arrow_up:

src/lex.l
91.75% <0.00%> (+1.03%)
:arrow_up:

src/parse_fc.c
90.50% <0.00%> (+2.53%)
:arrow_up:

src/perm_macro.c
91.90% <0.00%> (+4.28%)
:arrow_up:

src/fc_checks.c
87.95% <0.00%> (+6.02%)
:arrow_up:

src/maps.c
88.25% <0.00%> (+6.81%)
:arrow_up:

src/parse_functions.c
85.59% <0.00%> (+8.35%)
:arrow_up:

... and 12 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d9256b0...c90eab6. Read the comment docs.


Create review/feedback function

consider Trustpilot or G2
Bettina: Thomas, I was wondering, would it be possible to add a “review” or “feedback function” to the tool to get people’s feedback on using Harmony? I was thinking of the standard 1-5 stars and optional additional comments section?

Google form


Typo: Update → Add as the verb used when adding new IDL files

This was copypasta, the whole point of the verb argument was to allow for this
distinction.
Fixes https://github.com/tidoust/reffy-reports/issues/22.

Oops, looks like we're running Travis for PRs in a way that'll touch the real branches and PRs. Should fix that before it messes something up.

Filed https://github.com/tidoust/reffy-reports/issues/24 and turning off Travis for PRs.


Add license file to MANIFEST.in

It would be helpful to include the license file in the source distribution

@synapticarbors  Really Thank you for your contribution 😊

Thanks for the quick review. I'm packaging turfpy for conda-forge (https://github.com/conda-forge/staged-recipes/pull/12514) and manually packaged the license file for now. Once you have a new release to pypi that includes the license file in the source distribution, I'll update the recipe. If you have any interest in co-maintaining (https://conda-forge.org/docs/maintainer/adding_pkgs.html#maintainer-role) the recipe on conda-forge please let me know. I'm happy to take care of it myself if you rather not.

Cool, Yes @sackh and I are interested in co-maintaining the recipe on conda-forge, please also add use both as maintainers 😊

@omanges, @sackh -- I've added you both as co-maintainers in the pull request

@synapticarbors Just released a new version with your changes for manifest:- https://pypi.org/project/turfpy/


Added enzyme tests and all necessary dependencies to run tests via ka…

…rma and web pack.
Can add additional tests around reversed buttons. Let me know if you have any comments or issues running. Be sure to npm install to snag all the dependencies.
You will see some React warnings in the terminal when running the tests, so this may be a good time to make this React v15 ready.
npm run test will run the tests a single time.
npm run test-watch will run the tests once and then watch test files for changes.

Thanks for your hard work :)


try adding frozen to SchemaValidator and SchemaSerializer

See if this does anything to benchmarks...
py_gc_clear wasn't implemented on any validators or serialisers, so I figured it was okay to remove it.

What do we gain? Having to use interior mutability is a bit of a pain.

I hoped/hope we could get a performance improvement. But having tried a few things, I can't see a difference.
TBH, the main point here is that both SchemaValidator and SchemaSerializer are in practice immutable, and therefore don't need to be copied when copying models etc.

If there’s no real world performance gain I’d rather keep it as is. If we could do this on a per-implementer basis that would be one thing but unfortunately it’s all or nothing with traits.

ok.


Fix #3315 Closing tag inside comment causes an error

why not 2.2 ?

This fixers does not exist in 2.2

@SpacePossum
please help with review here ;)


Added SIP Calculator

Description 📜
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.
Fixes #277

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GSSOC'22 contributor

Screenshots / Gif (Optional) 📸

if you have any questions, reach out to me on discord !


chore: release 1.2.0

:robot: I have created a release *beep* *boop*
1.2.0 (2019-08-19)
Features

adds support for multiple regions (244e21e)

This PR was generated with Release Please.

Release is at https://github.com/googleapis/nodejs-vision/releases/tag/v1.2.0

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


keepalived error: cannot find /proc on a kubernetes 1.7.2 GKE cluster

Hi I'm trying to get keepalived working (using [1]) on a kubernetes 1.7.2 cluster but the pods all enter into a CrashLoopBackOff state with the following error:
F0810 20:55:48.149657       1 main.go:103] unexpected error: open /proc/sys/net/ipv4/vs/conntrack: no such file or directory
goroutine 1 [running]:
k8s.io/contrib/keepalived-vip/vendor/github.com/golang/glog.stacks(0x1d9fd00, 0xc400000000, 0x7d, 0xd1)
	/usr/local/google/home/beeps/goproj/src/k8s.io/contrib/keepalived-vip/vendor/github.com/golang/glog/glog.go:766 +0xa5
k8s.io/contrib/keepalived-vip/vendor/github.com/golang/glog.(*loggingT).output(0x1d7f800, 0xc400000003, 0xc420067980, 0x1d19f9b, 0x7, 0x67, 0x0)
	/usr/local/google/home/beeps/goproj/src/k8s.io/contrib/keepalived-vip/vendor/github.com/golang/glog/glog.go:717 +0x337
k8s.io/contrib/keepalived-vip/vendor/github.com/golang/glog.(*loggingT).printf(0x1d7f800, 0x3, 0x14ff936, 0x14, 0xc420655e78, 0x1, 0x1)
	/usr/local/google/home/beeps/goproj/src/k8s.io/contrib/keepalived-vip/vendor/github.com/golang/glog/glog.go:655 +0x14c
k8s.io/contrib/keepalived-vip/vendor/github.com/golang/glog.Fatalf(0x14ff936, 0x14, 0xc420655e78, 0x1, 0x1)
	/usr/local/google/home/beeps/goproj/src/k8s.io/contrib/keepalived-vip/vendor/github.com/golang/glog/glog.go:1145 +0x67
main.main()
	/usr/local/google/home/beeps/goproj/src/k8s.io/contrib/keepalived-vip/main.go:103 +0x5a2

Do I need to mount /proc into the containers?
[1] - https://github.com/kubernetes/contrib/tree/master/keepalived-vip

Anyone have an idea about this? This is on a default, GKE 1.7.2 cluster.

Because k8s node machine lack of 'conntrack' modules, the keepalived-vip pod 'changeSysctl' method raise an error.
Modify default k8s node image to install 'conntrack' may fix the problem, or simply upgrade the whole k8s cluster version (1.10.4-gke.0 version work!).


Envelop - New website

@B2o5T
Open issues:

[x] Not sure what to do with Plugin Hub tab, the same as Docs?
[x] FeatureList component have gap that too big. (Thinking also InfoList, this is in the theme? all gaps between component is too big)
[x] Should add Tooltip component to table in integrations doc
[x] Fix CI failures
[x] Missing subtitle

TODO:

[ ] Add website pipeline @dotansimha
[ ] merge https://github.com/the-guild-org/the-guild-components/pull/472 and release @dotansimha
[ ] Add missing repo secrets  @n1ru4l
[ ] test preview


pixi install --locked does not abort as expected

Checks

[X] I have checked that this issue has not already been reported.

[X] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example
(myenv) (rc: 0) $ pixi install --locked
  × lock-file not up-to-date with the project

(myenv) (rc: 0) $ pixi install --locked
✔ The default environment has been installed.
(myenv) (rc: 0) $

[project]
name = "test"
version = "0.1.0"
description = "Add a short description here"
channels = ["conda-forge"]
platforms = ["linux-64"]

[tasks]

[dependencies]
quarto = ">=1.4.550,<2,!=1.4.557"

I don't think the specific TOML matters here, just trying to comply with the form :) It just matters that the TOML changes in a way that breaks compatibility with a lock file, for example increasing the minimum version or excluding a version as I've done above, after locking.
Issue description
The help text for pixi install shows the --locked option as a check that aborts early when a lock-file is found to not comply with the manifest. This doesn't require an environment solve, so could be used in CI or pre-commit hook to quickly identify when a contributor forgot to commit the lockfile. However, when the lock file is found to be out of date, the command does not abort as described, and continues on to update the lockfile.
      --locked                                         Check if lockfile is up-to-date before installing the environment, aborts when lockfile isn't up-to-date with the manifest file [env:
                                                       PIXI_LOCKED=]

Expected behavior
I expect the command to abort (personally, I intuited a non-zero return code would be returned) immediately after detecting
Thank you :tada: :heart:
I'm a new pixi user, and as I've been telling my colleagues since yesterday, I think the design you're bringing to the conda userbase is revolutionary. I hope you don't mind an inline experience report. I didn't see an issue type for this. I work with researchers a lot, and I've dreamed of these things. Thank you! I am super impressed with these changes, as they resolve ways that I feel the traditional conda user experience would get in the way of the work researchers want to do:

Automatically handles building a sensible manifest and lock file from install commands. This is huge - for many, the importance of repeatability is understood, but the number of little things you need to remember to properly define a repeatable environment.yml is a lot. :bow:
Treats projects as the top-level "thing" instead of environments. It's so easy for researchers to install Anaconda and then start conda installing things into the base environment and get in to trouble later. Because projects are the entrypoint to using pixi, and there is no base environment, isolated environments are the default. Because environments are stored in a local directory, and activated based on current working directory, remembering environment names isn't a struggle and cleaning environments up can be done with regular OS-level tools. "I broke my conda install, can I re-install miniconda and keep my environments?" is a super common user experience in traditional conda. Yuck! :bow:

Hi @mfisher87, thanks for the kind words and good to see we're working on the right things!
The issue you describe is indeed a bug, but I can't seem to reproduce it. For my it only aborts and does that repeatably.
Could you specify exactly a reproducible state between two pixi tomls

One state that is installed and compatible with the lock file
One state that would be the second step and is not compatible with the lockfile.

Note that a lockfile can be in sync when adding dependencies or changing the version as long as the version specification is compatible and the package is already in the lockfile.

I can't reproduce this anymore! :scream:
I can tell you that the file pasted above is the "after" version, and the "before" version I tested yesterday had the !=1.4.557 specification omitted. But given that I can't reproduce today, there must have been some other variable involved. I'll post back if I ever find another reproduction :)
Thanks so much for your time, and apologies for the incorrect report!


Update loofah

Description of changes

Updates loofah dependency due to vulnerability.
Issue Resolved

Fixes # Undocumented issue, but some alert in the repo.

Yup, I agree with you. I messed up my branching and didn't notice it.

LOL


[HUDI-5038] Increase default num_instants to fetch for incremental source

Change Logs
By default, the default maximum number of instants to fetch in incremental source (hoodie.deltastreamer.source.hoodieincr.num_instants) is 1.  The checkpoint of the target Hudi table from the incremental ETL lags behind the source if the ingestion runs at a lower frequency than the source or the ingestion job stalls for some time, causing the data freshness issue.
This PR increases default num_instants to 5 so that the incremental ETL can fetch more instants to catch up with the source.
Impact
Only in the cases mentioned above, more instants are fetched for catchup.
Risk level: low
Documentation Update
N/A.  The default value is automatically updated on the Hudi website once the website is built for a new release.
Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

@yihua : there are some valid test failures that needs to be fixed.
can you check that.


Fix company_name parser

As I read your code and use it in my project, I'd scan some specialized region like Iranian users and it failed so much times! and find-out that the company_name always equal to universalName(especially in other language like Arabia or Persian. thanks for sharing the code.

PM: It'll fix the FALSE POSITIVE of company not found

we dont use that company_name that you changed in this. maybe you changed in the wrong spot. but this is still a good change as is.


DNA-based loading animation

Resolved (in master branch) by 8b01ddba6502cf83eb1b875d141ba7080c8fef3b. Probably won't implement for oldLoader


Moonrider performance investigation

I've been looking at some generic Three.js / A-Frame performance improvements related to updateMatrixWorld()
See: https://github.com/mrdoob/three.js/pull/25142 for background.
@dmarcos suggested I look at the impact these changes would have on Moonrider, as the most popular WebXR experience.  I've raised this issue to document that investigation.
Initial Results
I did some quick profiling of Moonrider on Windows/Chrome (easier environment than a VR headset), and found it was spending > 70% of CPU inside updateMatrixWorld() suggesting it would be a great candidate for optimization.

A quick console check revealed 2902 objects in the scene graph:
count = 0; document.querySelector('a-scene').object3D.traverse((o) => count++ ); count
2902

Moonrider runs against A-Frame 1.1.0, so I back applied the changes in 25142 to THREE.js r123.1 and used this to build a modified version of A-Frame 1.1.0.
Three.js: https://github.com/diarmidmackenzie/three.js/tree/super-r123-1-performance
A-Frame: https://github.com/diarmidmackenzie/aframe/tree/1.1.0-performance
I then modified Moonrider to run using this verson of Three.js.
It seems to be running fine with this updated version.  However, the performance gains are not as remarkable as hoped.

updateMatrixWorld now uses about 55% of CPU.
bear in mind that as CPU usage of updateMatrixWorld() goes down, the frame rate should go up,
so this could be read as a ~50% perf gain - the "other stuff" has gone from using 30% of CPU up to using 45% of CPU.
one would hope that would be accompanied by a ~50% increase in frame rate, but I don't have hard evidence for that yet... (I've focussed on CPU data rather than frame rate so far).

Nevertheless, the reduction from 70% to 55% was less than see with other apps.  I'll explain why that is...
Why only small gains?
Of the 2902 objects in the scene graph, a console query shows that we are skipping matrix calculations for just 446 of them (about 15%).
objs = []; document.querySelector('a-scene').object3D.traverse((o) => {if (o.privateMatrixData !== o.matrixData) { objs.push(o) }}); objs.length
446

There's a few reasons for this:

A-Frame changes will only affect object3Ds create by geometry, gltf-model & obj-model.  Moonrider has various bits of custom code that could also be adjusted to skip matrix calculations for more objects.
There seem to be a lot of GLTF objects with ~10 parts each (e.g. for broken blocks).  These won't result in much optimization: we will retain a separate matrix for each of the 10 parts, and only skipone matrix at the root of the object model.

However there does seem to be some substantial scope to optimize performance further...
How to optimize further
As things stand, we have a lot of objects in the scene graph with distinct matrix data.  Since we can't ignore non-identity matrices without compromising the experience, to optimize further, we'd need to significantly reduce the number of objects in the scene graph.
It looks as though most of the objects in the scene graph are inactive pool objects.  My understanding is these pools exist to minimize performance issues when spawning new objects - instead of creating new objects from scratch, they get switched in from a pool.
These pools of objects are the reason why there are 2902 objects in the scene graph, even when there isn't that much going on on screen.  They are invisible, so they don't have any impact on rendering performance, but they are still a part of the scene graph, which means they each have to be processed every frame in updateMatrixWorld() even though they aren't visible.
It could be tempting to suggest that updateMatrixWorld() should skip over non-visible objects, but there are good reasons to ensure that non-visible objects are correctly positioned, as non-visible objects can be used as colliders, raycasted against etc.
However these objects, when resting in pools don't need to have their matrices updated every frame.  The simplest way to avoid these updates would be to simply remove these objects from the scene graph when they are sitting unused in a pool.
I believe this would be a simple change, that would substantially improve the performance of Moonrider.  The performance overhead of adding an object3D back into the scene graph when activating it from a pool should be minimal, just a couple of matrix multiplications.
However I have held back from making any changes to moonrider code itself, due to some GitHub issues.
Issues with moonrider repo
I'm hitting an error when cloning the moonrider repo:
Downloading assets/img/envmap.psd (604 KB)
Error downloading object: assets/img/envmap.psd (0837264): Smudge error: Error downloading assets/img/envmap.psd (0837264a7ea743565218b35ee8cd4f5b2244810963a2de0a3c2d75a84dc35553): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

This error means I've not been able to set up any version control locally for the moonrider code.  I've tried making a couple of changes along the lines above, but working without version control in an unfamiliar codebase is not an ideal situation...
I can come back and look at application-level optimizations (where I think there's lots of potential), when I have a working version control setup...
For the same reason, I haven't published a live version that uses the latest A-Frame yet.
Next steps & resources
To use the version of A-Frame with performance improvements, update the A-Frame version loaded in index.html to this:
<script<EMAIL_ADDRESS>
Next steps:

application-level optimizations (once I'm able to cleanly clone the repo)
analyze FPS improvements, from existing & future fixes.

On further review, it turned out the best place to make the further changes was in the A-Frame pool component, so no application changes needed (apart from pointing to the newer A-Frame).
This fix (much simpler than all the other stuff I have been working on!)
We've now got total CPU for updateMatrixWorld() down to 35%, less than half of what it was when we started.

FPS on my Windows PC is definitely up from 55, now very close to 60.  It's capped at 60 on PC, I believe, and still misses sometimes, so everything's not perfectly smooth still, but the overall CPU load must e substantially reduced.

Managed to do some testing on Quest 2, using the OVF Metrics Tools described here:
https://developer.oculus.com/documentation/unity/ts-ovrmetricstool/#collect-performance-data-with-ovr-metrics-tool
I played Ed Sheeran, Shape of You, hitting more-or-less all the blocks (I believe block fragments are more intesive to render than blocks).
Here's a FPS chart from the original (https://moonrider.xyz)

In this version frame rate was ~flat at 44-45 FPS
And here from a fixed version (https://diarmidmackenzie.github.io/moonrider)

In this version Frame rate did sometimes dip as low as 45FPS, but was much ore variable, and sometimes a lot higher.
So on average, the frame rate was considerably better, but still highly variable.
I tried to also record data to file, which would allow for a more detailed analysis, but haven't yet figured how to access the data (supposedly it's written to csv files in: /OVRMonitorMetricsService/CapturedMetrics/ but I can't see any such files on my headset).

I didn't notice any functional deficiencies in the updated version - seemed to be running absolutely fine.

CPU usgae data...
old..

new...

So we're seeing the expected gains in updateMatrixWorld().
Big difference between running on VR headset & on my PC is that on PC the punchable blocks don't get rendered, so I wasn't seeing the cost of that in my earlier analysis.  Looks like the cost of rendering those blocks is now the dominant factor in overall performance terms.
I suspect savings can be made there, but probably needs to be done at the application level, e.g. using instancing for the blocks?

Came across discussion about this in the WebXR discord and thought I'd mention that one thing I did for my rhythm game (https://github.com/CadenzaVR/cadenza) is to use InstancedMesh for each unique note type. So I just have one mesh/object for each note type instead of one for each note.

Thanks, yes, using instancedMesh should give some decent performance gains.
Using aframe-instanced-mesh should allow this to be done without too much reworking of the existing code.


Convert logger test to Typescript

Converted test/logger.test.js into typescript

Thanks for the suggestions , will apply the changes and submit another PR

added the proposed changes @tcbyrd

Looks good. Thanks @yawningphantom!


[bug] Qwik: Serviceworker not installed correctly

Describe the bug
After creating a new tauri + qwik app following the official guide and creating a production build with --debug flag, i get the following error in the console:
TypeError: serviceWorker.register() must be called with a script URL whose protocol is either HTTP or HTTPS
After adding SSG mode to qwik, i got the following notice: " You must change the 'origin' url under staticAdapter inside 'vite.config.ts'"
The default value is: "origin: 'https://yoursite.qwik.dev'", i tried setting it to some other urls, but all resulted in the same error after building the app.
What is the correct value for the origin property or did i make any other mistake (im new to qwik...)?
Reproduction

Follow https://tauri.app/v1/guides/getting-started/setup/qwik
npm run tauri build -- --debug
Start app and check console output

Expected behavior
The qwik service worker should be installed without errors
Platform and versions
[✔] Environment
    - OS: Ubuntu 22.04 X64
    ✔ webkit2gtk-4.0: 2.38.6
    ✔ rsvg2: 2.52.5
    ✔ rustc: 1.68.0 (2c8cc3432 2023-03-06)
    ✔ Cargo: 1.68.0 (115f34552 2023-02-26)
    ✔ rustup: 1.25.2 (17db695f1 2023-02-01)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 19.8.1
    - npm: 9.6.5

[-] Packages
    - tauri [RUST]: 1.3.0
    - tauri-build [RUST]: 1.3.0
    - wry [RUST]: 0.24.3
    - tao [RUST]: 0.16.2
    - @tauri-apps/api [NPM]: not installed!
    - @tauri-apps/cli [NPM]: 1.3.1

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:5173/
    - bundler: Vite

Stack trace
TypeError: serviceWorker.register() must be called with a script URL whose protocol is either HTTP or HTTPS

Additional context
No response

I think setting the origin to 'https://tauri.localhost' should do the job (this is the url from other resources used by the app), but for some reason it doesn't work...
When running npm run preview, to view the app in the browser the service worker is installed without errors.

I think setting the origin to 'https://tauri.localhost/' should do the job (this is the url from other resources used by the app), but for some reason it doesn't work...

This is only the origin on Windows. macOS and Linux use tauri://localhost and switching to a http protocol is not possible without an actual http server, like with the localhost plugin (ref https://github.com/tauri-apps/wry/issues/389).
That said, i wonder if this is actually an issue like, what does qwik use the service worker for? Because at least the demo app seems to work completely fine...

After creating a new tauri + qwik app following the official guide

Can't wait for the new docs website where we will make this more clear, but the qwik guide is not really official, but more like a community-provided guide.

Oh okay, i will try the localhost plugin.
As far as i know qwik uses the service worker to prefetch and cache JavaScript which might be needed soon, so that the network request don’t slow down the app. So using qwik + tauri without a service worker probably isn’t a big issue, since fetching the JavaScript is instant anyway without a preload/cache. But maybe the service worker does more idk.

Well, there isn't anything we can do i think. So i'll go ahead and close this. At least it's now documented here with a few pointers so, thanks for the report :) (and we can reopen it in case there will be more issues)

The service worker works with the localhost plugin, when you set the origin to http://localhost. I will do some more testing, if the service worker is required for a tauri application and submit a pr for the docs if necessary.

Hi @qwerty084 ,
I am trying to register the firebase-messaging.js service worker. Could you please explain how did you get this work.
I have setup the localhost plugin and My service worker is registered but gives the error NotAllowedError : permission denied.


Change the highlight color of the map point tool in dark theme

The expected color should be

This is based on the snapping option when it is turned on the bottom of this image:

Due to the challenge that we currently understand about dark theme has kept this as being a issue. Currently we have ArcMap and ArcGIS Pro pulling from the same source code and that could be affecting if we can get these buttons to match what we would expect for a fully supported dark theme.


Introduce Raw XML Editor Interface

Introduce Raw XML Editor to allow editing parts which are not supported by the visual interface so far. This needs scope and specification. After each edit session we must ensure JATS4M is fulfilled, otherwise need to throw an error.

We won't do that, instead we will expose all relevant attributes as fields in the metadata section.


Update index.md

Im trying to create my own portfolio. Just trying to update the basics and see if its working,


openssl command not found

I am attempting to install the agent on a Kubernetes cluster in an offline environment. I had obtained my DevOps SSL certificate and entered in the configMap like the documentation suggests in the advanced section of the docs. However, when running a helm install it prints:
"Adding custom SSL certificates"
"Searching for *.crt in /app-root/azp-custom-certs"
finds my one cert then errors with
"start.sh: line 91: openssl: command not found"

If I understand well, OpenSSL executable is not resolved/installed on the container. This seems 100% a bug.
Can you give the flavor you’re using and its version/hash?

I was on a RHEL8 machine using ubi8-7.0.0 and the hash should be index digest sha256: fd2d3dd2224200490866339b9c207b59f7d0cc5102315c7099e68191e566f427
I also tried using ubi8-latest around the same time as the ubi8-7.0.0 but I have since deleted that image and no longer have the hash for it apologies.

Related: https://repo1.dso.mil/dsop/redhat/ubi/8.x/ubi8/-/issues/34

Fixed with 4a44d2cac0b041895aadcc8afa1c1d2e3a7e168b.
Will be on the v7.0.1!

v7.0.3 is out, is includes the correction.

Please reopen if it shows again! I'll invest time to add that in test cases (will be time consuming).


Image is not accessible in responsive_header

Describe the Feature you want to end
Add the image in navbar.
Expected behavior
So it look more attractive.
** Screenshot**

Additional context (optional )
I want to work on this issue. Please assign this issue to me

i want to work on the issue of image on navbar . Kindly assign it to me


Dask failing when attempting to run combine_preprocessing

Using the new combined_preprocessing approach I've found I'm unable to get any sort of parallelisation happening.  Any attempt to run any combined_preprocessing methods when connected to a cluster fails immediately with:
`/srv/conda/envs/notebook/lib/python3.8/site-packages/blinker/base.py:93: DeprecationWarning: invalid escape sequence *
"""Connect receiver to signal events sent by sender.
KilledWorker                              Traceback (most recent call last)
/srv/conda/envs/notebook/lib/python3.8/site-packages/intake_esm/merge_util.py in _open_asset(path, data_format, zarr_kwargs, cdf_kwargs, preprocess, varname, requested_variables)
314         try:
--> 315             ds = preprocess(ds)
316         except Exception as exc:
/srv/conda/envs/notebook/lib/python3.8/site-packages/cmip6_preprocessing/preprocessing.py in combined_preprocessing(ds)
459     # sort verticies in a consistent manner
--> 460     ds = sort_vertex_order(ds)
461     # convert vertex into bounds and vice versa, so both are available
/srv/conda/envs/notebook/lib/python3.8/site-packages/cmip6_preprocessing/preprocessing.py in sort_vertex_order(ds)
397
--> 398         lon_b = ds.lon_verticies.isel(x=x_idx, y=y_idx).load().data
399         lat_b = ds.lat_verticies.isel(x=x_idx, y=y_idx).load().data
/srv/conda/envs/notebook/lib/python3.8/site-packages/xarray/core/dataarray.py in load(self, **kwargs)
928         """
--> 929         ds = self._to_temp_dataset().load(**kwargs)
930         new = self._from_temp_dataset(ds)
/srv/conda/envs/notebook/lib/python3.8/site-packages/xarray/core/dataset.py in load(self, **kwargs)
864             # evaluate all the dask arrays simultaneously
--> 865             evaluated_data = da.compute(*lazy_data.values(), **kwargs)
866
/srv/conda/envs/notebook/lib/python3.8/site-packages/dask/base.py in compute(*args, **kwargs)
566
--> 567     results = schedule(dsk, keys, **kwargs)
568     return repack([f(r, *a) for r, (f, a) in zip(results, postcomputes)])
/srv/conda/envs/notebook/lib/python3.8/site-packages/distributed/client.py in get(self, dsk, keys, restrictions, loose_restrictions, resources, sync, asynchronous, direct, retries, priority, fifo_timeout, actors, **kwargs)
2675             try:
-> 2676                 results = self.gather(packed, asynchronous=asynchronous, direct=direct)
2677             finally:
/srv/conda/envs/notebook/lib/python3.8/site-packages/distributed/client.py in gather(self, futures, errors, direct, asynchronous)
1984                 local_worker = None
-> 1985             return self.sync(
1986                 self._gather,
/srv/conda/envs/notebook/lib/python3.8/site-packages/distributed/client.py in sync(self, func, asynchronous, callback_timeout, *args, **kwargs)
830         else:
--> 831             return sync(
832                 self.loop, func, *args, callback_timeout=callback_timeout, **kwargs
/srv/conda/envs/notebook/lib/python3.8/site-packages/distributed/utils.py in sync(loop, func, callback_timeout, *args, **kwargs)
339         typ, exc, tb = error[0]
--> 340         raise exc.with_traceback(tb)
341     else:
/srv/conda/envs/notebook/lib/python3.8/site-packages/distributed/utils.py in f()
323                 future = asyncio.wait_for(future, callback_timeout)
--> 324             result[0] = yield future
325         except Exception as exc:
/srv/conda/envs/notebook/lib/python3.8/site-packages/tornado/gen.py in run(self)
761                     try:
--> 762                         value = future.result()
763                     except Exception:
/srv/conda/envs/notebook/lib/python3.8/site-packages/distributed/client.py in _gather(self, futures, errors, direct, local_worker)
1849                         else:
-> 1850                             raise exception.with_traceback(traceback)
1851                         raise exc
KilledWorker: ('open_dataset-15050f301698f08248a31d25e33359c8lat-59b5685f299af92245d0b1cb37020a01', <Worker 'tls://<IP_ADDRESS>:42546', name: dask-worker-2e60963dbc254823a8cfaee8afce3a6f-xzzn4, memory: 0, processing: 1>)
`
The same code will run perfectly when not connected to the cluster.  Example code below, I've tested with several models, finding the same error for each, and on two different Pangeo deployments.
'!pip install git+https://github.com/jbusecke/cmip6_preprocessing.git --upgrade
!pip install git+https://github.com/pydata/xarray.git --upgrade
import cmip6_preprocessing.preprocessing as cpp
import cmip6_preprocessing.postprocessing as c_pp
from cmip6_preprocessing.utils import google_cmip_col
import warnings
warnings.filterwarnings(action='once')
create and connect to cluster
from dask_gateway import Gateway
from dask.distributed import Client
gateway = Gateway()
cluster = gateway.new_cluster(worker_memory=6)
cluster.scale(10)
client = Client(cluster)
client
#import data
col=google_cmip_col()
models='CNRM-ESM2-1'
experiment_id='ssp585'
cat_data = col.search(
require_all_on=["source_id"],
variable_id=['so','thetao','vmo','vo'],
experiment_id=experiment_id,
grid_label='gn',
table_id='Omon',
source_id=models)
kwargs= {
'zarr_kwargs':{
'consolidated':True,
'use_cftime':True
},
'aggregate':False,
'preprocess':cpp.combined_preprocessing
}
ddict = cat_data.to_dataset_dict(**kwargs)'
The same error occurs when I run other preprocessing methods.   I guess I could do all my preprocessing before creating a cluster, but this is sub optimal for my workflow, particularly as I'd like to later run the much maligned replace_x_y_nominal_lat_lon in order to make some regional selections!

Hi @Recalculate, thanks for raising this issue. Sorry for the trouble with cmip6_preprocessing.
Just to check a few things here. Does this only happen on the latest xarray version? v0.19.0 seems to have broken a bunch of stuff. I am working on a hotfix right now.
Can you confirm that loading the data (calling .to_dataset_dict()) with preprocess=None does indeed work with dask?
If both of the above dont give any clear indications of what is broken, I am happy to look into this further.

particularly as I'd like to later run the much maligned replace_x_y_nominal_lat_lon in order to make some regional selections!

I still believe that the code in there has a bug. So please use at your own risk!

So from a quick look it seems that the issue in #173 is mostly related to the tests and the basin-masking functionality. Nothing that impacts preprocessing as far as I can tell.
I remembered I did have some issues from time to time to use intake-esm with dask clusters, so I would be curious to whether this also happens with deactivated preprocessing.
Also pinging @andersy005

Thanks for following up.  I can confirm that it appears to be the xarray version.  The above code works just fine for:
!pip install<EMAIL_ADDRESS>but breaks for
!pip install<EMAIL_ADDRESS>Though given we are now up to xarray v0.19.0 I wonder how this has not been noticed before?
Further testing shows that
'ddict = cat_data.to_dataset_dict(**kwargs)'  works fine with xarray v0.18.0 if preprocessing is set to none, but any subsequent operations on ddict that require accessing data, such as .plot(), will give the same cluster error.
So it seems to be more an error with the interaction of xarray with dask than cmip6_preprocessing.

Though given we are now up to xarray v0.19.0 I wonder how this has not been noticed before?

These are quite complex 'full stack' workflows, which are really hard to test comprehensively. I wonder if we can add a test specific to this sort of workflow to the Cloud CI.
Just to check: Did you make sure that you did not install a dask version on the notebook that is different from dask on the workers? You can check this by comparing:
import dask
dask.___version__

and
client.get_versions(check=True)

The latter will give you the version of dask/distributed that is running on the workers. If those are not the same, some really funky stuff can happen. Some more explanation here: https://stackoverflow.com/a/54452458
If those are all the same we will have to dig a little deeper:
Here are some further steps to debug:

Try to find a single dataset that continously fails. Then extract the raw zarr store from the dataframe cat_data.df['zstore'].tolist().
Load this dataset with xarray.from_zarr() and try to plot with/without cmip6_pp and with/without the dask cluster. If this still fails the problem is further upstream (e.g. some of the zarr stores might not be available? If this both works, I would more strongly suspect intake-esm to be the culprit.

I've checked that the dask version on the notebook and cluster are the same, so that isn't it.
I can also confirm that using xarray v0.17.0 I can complete all cmip6_pre and post processing steps, and perform complex distributed operations.  Problems only arises once I use versions >0.17.0.
I'll have a go at the next debugging step tomorrow.  Getting quite late here!

Ok I think I got this figured out. It is the xarray version that needs to be aligned too!
The workers have 0.17.0 installed by default. If you update only the version in the notebook I can reproduce the failure both with a super simple example + one with cmip6_pp and intake-esm.
Check out this little demo: https://gist.github.com/jbusecke/d0da9998f19d235852e7a96d484f3f9b
Please let me know if this way of updating the xarray version on your workers solves this problem.

Success!  Thanks very much for this.  Also, for future reference it seems that having a cluster with v0.16.2 is compatible with a notebook with v0.17.0, but if you go past this it breaks!  I've got it working smoothly with v0.19.0 on both now. Thanks very much for your hard work on this!

No problem, I actually ended up facing the same issue yesterday hehe. Can we close this?

FYI @Recalculate: https://twitter.com/jrbourbeau/status/1420199883395506176?s=20
I am going to close this for now, feel free to reopen if needed.


Add Content to Fun Facts Page

Add some content in the page called "Fun Facts" (located at "/fun-facts/facts"). Please provide references as well.
Feel free to make any adjustments you may like.
VitePress Docs: https://vitepress.dev/

hey @SanditZZ  assign me this issue


SuperProductivity install fails

after installing, windows tries to create some shortcuts but fails. The superproductivity exe is nowhere to be seen. If I install superproductivity manually though one of the EXEs from the github releases, it works fine

Still an issue today. Can't install the .exe directly as it is a portable version, the microsoft store is buggy if you keep the option to go to taskbar if closed. Windows is definitely not the intended OS for the app 😂

Can't install the .exe directly as it is a portable version

Make a folder for it in Program Files, and then make a shortcut in the startup folder.

Can't install the .exe directly as it is a portable version

Make a folder for it in Program Files, move the exe there, and then make a shortcut for it and place it in the startup folder.

Oh sorry I might have explained myself poorly.
Yes it works this way, but if you pin the executable to the taskbar, it'll open another one when launching.
And if you open the one that launched afterward, it won't be able to open up on next boot because it was just a temp shortcut.
Hence the issue on my end ! But thanks, it'll help people 💪

Hi everyone,
I have updated the package in order to correct the issue you mentioned.
It should be fixed since the package version <IP_ADDRESS>31228 (package link).
Feel free to test that out, when you will have the time and give me some feedback 😊
Have a nice day

Hi, @Xav83 ,
Thank you very much. Now, everything works correctly. On my Windows 11 x64 OS, SuperProductivity is updated successfully.

Can confirm, the installation works fine now. Finally, we can ditch the Microsoft Store version ! Thanks !
Can be closed I guess.

Hi everyone,
I have updated the package in order to correct the issue you mentioned. It should be fixed since the package version <IP_ADDRESS>31228 (package link).
Feel free to test that out, when you will have the time and give me some feedback 😊 Have a nice day

Can confirm, the installation works fine now. Finally, we can ditch the Microsoft Store version ! Thanks !
Can be closed I guess.
EDIT : When you pin SupProd to the taskbar and have the stay minimized to tray option activated, if you close SupProd, you can't open it back from the pinned taskbar icon. You need to click on the tray icon.

Thank you @mathisgauthey for your feedback :slightly_smiling_face:

EDIT : When you pin SupProd to the taskbar and have the stay minimized to tray option activated, if you close SupProd, you can't open it back from the pinned taskbar icon. You need to click on the tray icon.

This issue may come from the SuperProductivity installer itself, since Chocolatey only runs the installer provided by @johannesjo, the software author of SuperProductivity. So you should probably report it on super-productivity github repository :wink:


WIP: Add PlaceController

Closes #223

Codecov Report

Merging #364 (ac2cd4c) into main (34f042b) will decrease coverage by 0.45%.
The diff coverage is 11.76%.

@@            Coverage Diff             @@
##             main     #364      +/-   ##
==========================================
- Coverage   93.70%   93.24%   -0.46%
==========================================
  Files          55       56       +1
  Lines        2606     2621      +15
  Branches      334      335       +1
==========================================
+ Hits         2442     2444       +2
- Misses        125      138      +13
  Partials       39       39

Impacted Files
Coverage Δ

pyinaturalist/controllers/observations.py
85.71% <ø> (ø)

pyinaturalist/controllers/places.py
0.00% <0.00%> (ø)

pyinaturalist/docs/templates.py
100.00% <ø> (ø)

pyinaturalist/v1/places.py
100.00% <100.00%> (ø)

pyinaturalist/docs/signatures.py
98.33% <0.00%> (+3.33%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 34f042b...ac2cd4c. Read the comment docs.


Support for CSharp 9

Record types
Init accessor (?)

I'll add another to the list:

Map System.IntPtr and System.UIntPtr to the new type keywords nint and nuint (?)

This is debatable. System.IntPtr has traditionally been used to represent an unmanaged pointer in interop scenarios. nint doesn't transport those semantics quite as well, it looks more like any regular integer type. I am not sure what we should do about these keywords.

Init accessor

This would be reasonably straightforward as the setter's return type gets annotated with a System.Runtime.CompilerServices.IsExternalInit modreq.
This would be a prerequisite for...

Record types

Sensible support for record is currently very difficult for several reasons:

There is no officially sanctioned way of distinguishing records from classes (see https://github.com/dotnet/csharplang/issues/4121). We can infer record from the presence a method named <Clone>$, but that is likely implementation-specific to the Roslyn compiler.

The compiler provides default implementations for a whole bunch of methods if user code doesn't provide them. Ideally, we would filter those out in the generated output. Unfortunately, that isn't feasible, as it is currently impossible to distinguish compiler-generated from user-provided methods; see https://github.com/dotnet/roslyn/issues/47613#issuecomment-755202607.

I think we should start by focusing on init-only setters.

I'll add another to the list:

Map System.IntPtr and System.UIntPtr to the new type keywords nint and nuint (?)

This is debatable. System.IntPtr has traditionally been used to represent an unmanaged pointer in interop scenarios. nint doesn't transport those semantics quite as well, it looks more like any regular integer type. I am not sure what we should do about these keywords.

Init accessor

This would be reasonably straightforward as the setter's return type gets annotated with a System.Runtime.CompilerServices.IsExternalInit modreq.
This would be a prerequisite for...

Record types

Sensible support for record is currently very difficult for several reasons:

There is no officially sanctioned way of distinguishing records from classes (see https://github.com/dotnet/csharplang/issues/4121). We can infer record from the presence a method named <Clone>$, but that is likely implementation-specific to the Roslyn compiler.

The compiler provides default implementations for a whole bunch of methods if user code doesn't provide them. Ideally, we would filter those out in the generated output. Unfortunately, that isn't feasible, as it is currently impossible to distinguish compiler-generated from user-provided methods; see https://github.com/dotnet/roslyn/issues/47613#issuecomment-755202607.

I think we should start by focusing on init-only setters.

As of 5/17/2022, Visual Studio 17.2.1 and/or SDK 6.0.300 uses the CompilerGenerated attribute for more methods of record types which changes the output of PublicApiGenerator.  See:

https://github.com/dotnet/roslyn/issues/47613
https://github.com/dotnet/roslyn/pull/58542

In my application, these methods of record types are not listed anymore in the output:

Deconstruct
Equals (both typed and object overload)
GetHashCode
ToString
operator !=
operator ==

Also see #247

As with IntPtr vs. nint (see above), I am also wondering whether record types should actually be rendered using the record keyword or simply as the class-es that they really are... see also the discussion at https://github.com/dotnet/csharplang/issues/4121#issuecomment-731660563. Any opinions on this?

I think that no one wants to see all that internal default stuff for records : <Clone>$, PrintMembers, etc. I would like to see only overridden methods and record keyword instead of class.

Actually all that stuff is filtered out now by CompilerGenerated attribute. OK. Another argument - what if one has switched from record to class or vice versa? It can be a breaking change for consumers that override some method so I would like to see when it happens.

  // in core library
        public record User(string login, string password); // switch to User1

        public class User1 : System.IEquatable<User1>
        {
            public User1(string login, string password) { }

            public string login { get; init; }

            public string password { get; init; }
        }

        // in some external library
        public record Admin(string login, string password) : User(login, password)
        {
            protected override bool PrintMembers(StringBuilder builder) // BOOM after swithing from record to class for User
            {
                builder.Append("BlaBlaBla");
                return base.PrintMembers(builder);
            }
        }

Well, I found a bug. See PublicApiGeneratorTests.Record. This test has wrong expectedOutput if we treat User as class (for now we do). It should contain public bool Equals(User other) but this method is filtered out by CompilerGenerated attribute. The fix for that situation - switch class keyword to record!


[Feat]: Verbose Option to relaxer

Contact Details
No response
Feature Description
relax function of the Relaxer object can have a boolean parameter verbose to let user to print out or suppress the energy and fmax values at each step of relaxation.
Motivation
For a stream lined application, screen output of relaxation steps can be too much to monitor. In that case user may choose to suppress these.
Proposed Solution
In relax.py :
stream = sys.stdout if verbose else io.StringIO()
with contextlib.redirect_stdout(stream):
optimizer = self.optimizer(ecf, **kwargs)
optimizer.run(fmax=fmax, steps=steps)
and of course at function def line:
def relax(
    self,
    atoms: Atoms,
    steps: int = 500,
    fmax: float = 0.01,
    params_filter: dict = {},
    verbose: bool = True,
    **kwargs,
) -> Atoms:

also import necessary modules:
import sys
import contextlib
Contribution Interest

[x] I'm interested in potentially implementing this feature
[ ] I can provide guidance, but cannot implement
[ ] I'm just suggesting the feature for the community

Code of Conduct

[x] I agree to follow the project's Code of Conduct

Dear @dundar11,
Thank you for suggesting this feature! We warmly welcome contributions from the community. Please feel free to submit a pull request once you have implemented this feature. Thank you!
Best regards,
Han


Counter logs successful send despite failure when SLF4J logger missing

When there's no SLF4J logger implementation on the classpath, the Zipkin log_span counter logs a successful send when it's actually failing due to a NoClassDefFoundException.  Using a simple console StatsReceiver with no logger implementation, the output is as follows:
Counter HttpServer:connects = 1
Counter HttpServer:received_bytes = 149
Counter HttpServer:requests = 1
Stat HttpServer:handletime_us = 61161.0
Stat HttpServer:request_latency_ms = 4.0
Counter HttpServer:success = 1
Counter zipkin:create_log_entries:error:java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder = 1
Counter HttpServer:sent_bytes = 19
Stat HttpServer:connection_received_bytes = 149.0
Stat HttpServer:connection_sent_bytes = 19.0
Stat HttpServer:connection_duration = 170.0
Stat HttpServer:connection_requests = 1.0
Counter zipkin:log_span:ok = 1
... but the span is not actually sent to Scribe.

This probably doesn't apply anymore.


Upgrade yahoo-finance to 1.3.2

1.3.2

Fix ImportError: No module named 'urllib2' in Python 3

1.3.1

Fix Creating Share object fails in raw_decode

1.2.2

Change API URL to HTTPS
Add get_percent_change()
Add get_name()
Cleanup

Tested with the following configuration:
sensor:
  - platform: yahoo_finance
    name: Red Hat Inc.
    symbol: RHT
  - platform: yahoo_finance
    name: Google
    symbol: GOOGL
  - platform: yahoo_finance
    name: Yahoo
    symbol: YHOO

@fabaff  Looks good! Thanks!


Fails to install using pip version 6

Solution seems to be described here:
http://stackoverflow.com/questions/27869152/heroku-typeerror-parse-requirements-missing-1-required-keyword-argument-ses
install_reqs = parse_requirements('requirements.txt')
to
install_reqs = parse_requirements('requirements.txt', session=False)
Can this changed be added? I don't know whether this will break older versions of pip.

I see it should be there. My mistake.


Bug: cant Scroll in Matrix-View

Describe the bug
I am having the Matrix-View in the sidebar with a lot of relatives. Due to he length of the list the ones at the bottom get cut of and there is no posibility to scroll.
To Reproduce
Steps to reproduce the behavior:

Put Breadcrumbs Matrix on one sidebar.
Open note with as many realtives, so you cant see some of them on the matrix-view.

Expected behavior
I would expect that you could scroll through the matrix-view like with the breadcrumbs-down view.
Screenshots

Desktop (please complete the following information):

OS: Windows 10
OS-Version: 21H2 -> Build:19044.1766
Obsidian-Version:  0.15.4

Please fix this! Breadcrumbs was a game changer until I came across this bug, and now it's barely useable and I've had to go back to using tags.

Testing it again, it looks like in 1.0 it might actually be showing all of the relatives and it just looks like it's not, because it doesn't scroll to the end of the boxes as you would see if you have less.  I had to do some testing to check if those were all of them.

Please give the new V4 a try. I've rewritten Breadcrumbs from scratch, so things work quite differently. You should be able to scroll now.
See here for more info about V4: https://github.com/SkepticMystic/breadcrumbs/blob/master/V4.md

Confirmed working in v4, gonna close this out


Fix Lucene query building for array types

Summary of the changes / Why this improves CrateDB
Fixes the following scenario(the first part of https://github.com/crate/crate/pull/14856#issuecomment-1757931824):
cr> create table tbl (a int, b int index off, c int index off storage with (columnstore = false));
CREATE OK, 1 row affected  (0.128 sec)
cr> insert into tbl values (1, 1, 1);
INSERT OK, 1 row affected  (0.009 sec)
cr> select * from tbl where a = any([1]);
+---+---+---+
| a | b | c |
+---+---+---+
| 1 | 1 | 1 |
+---+---+---+
SELECT 1 row in set (0.085 sec)
cr> select * from tbl where b = any([1]);
+---+---+---+
| a | b | c |
+---+---+---+
+---+---+---+
SELECT 0 rows in set (0.003 sec)
cr> select * from tbl where c = any([1]);
+---+---+---+
| a | b | c |
+---+---+---+
+---+---+---+
SELECT 0 rows in set (0.004 sec)

Created EqQuery.termsQuery referring to previous commits to fix-lucene-query-builder regarding EqQuery.termQuery (since termsQuery is basically termQuery with a collection of values) as well as the tests.
Checklist

[ ] Added an entry in the latest docs/appendices/release-notes/<x.y.0>.rst for user facing changes
[ ] Updated documentation & sql_features table for user facing changes
[ ] Touched code is covered by tests
[ ] CLA is signed
[ ] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in the latest docs/appendices/release-notes/<x.y.0>.rst
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

This entry should be good enough:
https://github.com/crate/crate/blob/8d9eb6a9754d06ee0d66a7c8942df8c134243c83/docs/appendices/release-notes/5.4.5.rst?plain=1#L49-L52


How does the Semisupervised malay dataset do vad?

Hello, may I ask how to do vad for this dataset? You say you use google vad to segment audio, could you please share the link of google vad?

https://github.com/huseinzol05/malaya-speech/blob/master/data/semisupervised-malay/semisupervised-googlespeech.py, https://github.com/wiseman/py-webrtcvad


[POC] improve actor monitoring

Proposed changes
Adding a way to monitor running actors (are they working? blocked? looping on errors?) and to let the health check actor probe all the actors before sending a status.

[x] Add status runtime requests and responses
[x] Add a channel to all actors to send status and actor events
[x] Use the Runtime to broadcast status requests
[x] Let the CombinedReceiver collect activity statistics and respond to status requests
[x] Collect count of messages received
[ ] Collect count of messages sent
[ ] Collect count of errors
[ ] Collect processing time stats
[x] Connect to the runtime any actor ready to request and process status requests
[x] Improve the health check actor to probe all the actors
[x] Let the health check actor request a shutdown if an actor crashes
[ ] Control the list of actors monitored by the health check actor
[ ] Control the behavior when an actor stops or crashes (ignore? down status? shutdown? restart?)
[ ] Fix the actors which don't use a CombinedReceiver.

Types of changes

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
[ ] Documentation Update (if none of the other choices apply)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

Checklist

[x] I have read the CONTRIBUTING doc
[x] I have signed the CLA (in all commits with git commit -s)
[x] I ran cargo fmt as mentioned in CODING_GUIDELINES
[x] I used cargo clippy as mentioned in CODING_GUIDELINES
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Further comments

Closing as fully behind.


SoS goes to single core at multiple dependent steps

Sorry to keep posting here issues running large number of small jobs. I initially thought this is related to #971 but looks it is not. Basically I have a workflow like #971, but now I have 4 steps A, B, C and D. The complete sequences should be:
A -> B -> C
A -> B -> D

and I made it such that the default step depends on C and D which then depend on A and B respectively. In execution, I expect A and B be executed sequentially, then C and D in parallel. This should be a very intuitive outcome-oriented logic.
But it was not the case. I do see C and D gets started the same time, but only C gets executed in parallel. D drags along with only one thread, until it finishes all the computation. This is weird.  I've got a MWE here:
16-May-2018-drag.zip
This example has a slightly none-trivial step A but the rest steps are trivial.
To reproduce the drag, first open top in another terminal, then
time sos run step_drag.sos -j 20

you'll see all seems fine (nicely parallelled) until steps score_pi0_0 and score_beta_0 (my C and D) above. One of them finished quickly but the other was dragging it running single process computation, although I would expect by logic that C and D should complete at the same time! The time it took was:
real	1m22.695s

Now, run the other example that removes step D only keep step C,
time sos run step_no_drag.sos -s force -j 20

everything is paralleled and time took is only:
real	0m21.712s

So something strange is happening with this outcome-oriented style execution. The DAG file drag_test.pdf
looks good.  File lock is my only guess now. In my MWE zip file I also put in a version called step_drag_task_version.sos that removes all concurrent = True and replace with task:  for actions. Running that version, it seems C and D completed at the same time!

Without running your example, I suspect that this is what happens:

C and D starts
C got all the remaining "slots", D got the one for the worker
C completes, D continues to use the one slot that was assigned

I agree with your suspicion, because that is the simplest theory to explain what is going on!

Note that sharing pools are not possible because the pools are created with processes that are forked from the worker process for each step. The only way to make it more clever is to checking for more resources and expand dynamically during the lifetime of a pool. I do not know how difficult it is to do this.

I do not see a need for the shrink scenario because there is no need to shrink as long as all computing resources (processes) are busy. I am checking if it is possible for a pool to expand if there are remaining resources.

I am checking if it is possible for a pool to expand if there are remaining resources.

Thanks a lot, that would be of tremendously useful!

The celery fork of multiprocessing, billiard, provides an enhanced pool with a grow function. I have not tested it heavily and have not made billiard the default, but if you install billiard locally, sos should now be able to grow the pool when there are slots available.

Great! I installed billiard locally, and I think it worked -- because it reduced my toy benchmark from 180 sec to 72 sec, and I can tell it is paralleled almost all the time.
So what's the deal here? Should we make it default, or maybe we need more tests? Or do we expect Python's multiprocessing will later catch it up?

As far as I remember, billiard was used a while ago but it caused some compatibility problem. Although here the usage is limited within a step and should be ok. I will let you use it for a while and add it to setup.py if no adverse effect is observed.

I recall having used celery some time ago that completely replaced Python's default multiprocessing, but indeed we switched it back ... here we are only using the Pool feature so hopefully it works! I'll close this issue for now until we have a problem.

So I searched for billiard in git history just out of curiosity and found this patch and this issue which I believe was the reason we got rid of it. So I updated to the latest sklearn (pip install -U scikit-learn) and ran this:
from sklearn import manifold
[1]
test = [1,2,3]
input: for_each = 'test', concurrent = True
from sklearn import manifold
print(9)

I had no problem. So we should be good, even to replace it globally?
But back to the patch that introduced billiard it seems there was some limitations of the stock multiprocessing you want to overcome. I take that later billiard was not needed because you've got a better solution.

OK, I have added billiard as a dependency and use it instead of multiprocessing.


Queued for more than an hour

I understand that the queue system is implemented to prevent a blackout like the previous FRR a few months ago. But after queuing for the update for more than an hour, I'm beginning to think there might be a deadlock that you are facing in your queuing system. You may want to consider a maximum timeout for those updating at the front of the queue.

Queue process worker failed to start after a server reboot. It's processing now. Thanks for bringing it to my attention.


Rewrite relative import extensions with flag

This PR adds --rewriteRelativeImportExtensions to support transforming module specifiers from e.g. "./utils.ts" to "./utils.js". A module specifier will be statically rewritten or shimmed during JS emit if it meets all of these criteria:

it begins with ./ or ../
it does not end in a declaration file name (.d.ts, .d.mts, .d.cts, .d.*.ts)
it ends in .ts, .tsx, .mts, or .cts

Error checking
Errors are issued in an attempt to catch common mistakes:

A module specifier will get rewritten but will break after rewriting:

"./foo.ts" actually resolves to ./foo.ts.ts or foo.ts/index.ts
"../other-project/src/index.ts" belongs to another project where outputs go to a different outDir

A module specifier will not get rewritten but will break after emitting as-is:

"#blah/foo.ts" resolves to foo.ts where the .ts matches through a wildcard

Syntax support

Scenario
Example input
Operation
Example output

Import declarations
import "./foo.ts"
Rewrite
import "./foo.js", require("./foo.js")

Export declarations
export * from "./foo.ts"
Rewrite
export * from "./foo.js"

Import equals
import foo = require("./foo.ts")
Rewrite
import foo = require("./foo.js")

Import calls with qualifying literal argument
import("./foo.ts")
Rewrite
import("./foo.js")

Require calls in JS with qualifying literal argument
require("./foo.ts")
Rewrite
require("./foo.js")

Import calls with non-literal argument
import(getPath())
Shim
import(__rewriteRelativeImportExtension(getPath()))

Require calls in JS with non-literal argument
require(getPath())
Shim
require(__rewriteRelativeImportExtension(getPath()))

Import calls with non-qualifying literal argument
import("foo")
None
import("foo")

Require calls with non-qualifying literal argument
require("foo")
None
require("foo")

Require calls in TS
require("./foo.ts")
None
require("./foo.ts")

Indirected require calls
(require)("./foo.ts")
None
(require)("./foo.ts")

Limitations and future work
This PR doesn’t change how module resolution works, so it’s still possible to reference a .ts file by a .js module specifier:
// @Filename: a.ts
export {};

// @Filename: b.ts
import {} from "./a.js"; // Always ok

We discussed that it’s probably desirable to turn this functionality off under --rewriteRelativeImportExtensions (and --allowImportingTsExtensions), since these options are a strong indicator that the user is going to run the input TS files in a TS-native runtime like Bun or node --experimental-strip-types. That would be a breaking change and isn’t included in this PR.
tslib PR: https://github.com/microsoft/tslib/pull/270
Fixes #59597

@typescript-bot pack this

@typescript-bot pack this

@typescript-bot pack this

The original issue was locked; it would be nice for someone with permissions to comment there so that people who were following there get this update.

@RyanCavanaugh I happened upon your final post here: https://github.com/microsoft/TypeScript/issues/49083#issuecomment-1435399267 minutes before you commented and referenced this PR.
I'm curious what changed from your reasoning a year ago as to why this would never be a feature?

NodeJS shipping --experimental-strip-types means there's now an actual runtime scenario where you need both JS and TS extensions

I have tested TS 5.7.0-dev.
It does not rewrite .d.ts files.
My library preset on 5.6.2:
    /* Library preset */
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "noEmit": false,
    "declaration": true,

and new one on 5.7.0-dev:
    /* Library preset */
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "allowImportingTsExtensions": true,      // <- new
    "rewriteRelativeImportExtensions": true, // <- new
    "noEmit": false,
    "declaration": true,

It works, I can use tsc (after changing .js to .ts in imports in all files).
Also, now I can run TS files with deno without using --unstable-sloppy-imports which prints annoying warnings.
However, imports inside .d.ts files have .ts ending now. There were no rewriting.
I expect that both configs should produce absolutely the same result (.js and .d.ts files) after using tsc.

Imports in .d.ts files are allowed to use .ts extensions regardless of config, so I wouldn't really consider that a bug.

It's a bug. Not rewritten imports in d.ts. breaks (partially) the code assistance in an IDE.
It's OK:

(npm install<EMAIL_ADDRESS>After using rewriteRelativeImportExtensions:

(npm install<EMAIL_ADDRESS>--registry=https://npm.pkg.github.com)
In this case, the IDE no longer highlights the function names, nor does it show the function signature.
The imports in .d.ts also should be rewritten.

Also, it currently (?) does not support aliases which resolve to a relative path.
{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["../*"]
    }
  }
}

I get the follow error for import {sleep} from "@/index.ts";:
TS2877: This import uses a '.ts' extension to resolve to an input TypeScript file, but will not be rewritten during emit because it is not a relative path.

Also, it currently (?) does not support aliases which resolve to a relative path.

This is 100% intentional

Is it a problem to resolve the alias first and only after that check if it is a relative path or not?
It doesn't seem like something that is difficult to implement. Just only one extra simple action.

I don't think the setup you have there works under --experimental-strip-types. https://github.com/microsoft/TypeScript/pull/59767#issuecomment-2383844756

Okay, I have checked it with the latest Node.js (v22.9.0) too (I tested it with Deno before).
It works (as expected).

I can't replicate what you're doing there
// with
// import * as bar from "./bar.ts";

node --experimental-strip-types foo.ts
hi

vs
// with
// import * as bar from<EMAIL_ADDRESS>Error [ERR_MODULE_NOT_FOUND]: Cannot find package<EMAIL_ADDRESS>imported from D:\Throwaway\est-test\foo.ts

The purpose of the flag is to rewrite paths which are syntactically relative, not "semantically" relative (whatever that would even mean).

Hey, I was reading the table in the PR description and I'm getting confused by these two lines:

Scenario
Example input
Operation
Example output

Require calls in JS with qualifying literal argument
require("./foo.ts")
Rewrite
require("./foo.js")

Require calls in TS
require("./foo.ts")
None
require("./foo.ts")

Does it mean that require("./foo.ts") will be rewritten if it's inside a JS file, but not if it's inside a TS file?

Yes. Plain require calls aren’t recognized as special in TS files. You’ll notice in JS that require("./foo") performs module resolution (the compiler knows the type to return), but in TS, require isn’t even allowed unless it’s declared as a global function, in which case that function’s return type is used (usually any).

Just out of curiosity, I’m facing an issue where my .d.ts files don’t have an extension in the path. For example: export * as v1alpha2 from './v1alpha2/index.gen';. Why is the .ts extension mandatory to transform it into .js? Thank you.

@RyanCavanaugh

Imports in .d.ts files are allowed to use .ts extensions regardless of config, so I wouldn't really consider that a bug.

While .d.ts files may allow .ts extensions in imports without configuration, wouldn't this break backwards compatibility for libraries targeting TypeScript 4 support since allowImportingTsExtensions wasn't introduced until TypeScript 5?