CSS file is not being compiled

Hello all,
I am trying to use phoenix 1.7 with tailwind without the npm dependencies.
I dont know why but the tailwind is not compiling and generating the css file even with a simple example project.
Seems that the JS generation works ok.
I am using VSCode on windows with WSL1:
Please take a look at the following commands:
$ elixir -v
	Erlang/OTP 24 [erts-12.2.1] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]
	Elixir 1.15.0-dev (1c41021) (compiled with Erlang/OTP 24)

$ mix tailwind.install
	16:28:05.615 [debug] Downloading tailwind from https://github.com/tailwindlabs/tailwindcss/releases/download/v3.1.8/tailwindcss-linux-x64

$ mix archive.install hex phx_new 1.7.0-rc.0
$ mix phx.new counter --live
$ cd counter/
$ mix ecto.create
$ mix phx.server
	[info] Running CounterWeb.Endpoint with cowboy 2.9.0 at <IP_ADDRESS>:4000 (http)
	[info] Access CounterWeb.Endpoint at http://localhost:4000
	[watch] build finished, watching for changes...
	[info] GET /
	[debug] Processing with CounterWeb.PageController.home/2
	  Parameters: %{}
	  Pipelines: [:browser]
	[info] Sent 200 in 147ms
	[info] GET /assets/app.css
	**[debug] ** (Phoenix.Router.NoRouteError) no route found for GET /assets/app.css (CounterWeb.Router)**
		(counter 0.1.0) lib/phoenix/router.ex:482: CounterWeb.Router.call/2
		(counter 0.1.0) lib/counter_web/endpoint.ex:1: CounterWeb.Endpoint.plug_builder_call/2
		(counter 0.1.0) lib/plug/debugger.ex:136: CounterWeb.Endpoint."call (overridable 3)"/2
		(counter 0.1.0) lib/counter_web/endpoint.ex:1: CounterWeb.Endpoint.call/2
		(phoenix 1.7.0-rc.2) lib/phoenix/endpoint/sync_code_reload_plug.ex:22: Phoenix.Endpoint.SyncCodeReloadPlug.do_call/4
		(plug_cowboy 2.6.0) lib/plug/cowboy/handler.ex:11: Plug.Cowboy.Handler.init/2
		(cowboy 2.9.0) /home/nuno/phoenix_projects/counter/deps/cowboy/src/cowboy_handler.erl:37: :cowboy_handler.execute/2
		(cowboy 2.9.0) /home/nuno/phoenix_projects/counter/deps/cowboy/src/cowboy_stream_h.erl:306: :cowboy_stream_h.execute/3
		(cowboy 2.9.0) /home/nuno/phoenix_projects/counter/deps/cowboy/src/cowboy_stream_h.erl:295: :cowboy_stream_h.request_process/3
		(stdlib 3.17) proc_lib.erl:226: :proc_lib.init_p_do_apply/3

	[watch] build started (change: "js/app.js")
	[watch] build finished
	[debug] Live reload: priv/static/assets/app.js
	[debug] Live reload: priv/static/assets/app.js

Now the website loads but has no css.
I then tried to force it:
$ mix assets.deploy
** (Mix) `mix tailwind default --minify` exited with 8

The code is here:
github proj
Does anyone have an idea of the reason?
May it be some issue with tailwind CLI and WSL1?
Thank you very much, any help is appreciated.
Thank you for your work, this stack is quite awesome.

As a follow up, I did the same thing in Windows directly and it works correctly, it downloads the tailwind exe and works fine.
So it seems something is wrong with WSL1.
I know that WSL1 is not a complete virtual machine, but it is way faster than WSL2. If someone finds it interesting, wants to dig further and need some help, I can help.
As a side note, I was trying WSL1 because windows had some issues with some libraries but I guess I read somewhere that phoenix 1.7 (or some previous version) has some encryption libraries changed to make it more compatible with windows. I will give it a try again with windows.
Thank you all

Hi all,
I confirmed having the same issue on WSL1.
Upgrading to WSL2 resolved the issue.

I did a clean install, and I am getting
Browserslist: caniuse-lite is outdated. Please run:
  npx update-browserslist-db@latest
  Why you should do it regularly: https://github.com/browserslist/update-db#readme
Error [BrowserslistError]: Unknown version 110 of Edge <---------- HERE
    at Function.select (/snapshot/tailwindcss/node_modules/browserslist/index.js:1096:17)
    at /snapshot/tailwindcss/node_modules/browserslist/index.js:314:29
    at Array.reduce (<anonymous>)
    at resolve (/snapshot/tailwindcss/node_modules/browserslist/index.js:304:34)
    at browserslist (/snapshot/tailwindcss/node_modules/browserslist/index.js:406:21)
    at Browsers.parse (/snapshot/tailwindcss/node_modules/autoprefixer/lib/browsers.js:54:12)
    at new Browsers (/snapshot/tailwindcss/node_modules/autoprefixer/lib/browsers.js:42:26)
    at loadPrefixes (/snapshot/tailwindcss/node_modules/autoprefixer/lib/autoprefixer.js:106:20)
    at Object.prepare (/snapshot/tailwindcss/node_modules/autoprefixer/lib/autoprefixer.js:120:22)
    at /snapshot/tailwindcss/node_modules/postcss/lib/lazy-result.js:149:39 {
  browserslist: true
}

That error is preventing the CSS from being compiled correctly.
I ran assets.build to confirm it is failing.

Changing from config :tailwind, version: "3.2.7", to config :tailwind, version: "3.3.2" fixed the issue for me

I just hit this issue and I think the bigger issue isn't a tweak of the code - it is that my app is trying to install dependencies, at runtime, without my input, I can't stop it from trying, and because of my firewall policy, it's in a crash loop.
I'm able to install dependencies, but because of the security stuff, I need to do them manually, and so this is a huge pain for me right now.
Is there a way we can remove the installation from startup to mix deps.build perhaps? I tried running that and it didn't do the task of doing whatever it's trying to do.
Unless there's a command, or series of commands like cleaning, or a mix phx.* command, it would be useful in the error message.
I'm sorry - I am very tired and should have gone to bed long ago, but Phoenix calls to me and I must build haha. I love you guys and this project, and am eager to help with this if I can!


Generation Script of frontier template is giving Error

Question
Hi Team
I am trying to Generation Script of frontier template but i am getting error after the below command
./node-template-release.sh TEMPLATE.tar.gz
Error:
error: no matching package found
searched package name: substrate-prometheus-endpoint
prerelease package needs to be specified explicitly
substrate-prometheus-endpoint = { version = "0.10.0-dev" }
location searched: https://github.com/paritytech/substrate
required by package fc-consensus v2.0.0-dev (https://github.com/paritytech/frontier.git?rev=30e05d8736ef9de2039327bcb1098b45bb546502#30e05d87)
... which satisfies git dependency fc-consensus of package frontier-template-node v0.0.0 (/private/var/folders/7h/zsl46ccs26n6g9jqmqdcfxdw0000gn/T/.tmpZ2uJ6u/template/node)
thread 'main' panicked at 'assertion failed: Command::new("cargo").args(&["build",\n                             "--all"]).current_dir(path).status().expect("Compiles node").success()', src/main.rs:188:5
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Can you please help me in this?

the same error occurs. @PankajChaudhary5 , have you found any solutions?

No @dongchangYoo. I used the code given in the documentation as the initial code.

I think this One: https://github.com/substrate-developer-hub/frontier-node-template

Any Solution to this issue? I want to build the latest one. Not want to use pre-generated.

I have the same problem. Wasted days to fix the dependency hell.
@PankajChaudhary5 The pre-generated node template also has issue with tokio. It has two versions in the dependency tree

I have the same issue.
Hey @naiemk, I couldn't find your fix nor your PR, can you share it?


NSGestureRecoginzer mouseDown sent twice with NSTextField in focus

In Google Inbox example the user has to paste the code with right click because the menu isn't hooked up.   That is an easy fix. After this the NSTextField is the first responder.
However when I click somewhere else in the window, on any other view, I get the exact same NSMouseDown event twice in RCTTouchHandler.  This causes it to throw an error because the The Touch is already recorded.   It has already seen the event.   I am on El Capitan.
I am trying to figure out why the same mouseDown event is sent twice to the gesture recognizer in these cases.  I was able to workaround it by checking for the same event and ignoring it.

I got the same error a while ago, and added some temporary workaround: https://github.com/ptmt/react-native-desktop/blob/master/React/Base/RCTTouchHandler.m#L96. Anyway, mouse events is bad and incomplete right now, need to invest a more time to RCTTouchHandler to fix a few major problems. @mrjjwright  could you reach me out on muakacho at gmail.com, I would love to know what kind of apps you are going to make with RND?

Need to create a reproducible scenario. It seems that the exact problem is fixed


Investigate SSR support

When using Foundry with server-side rendering (SSR) apps, i.e. apps created with NextJS, don't have a window object and will require polyfilling.
I have noticed that there are many answers for working around the window is not defined error received from server-side renderings SSR, ie NextJS, apps. These solutions range from polyfilling the global window variable to using next/dynamic importing. All of these solutions are approached from and applied to the application consuming a 3rd party module that references window. Which makes sense, since normally that is what we can control.
However, I am interested if anyone has any advice on how to fix this problem from the npm package side of things. I am working on a private React UI library package that I have published to npm and have realized that when I add it to a NextJS project I get the window is not defined error (works fine in a create-react-app). Instead of documenting a said workaround in my readme, I would much rather explore the possibility of removing the package's dependency of window so my UI library package can SSR.

I wonder if it is styled-components not working - they have a page dedicated to enabling server-side rendering: https://styled-components.com/docs/tooling#serverside-rendering

A simple create-next-app would be a good place to start testing solutions.


Operation request: Word Cloud Generator

Summary
Input a load of text, generate a word cloud which highlights the most used words (filtering out common words like 'the', 'and', 'it' etc.).
The basic output type could be a ranked list and the present type could be an image or some other HTML-based display.

Ideally not, but that's probably a good place to start. It would be nice if there was a dropdown option to choose which language, but I imagine that would be quite a lot of work, so let's start with English.

Hi, how could I contribute to this? Has someone already been working on it? Thanks :)

Hi @NalinGHub
You can pick this up; Go through contribution guidelines and follow the steps.
Have fun.


Allow the use of 64 hex digits pre-shared-key

Add a --psk command switch to allow the use of pre-shared-key in binary format instead of an ascii passphrase as allowed by hostapd
For example:
create_ap -n -g <IP_ADDRESS> --psk MySSID 9c399aba03129af0a86838780444a85fe5dff2cf341da3e0f78e32d1e3f0a45a

Your commit works but it's a bit hacky. In mind a proper implementation will save pre-shared-key in the PSK variable instead of PASSPHRASE variable.
Also when the user doesn't provide the PSK then we don't need to read it from tty as a password (-s parameter of read) and the user don't need to write it twice.
I can merge your commit and then fix these issues above your commit, or you can fix them in a new commit. What do you prefer?

You can do it if you want.
2015-05-17 19:43 GMT+02:00 oblique<EMAIL_ADDRESS>
Your commit works but it's a bit hacky. In mind a proper implementation
will save pre-shared-key in the PSK variable instead of PASSPHRASE
variable.
Also when the user doesn't provide the PSK then we don't need to read it
from tty as a password (-s parameter of read) and the user don't need to
write it twice.
I can merge your commit and then fix these issues above your commit, or
you can fix them in a new commit. What do you prefer?
—
Reply to this email directly or view it on GitHub
https://github.com/oblique/create_ap/pull/79#issuecomment-102826605.

I decided to use the same variable instead of creating a new one because it was complicating many things.
I did fix some issues though.
Merged.


UI update

http://petstore.swagger.io/
Are you planning to update UI like in link above

Dip of #1064


erlangR22: 22.0.4 -> 22.1.7

Motivation for this change
Keeping things up-to-date.
This will superseded PR https://github.com/NixOS/nixpkgs/pull/71285 & https://github.com/NixOS/nixpkgs/pull/69438 (which are open already too long in my opinion).
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @the-kenny  @sjmackenzie  @couchemar  @gleber

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/70


migrate to nuxt/auth v5

We should migrate to nuxt/auth v5 so we can take advantage of its built-in support for refresh tokens (https://auth.nuxtjs.org/schemes/refresh).  This will allow us to stop hijacking the browser to force the user to redo the SSO login dance.

Closing in favor of https://github.com/ITI/searcch/issues/167 .


Receiving "Conversation ID not found" errors in adapter's onTurnError

Versions
NodeJS v10.16.3
BotBuilder NodeJS SDK v4.6.2
OS: NodeJS Docker Image
Describe the bug
In the production, our bot service adapter's onTurnError listener is receiving plenty of but intermittent errors for directline channel users. When printed the error object, it looks like below
{ Error: Conversation ID not found","stream":"stderr","time":"2020-04-11T09:39:47.034381068Z"}

Some of the conversation IDs for which the errors have occurred are below:
LkrMRVxnwvD4VIM2sbSO7t-h
Gz8jVK8ZDbj3NZGk7kXfjD-h
EBEQvQQyvmIKmfDiWlWBhq-h
5s9G9tEbk2Y2YCWUpAPLEn-h

We are not able to reproduce this error and identify the root cause of it.
Please guide us in understanding in what scenarios this may happen or how to debug so we can fix them.

The fix has been deployed.  Please reopen if you see this again

@craigjensen
Errors are still occurring in our bots.
Below are some of the conversation Ids for which error occurred.
LrgaRN4IOeV9Thpi3vt8vA-h SdwjhlmM1X4zgjJfzh6Ke-h 9V2gmnWSiTRKrcCQWcxfaG-h BccRGINMspOJOkQ8jOiUHQ-h

There's a scenario that the original fix didn't address but it appears to be a fairly rare corner case.  We'll get a fix ready but knowing how often you are seeing this will help us prioritize getting it deployed.

@craigjensen The error count varies from 5 to 20 per day depending on usage by the customers.

The fix will go out in the next deployment which is planned for this week

Fix has been deployed - please reopen if you see this again


Sofa tables

When running on macOS 14.0
osquery> select * from sofa_unpatched_cves;
+------------+----------------+-----------------+--------------------+
| os_version | cve            | patched_version | actively_exploited |
+------------+----------------+-----------------+--------------------+
| 14.0.0     | CVE-2024-1580  | 14.4.1          | false              |
| 14.0.0     | CVE-2024-23231 | 14.4            | false              |
| 14.0.0     | CVE-2024-23245 | 14.4            | false              |
| 14.0.0     | CVE-2024-23281 | 14.4            | false              |
| 14.0.0     | CVE-2022-48554 | 14.4            | false              |
| 14.0.0     | CVE-2024-23279 | 14.4            | false              |
| 14.0.0     | CVE-2024-23259 | 14.4            | false              |
| 14.0.0     | CVE-2024-23293 | 14.4            | false              |
| 14.0.0     | CVE-2024-23291 | 14.4            | false              |
| 14.0.0     | CVE-2024-23216 | 14.4            | false              |
| 14.0.0     | CVE-2024-23289 | 14.4            | false              |
| 14.0.0     | CVE-2024-23280 | 14.4            | false              |
| 14.0.0     | CVE-2024-23270 | 14.4            | false              |
| 14.0.0     | CVE-2024-23234 | 14.4            | false              |
| 14.0.0     | CVE-2024-23241 | 14.4            | false              |
| 14.0.0     | CVE-2024-23274 | 14.4            | false              |
| 14.0.0     | CVE-2024-23226 | 14.4            | false              |
| 14.0.0     | CVE-2024-23277 | 14.4            | false              |
| 14.0.0     | CVE-2024-23250 | 14.4            | false              |
| 14.0.0     | CVE-2024-23235 | 14.4            | false              |
| 14.0.0     | CVE-2024-23273 | 14.4            | false              |
| 14.0.0     | CVE-2024-23258 | 14.4            | false              |
| 14.0.0     | CVE-2024-23267 | 14.4            | false              |
| 14.0.0     | CVE-2024-23275 | 14.4            | false              |
| 14.0.0     | CVE-2023-48795 | 14.4            | false              |
| 14.0.0     | CVE-2023-51385 | 14.4            | false              |
| 14.0.0     | CVE-2024-23255 | 14.4            | false              |
| 14.0.0     | CVE-2024-23246 | 14.4            | false              |
| 14.0.0     | CVE-2024-23233 | 14.4            | false              |
| 14.0.0     | CVE-2024-23288 | 14.4            | false              |
| 14.0.0     | CVE-2024-23266 | 14.4            | false              |
| 14.0.0     | CVE-2024-23260 | 14.4            | false              |
| 14.0.0     | CVE-2024-23284 | 14.4            | false              |
| 14.0.0     | CVE-2024-23225 | 14.4            | true               |
| 14.0.0     | CVE-2024-23296 | 14.4            | true               |
| 14.0.0     | CVE-2024-23239 | 14.4            | false              |
| 14.0.0     | CVE-2024-23290 | 14.4            | false              |
| 14.0.0     | CVE-2024-23263 | 14.4            | false              |
| 14.0.0     | CVE-2024-23283 | 14.4            | false              |
| 14.0.0     | CVE-2024-23268 | 14.4            | false              |
| 14.0.0     | CVE-2024-23238 | 14.4            | false              |
| 14.0.0     | CVE-2024-23265 | 14.4            | false              |
| 14.0.0     | CVE-2024-23287 | 14.4            | false              |
| 14.0.0     | CVE-2024-23272 | 14.4            | false              |
| 14.0.0     | CVE-2024-23244 | 14.4            | false              |
| 14.0.0     | CVE-2024-23264 | 14.4            | false              |
| 14.0.0     | CVE-2024-23276 | 14.4            | false              |
| 14.0.0     | CVE-2024-23286 | 14.4            | false              |
| 14.0.0     | CVE-2024-23285 | 14.4            | false              |
| 14.0.0     | CVE-2023-51384 | 14.4            | false              |
| 14.0.0     | CVE-2024-23230 | 14.4            | false              |
| 14.0.0     | CVE-2022-42816 | 14.4            | false              |
| 14.0.0     | CVE-2024-23253 | 14.4            | false              |
| 14.0.0     | CVE-2024-23257 | 14.4            | false              |
| 14.0.0     | CVE-2024-23278 | 14.4            | false              |
| 14.0.0     | CVE-2023-42853 | 14.4            | false              |
| 14.0.0     | CVE-2024-23254 | 14.4            | false              |
| 14.0.0     | CVE-2024-23227 | 14.4            | false              |
| 14.0.0     | CVE-2024-23249 | 14.4            | false              |
| 14.0.0     | CVE-2024-0258  | 14.4            | false              |
| 14.0.0     | CVE-2024-23205 | 14.4            | false              |
| 14.0.0     | CVE-2024-23294 | 14.4            | false              |
| 14.0.0     | CVE-2024-23232 | 14.4            | false              |
| 14.0.0     | CVE-2024-23292 | 14.4            | false              |
| 14.0.0     | CVE-2024-23242 | 14.4            | false              |
| 14.0.0     | CVE-2024-23269 | 14.4            | false              |
| 14.0.0     | CVE-2024-23247 | 14.4            | false              |
| 14.0.0     | CVE-2024-23248 | 14.4            | false              |
| 14.0.0     | CVE-2024-23208 | 14.3            | false              |
| 14.0.0     | CVE-2024-23201 | 14.3            | false              |
| 14.0.0     | CVE-2024-23209 | 14.3            | false              |
| 14.0.0     | CVE-2024-23271 | 14.3            | false              |
| 14.0.0     | CVE-2024-23224 | 14.3            | false              |
| 14.0.0     | CVE-2024-27791 | 14.3            | false              |
| 14.0.0     | CVE-2024-23203 | 14.3            | false              |
| 14.0.0     | CVE-2024-23204 | 14.3            | false              |
| 14.0.0     | CVE-2024-23217 | 14.3            | false              |
| 14.0.0     | CVE-2024-23210 | 14.3            | false              |
| 14.0.0     | CVE-2024-23214 | 14.3            | false              |
| 14.0.0     | CVE-2024-23207 | 14.3            | false              |
| 14.0.0     | CVE-2024-23213 | 14.3            | false              |
| 14.0.0     | CVE-2024-23222 | 14.3            | true               |
| 14.0.0     | CVE-2024-23211 | 14.3            | false              |
| 14.0.0     | CVE-2024-23218 | 14.3            | false              |
| 14.0.0     | CVE-2024-23223 | 14.3            | false              |
| 14.0.0     | CVE-2024-23215 | 14.3            | false              |
| 14.0.0     | CVE-2024-23206 | 14.3            | false              |
| 14.0.0     | CVE-2024-23212 | 14.3            | false              |
| 14.0.0     | CVE-2023-42940 | 14.2.1          | false              |
| 14.0.0     | CVE-2023-42909 | 14.2            | false              |
| 14.0.0     | CVE-2023-42974 | 14.2            | false              |
| 14.0.0     | CVE-2023-42907 | 14.2            | false              |
| 14.0.0     | CVE-2023-42881 | 14.2            | false              |
| 14.0.0     | CVE-2023-42884 | 14.2            | false              |
| 14.0.0     | CVE-2023-42913 | 14.2            | false              |
| 14.0.0     | CVE-2023-42901 | 14.2            | false              |
| 14.0.0     | CVE-2023-42900 | 14.2            | false              |
| 14.0.0     | CVE-2023-42932 | 14.2            | false              |
| 14.0.0     | CVE-2023-42919 | 14.2            | false              |
| 14.0.0     | CVE-2023-42905 | 14.2            | false              |
| 14.0.0     | CVE-2023-3618  | 14.2            | false              |
| 14.0.0     | CVE-2023-42930 | 14.2            | false              |
| 14.0.0     | CVE-2023-42950 | 14.2            | false              |
| 14.0.0     | CVE-2023-42894 | 14.2            | false              |
| 14.0.0     | CVE-2023-42892 | 14.2            | false              |
| 14.0.0     | CVE-2020-19187 | 14.2            | false              |
| 14.0.0     | CVE-2020-19190 | 14.2            | false              |
| 14.0.0     | CVE-2023-42947 | 14.2            | false              |
| 14.0.0     | CVE-2023-42902 | 14.2            | false              |
| 14.0.0     | CVE-2023-42896 | 14.2            | false              |
| 14.0.0     | CVE-2023-38545 | 14.2            | false              |
| 14.0.0     | CVE-2023-42931 | 14.2            | false              |
| 14.0.0     | CVE-2023-42904 | 14.2            | false              |
| 14.0.0     | CVE-2023-42924 | 14.2            | false              |
| 14.0.0     | CVE-2020-19185 | 14.2            | false              |
| 14.0.0     | CVE-2023-42883 | 14.2            | false              |
| 14.0.0     | CVE-2023-42903 | 14.2            | false              |
| 14.0.0     | CVE-2023-42914 | 14.2            | false              |
| 14.0.0     | CVE-2023-42936 | 14.2            | false              |
| 14.0.0     | CVE-2023-42926 | 14.2            | false              |
| 14.0.0     | CVE-2023-42842 | 14.2            | false              |
| 14.0.0     | CVE-2023-42910 | 14.2            | false              |
| 14.0.0     | CVE-2023-38039 | 14.2            | false              |
| 14.0.0     | CVE-2023-42887 | 14.2            | false              |
| 14.0.0     | CVE-2023-40390 | 14.2            | false              |
| 14.0.0     | CVE-2023-5344  | 14.2            | false              |
| 14.0.0     | CVE-2023-42937 | 14.2            | false              |
| 14.0.0     | CVE-2023-42890 | 14.2            | false              |
| 14.0.0     | CVE-2023-42911 | 14.2            | false              |
| 14.0.0     | CVE-2023-42874 | 14.2            | false              |
| 14.0.0     | CVE-2023-42886 | 14.2            | false              |
| 14.0.0     | CVE-2023-42956 | 14.2            | false              |
| 14.0.0     | CVE-2023-42912 | 14.2            | false              |
| 14.0.0     | CVE-2023-42898 | 14.2            | false              |
| 14.0.0     | CVE-2023-42899 | 14.2            | false              |
| 14.0.0     | CVE-2023-42888 | 14.2            | false              |
| 14.0.0     | CVE-2023-42891 | 14.2            | false              |
| 14.0.0     | CVE-2020-19186 | 14.2            | false              |
| 14.0.0     | CVE-2020-19188 | 14.2            | false              |
| 14.0.0     | CVE-2023-42922 | 14.2            | false              |
| 14.0.0     | CVE-2023-42893 | 14.2            | false              |
| 14.0.0     | CVE-2023-42906 | 14.2            | false              |
| 14.0.0     | CVE-2023-42908 | 14.2            | false              |
| 14.0.0     | CVE-2023-42882 | 14.2            | false              |
| 14.0.0     | CVE-2023-45866 | 14.2            | false              |
| 14.0.0     | CVE-2023-38546 | 14.2            | false              |
| 14.0.0     | CVE-2020-19189 | 14.2            | false              |
| 14.0.0     | CVE-2023-42916 | 14.1.2          | true               |
| 14.0.0     | CVE-2023-42917 | 14.1.2          | true               |
| 14.0.0     | CVE-2023-30774 | 14.1            | false              |
| 14.0.0     | CVE-2023-40444 | 14.1            | false              |
| 14.0.0     | CVE-2023-42945 | 14.1            | false              |
| 14.0.0     | CVE-2023-42823 | 14.1            | false              |
| 14.0.0     | CVE-2023-42438 | 14.1            | false              |
| 14.0.0     | CVE-2023-41988 | 14.1            | false              |
| 14.0.0     | CVE-2023-42842 | 14.1            | false              |
| 14.0.0     | CVE-2023-4751  | 14.1            | false              |
| 14.0.0     | CVE-2023-42843 | 14.1            | false              |
| 14.0.0     | CVE-2023-42857 | 14.1            | false              |
| 14.0.0     | CVE-2023-40449 | 14.1            | false              |
| 14.0.0     | CVE-2023-42847 | 14.1            | false              |
| 14.0.0     | CVE-2023-42839 | 14.1            | false              |
| 14.0.0     | CVE-2023-4734  | 14.1            | false              |
| 14.0.0     | CVE-2023-4738  | 14.1            | false              |
| 14.0.0     | CVE-2023-41975 | 14.1            | false              |
| 14.0.0     | CVE-2023-42849 | 14.1            | false              |
| 14.0.0     | CVE-2023-42942 | 14.1            | false              |
| 14.0.0     | CVE-2023-42853 | 14.1            | false              |
| 14.0.0     | CVE-2023-42845 | 14.1            | false              |
| 14.0.0     | CVE-2023-42873 | 14.1            | false              |
| 14.0.0     | CVE-2023-41976 | 14.1            | false              |
| 14.0.0     | CVE-2023-42854 | 14.1            | false              |
| 14.0.0     | CVE-2023-42834 | 14.1            | false              |
| 14.0.0     | CVE-2023-42935 | 14.1            | false              |
| 14.0.0     | CVE-2023-42889 | 14.1            | false              |
| 14.0.0     | CVE-2023-42841 | 14.1            | false              |
| 14.0.0     | CVE-2023-4735  | 14.1            | false              |
| 14.0.0     | CVE-2023-40416 | 14.1            | false              |
| 14.0.0     | CVE-2023-40446 | 14.1            | false              |
| 14.0.0     | CVE-2023-42859 | 14.1            | false              |
| 14.0.0     | CVE-2023-4750  | 14.1            | false              |
| 14.0.0     | CVE-2023-42835 | 14.1            | false              |
| 14.0.0     | CVE-2023-42946 | 14.1            | false              |
| 14.0.0     | CVE-2023-4752  | 14.1            | false              |
| 14.0.0     | CVE-2023-40447 | 14.1            | false              |
| 14.0.0     | CVE-2023-42877 | 14.1            | false              |
| 14.0.0     | CVE-2023-42953 | 14.1            | false              |
| 14.0.0     | CVE-2023-42860 | 14.1            | false              |
| 14.0.0     | CVE-2023-41977 | 14.1            | false              |
| 14.0.0     | CVE-2023-40413 | 14.1            | false              |
| 14.0.0     | CVE-2023-42848 | 14.1            | false              |
| 14.0.0     | CVE-2023-42850 | 14.1            | false              |
| 14.0.0     | CVE-2023-41982 | 14.1            | false              |
| 14.0.0     | CVE-2023-36191 | 14.1            | false              |
| 14.0.0     | CVE-2023-41989 | 14.1            | false              |
| 14.0.0     | CVE-2023-38403 | 14.1            | false              |
| 14.0.0     | CVE-2023-28826 | 14.1            | false              |
| 14.0.0     | CVE-2023-42856 | 14.1            | false              |
| 14.0.0     | CVE-2023-42840 | 14.1            | false              |
| 14.0.0     | CVE-2023-40423 | 14.1            | false              |
| 14.0.0     | CVE-2023-42861 | 14.1            | false              |
| 14.0.0     | CVE-2023-4733  | 14.1            | false              |
| 14.0.0     | CVE-2023-40408 | 14.1            | false              |
| 14.0.0     | CVE-2023-40404 | 14.1            | false              |
| 14.0.0     | CVE-2023-41254 | 14.1            | false              |
| 14.0.0     | CVE-2023-42852 | 14.1            | false              |
| 14.0.0     | CVE-2023-42878 | 14.1            | false              |
| 14.0.0     | CVE-2023-4736  | 14.1            | false              |
| 14.0.0     | CVE-2023-4781  | 14.1            | false              |
| 14.0.0     | CVE-2023-42858 | 14.1            | false              |
| 14.0.0     | CVE-2023-42952 | 14.1            | false              |
| 14.0.0     | CVE-2023-41072 | 14.1            | false              |
| 14.0.0     | CVE-2023-42844 | 14.1            | false              |
| 14.0.0     | CVE-2023-42836 | 14.1            | false              |
| 14.0.0     | CVE-2023-41997 | 14.1            | false              |
| 14.0.0     | CVE-2023-40421 | 14.1            | false              |
| 14.0.0     | CVE-2023-41983 | 14.1            | false              |
| 14.0.0     | CVE-2023-40405 | 14.1            | false              |
| 14.0.0     | CVE-2023-42838 | 14.1            | false              |
+------------+----------------+-----------------+--------------------+
osquery>

When running macOS 14.4.1
| update_name         | product_version | release_date         | security_info                         | unique_cves_count | days_since_previous_release |
+---------------------+-----------------+----------------------+---------------------------------------+-------------------+-----------------------------+
| macOS Sonoma 14.4.1 | 14.4.1          | 2024-03-25T00:00:00Z | https://support.apple.com/kb/HT214096 | 1                 | 18                          |
+---------------------+-----------------+----------------------+---------------------------------------+-------------------+-----------------------------+

For the 14.4.1 example, that CVE says it was patched on 14.4.1. Shouldn't that query come up empty since it is running on the version of macOS for which it was patched?
I'd definitely expect that to show up on a 14.4.0 machine since it wasn't patched until 14.4.1.

You mean on the info table? That table is supposed to be information about the current running OS, but it could be a look back. Open to suggestions here - please elaborate on the logic you are thinking of.

You mean on the info table? That table is supposed to be information about the current running OS, but it could be a look back. Open to suggestions here - please elaborate on the logic you are thinking of.
Edit: I now realize I missed off the query I ran when I pasted the output. That run is for the separate info table.

Oh right.
So for sofa_unpatched_cves on 14.4.1, it would have nothing listed, presumably.
In the other table, it would show info about what the current OS has patched. That makes sense. I was thinking the second query was also sofa_unpatched_cves, which would be confusing. (Even though it obviously has totally different columns).

Now I think about it more, perhaps the tables should operate the same (showing unpatched vulnerabilities for the same major os version) and accept an input for other versions. Thoughts?

I think that would make sense 👍

I think that would make sense 👍

I left the sofa_security_release_info table displaying the current running os by default, as it is representing information about the release, not unpatched vulnerabilities as in the other table. Both tables will use the os_version predicate now to allow the operator to look at historical data if needed.


svelte-carousel doesn't appear to be written in CJS, but also doesn't appear to be a valid ES module

Bug Report
I'm using SvelteKit. Every time I run my project that uses the fomantic-ui package, I keep on getting this message on my terminal:
svelte-carousel doesn't appear to be written in CJS, but also doesn't appear to be a valid ES module (i.e. it doesn't have "type": "module" or an .mjs extension for the entry point). Please contact the package author to fix.
Now I don't know if this is alright or not. But everything seems to be working fine. It's just that this message keeps on showing whenever I run my project.
Steps to reproduce

Install fomantic-ui to your project.
Use it.
Then run your project to your browser.
In your terminal, you'll see this:

Expected result
No message like that on the terminal and everything should be fine.
Actual result

Version
^2.8.8

Duplicates https://github.com/vadimkorr/svelte-carousel/issues/95


[DRAFT] GCP Pipeline Jobs

API to expose the VertexAI endpoints for custom models (fine-tuning)

This PR looks pretty good to me so far. Only added a small reply to Raul's comment.

I talked to the others, Fede is currently on vacation. You can apply your suggestions and finish this pr, as far as I am concerned.

I'm currently on it. @nomisRev


Blocking braze breaks an email list sign-up page

I use a pihole to block ads, and it uses this hosts list.
With the pihole active, I can't seem to use this website to sign up for the email list:
https://transformersheavymetal.com/
The form submission fails, and I see some POST to blaze failed in the console.
I am guessing the blocklist is a bit too strict and breaks this. Thanks for any info.

@mezz post here the domain(s) from the console log please.

My client attempts to POST to
https://sdk.iad-06.braze.com/api/v3/data/

@jawz101 it's one of yours,you mind  look in to it. Thanks(as allways) 👍

It's all about audience engagement/segmentation... all of the stuff that is tracking.  And shows up often in Android app traffic.  Leaving for now and users can whitelist as necessary.

This is a form I willingly submit, I didn't realize this project was so hardline on tracking. I use this as a pihole blacklist. For more fine-grained anti-tracking I disable JavaScript and many other things in my browser, where I have an easier time controlling it manually.
Do you have any recommendations for an ad-blocking list that only blocks ads and invisible trackers? That is what I believe I need at the router DNS level, for my mobile devices, game consoles, and for my family to use conveniently. Thanks.

I understand.  If this was a common problem with many people, I would reconsider, but it's one isolated instance on one website doing one thing so far.  Otherwise, Braze https://www.braze.com/ (formerly Appboy) is a tracker (I created this ad signature in Exodus Privacy Project a few years ago.
I would say you consented to sign up to a concert site- much like everything you and we do online- and clicked on I agree on the fine print.  But then we choose to block ads and trackers.  The problem I see is that one site tied a sign up screen into a 3rd party marketing product either intentionally or unintentionally to break if blocked.  I consider that rare. Otherwise, that particular/random subdomain makes our devices so chatty on the network that it is the (gasp) 4463rd most looked up DNS lookup out of the top million domain lookups on Cisco's Top 1 Million DNS lookups for today.  That's like if you have the ESPN, Disney+, Dashlane password manager, or NBA mobile app, your phone is constantly giving them data to log your behaviors.  Based on its rank, it's checked more often than people watch videos on Facebook, visit target.com, most time servers are checked, antivirus updates are checked.... all sorts of stuff.
I remove a lot and I'd remove this one if the scales tipped the wrong way too much but it doesn't right now.  That's why pi-holehas a whitelist.  I whitelist a few things I want that some blocklists try to block.  And Steven Black's list is very reliable so I personally wouldn't want to make it look bad.  But, this is one of those I think is not worth opening up for the sake of the thousands and millions of times our devices want to try and phone home to them without us aware.

I recognize there is a trade off here, but this is not the stance I expected from this list because I thought of it as a safe default for everyone. If possible, I would like to find a similar list that prioritizes convenience. I mainly just want to block ads, and it would be nice to block tracking in cases where it is very unlikely to impact anyone's experience. Please let me know if there is a good place to look. Thanks!

Certainly.
If you notice, StevenBlack is a list of lists.  If you look at the main page
https://github.com/StevenBlack/hosts
Under
"Sources of hosts data unified in this variant"
It Iists each source list individually along with links to each.  If you add each except for the AdAway list it'll omit AdAway's entries and, consequently, this braze one.
Other sources might be found on filterlists.com.  it has just about every list out there but many of them are combo lists and many will have AdAway entries.
If you're looking for original lists, I'd suggest Steven Black's source lists, specifically MVPS, Dan Pollock/someonewhocares, Peter Lowe's (should be on that filter list site, and AdGuard DNS list.
On that filterlist site, any with the pi-hole logo are host file format should work with pi-hole.  There are tons of crappy lists on there- some block everything but the kitchen sink.  The ones I suggested above are the most reliable, effective, and original that I've found.

There are tons of crappy lists on there- some block everything but the kitchen sink.

I do like how you described it ☝  😄

Well some will block facebook, foxnews because they want to call it fake news... you get the idea.  I've added a ton and see what all they block and many are just goofy.

It's all about audience engagement/segmentation... all of the stuff that is tracking. And shows up often in Android app traffic. Leaving for now and users can whitelist as necessary.

Steve @StevenBlack this one is wontfix and can be closed.


Demultiplexing "N"-barcode as no-op

With https://github.com/fulcrumgenomics/fqtk/pull/30 (and release v0.3.0) fqtk allows Ns in barcodes.
I tried to run demultiplexing accepting any sequence for a sample (with a barcode containing only Ns), but all reads are written to unmatched.R1.fq.gz instead of the sample fq.
Is this intended?

@mschubert would you be willing to share some of your data, or one FASTQ record that should have been matched to a sample along with the expected barcode?

My apologies for the late reply: The issue seems to be with fastq records that contain Ns themselves:
# my.fq.gz
@M00872:1070:000000000-GLPWM:1:1101:15776:1330 1:Y:0:1
AAGANNATNGNNGNNANNNTNNNAACGTAGTGCGCCAGCCTATTTCAGTGCTCAATCTTGCAGAGAATACTCTTGAGAGCG
+
AA1A##>>#>##A##A###A###ABBFFFHGGHEGGGGGGHHFHHHHHHHHHGFHHHHHHHHHHHCGHHFHHHGHHHHHHE
@M00872:1070:000000000-GLPWM:1:1101:15866:1331 1:Y:0:1
AAGANNATNGNNGNNANNNTNNNAACGTAGTGCGCATAAGCCGTTCAAGAGGAGCCATTGTGGGGAGGCCCTGGGGACTGG
+
AAAA##>>#>##A##A###A###BABFFHHGGHEEEEGHFFHGEEGHGFHEHHEHGFHHHFGFC>FCGGCEHHHGGAEFG/

# meta.tsv
sample_id  barcode
test       NNNNNNN

fqtk demux --inputs my.fq.gz --max-mismatches 0 --read-structures 7B+T --sample-metadata meta.tsv --output out

Thank-you @mschubert for the clear report!


Large scale root-finding

I have a problem where I'm looking for a fixed point for a [1000, 1, 1000, 3] complex field. I started by splitting it into a real and imaginary part to allow implicit differentiation, so essentially I'm working with a [1000, 1, 1000, 3, 2] sized field. Fixed point iteration works excellent, and so does implicit differentiation.
I can rewrite this problem more efficiently as a root finding problem (some things cancel out), but using find_root quickly goes out of memory for any method I'm trying - for example, Newton is trying to allocate 77TB(!) of memory. I'm trying to understand if this is expected behaviour - the Jacobian is big here, but it doesn't need to be explicitly calculated, does it (matrix free / JVP style)? Am I missing something here?
Thanks!

By default, Optimistix will materialize the Jacobian. This is because the matrix-materializing linear solvers are generally both faster (for problems that fit in-memory) and more numerically stable, than the matrix-free ones.
In this case you may wish to use a matrix-free linear solver, e.g. optimistix.Newton(linear_solver=lineax.CG()). (Make sure your problem has the right structure for the linear solver you use, see https://docs.kidger.site/lineax/examples/no_materialisation/ for more.)

Thanks, this was very helpful - I was unaware this was optimistix default behaviour.
Additionally, do you know if there's a difference between the jaxopt matrix-free solvers and the optimistix ones? In my problem, implicit differentiation works fine in jaxopt (using NormalCG, I checked and the gradients are correct), but optimistix returns nans. I can take some time to write something reproducible, but was wondering if I'm missing something obvious?

The tools on this page might be a useful starting point. But I don't think there should be a serious difference between the two tech stacks. A MWE might be necessary I'm afraid!
En passant note that implicit differentiation also involves a linear solve, separate to the one already discussed, and you can adjust this with adjoint=ImplicitAdjoint(linear_solver=lineax.Foo()).

Allright, I'll get to it then! My money's on a divide by zero somewhere (I do some padding), but it doesn't seem to be an issue for jaxopt, so that's what I'm surprised about? I'll get back to you in a few days once I have time to do this.
And yes, I'm aware of that - I noticed jaxopt used NormalCG in the implicit, but both CG nor NormalCG in the adjoint of optimistix returned NaNs.
I'm wondering if it makes sense to add a warning about optimistix using matrix-materialising solvers by default? For users coming from jaxopt who are not too aware of the inner workings of implicit diff, optimistix will fail where jaxopt succeeded.

Allright, I'll get to it then! My money's on a divide by zero somewhere (I do some padding), but it doesn't seem to be an issue for jaxopt, so that's what I'm surprised about? I'll get back to you in a few days once I have time to do this.

Thank you!

I'm wondering if it makes sense to add a warning about optimistix using matrix-materialising solvers by default? For users coming from jaxopt who are not too aware of the inner workings of implicit diff, optimistix will fail where jaxopt succeeded.

That makes sense to me! Where would be best? (The documentation? Maybe a warning in code if the input is large? I'mt not sure.) If you have thoughts I'd be happy to take a PR on wherever you would have found it most useful.

A warning in the code could be a good idea, although it would require us to decide on a size limit - which would be fairly system dependent...
Looking at the documentation, how about adding a section to the FAQ? Or even under Misc in its own section?

I think adding this to the FAQ sounds good to me!


Websocket Extension for control inputs to the WebServer

As a result of the previous testing session in Drumheller, I noticed that the WebServer process is extremely sensitive to routing+DNS because of the HTTP protocol we are using to send data.
The current system requires a new socket to be opened for every message, and the tcp exchange to be successful (meaning it also will retry until getting delivered). If some part of this long process is delayed, the current HTTP protocol will also delay any future messages so they don't arrive out of order.
For something like joysticks, we need a more streamlined data flow. The current websocket protocol looks promising, but it is still TCP (not fixing out delay problem). However, once the connection does establish, it should be a lot more reliable.
https://www.tutorialspoint.com/html5/html5_websocket.htm on the webpage side
https://github.com/zeekay/bottle-websocket on the webserver side (maybe?)

Kind-of secondary, but here is someone's solution implementing WebRTC on Bottle (which would give us true UDP with Javascript).
https://github.com/xhs/webrtc-experiments

I have made a proof-of-concept in the rover-webui repo and updated the relevant files of the rover software on the branch websocket-integration.
It is currently using the bottle-websocket plugin, as that appears to have removed the need for a custom thread-safe WSGI server because it is using the gevent server as a starting point.


Render deploys should work after upgrade to Yarn 4

Upgrading to Yarn 4 also broke Render deploys.
see https://github.com/bullet-train-co/bullet_train/issues/1496
and
https://feedback.render.com/features/p/add-support-for-yarn-2

does anyone have an opinion on this? Are people just not deploying current bullet-train apps to Render atm?

@kbighorse I don't use Render so I don't know if this will work, but you might try altering your render.yaml so that the buildCommand line looks like this:
buildCommand: "corepack enable && yarn && ./bin/render-build.sh"

Or alternatively you might try updating bin/render-build.sh to look like this:
#!/usr/bin/env bash
# exit on error
set -o errexit

corepack enable
yarn

bundle install
bundle exec rake assets:precompile
bundle exec rake assets:clean

# These are not combined because we want to reload all models after the migrations take place.
# TODO Any way to read these from the `Procfile` where we have the same thing defined for Heroku?
bundle exec rails db:migrate
bundle exec rails db:seed

Reference: https://community.redwoodjs.com/t/deployment-to-render-yarn-versions/5789
And based on the link you shared it look like you might have to set the SKIP_INSTALL_DEPS ENV var to true, but I don't know how or where you'd do that.
Please report back if you give this a try. If it works we can add it to the repo.

I have an open request on the render community forum. I tried a ton of options and I haven't been able to figure out what I'm missing...
render forum thread
I'll update the render.yaml and render-build.sh once I've got a working version
My working changes:
render.yaml
services:
  - type: web
    name: web
    env: ruby
    buildCommand: "./bin/render-build.sh"
    startCommand: "bundle exec puma -C config/puma.rb"
    envVars:
      - key: SKIP_INSTALL_DEPS
        value: true

bin/render-build.sh
#!/usr/bin/env bash
# exit on error
set -o errexit

echo "bundle install starting..."
bundle install

echo "enabling corepack..."
corepack enable
echo "corepack install..."
corepack install
echo "running yarn..."
yarn

echo "setting yarn version..."
yarn set version 4.2.2

echo "assets precompile starting..."
bundle exec rake assets:precompile

echo "assets clean starting..."
bundle exec rake assets:clean

echo "db:migrate starting..."
bundle exec rails db:migrate
echo "db:seed starting..."
bundle exec rails db:seed

The current output error in render is
<trimmed> everything above looks as expected
  enabling corepack...
==> Using Node.js version 20.15.0 via /opt/render/project/src/.nvmrc
==> Docs on specifying a Node.js version: https://render.com/docs/node-version
==> Using Bun version 1.1.0 (default)
==> Docs on specifying a bun version: https://render.com/docs/bun-version
corepack install...
Adding<EMAIL_ADDRESS>to the cache...
running yarn...
➤ YN0000: · Yarn 4.2.2
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed in 0s 293ms
➤ YN0000: ┌ Fetch step
➤ YN0013: │ 620 packages were added to the project (+ 139.01 MiB).
➤ YN0000: └ Completed in 14s 388ms
➤ YN0000: ┌ Link step
➤ YN0007: │ esbuild@npm:0.23.1 must be built because it never has been before or the last one failed
➤ YN0007: │ core-js@npm:3.32.2 must be built because it never has been before or the last one failed
➤ YN0000: │ core-js@npm:3.32.2 STDOUT Thank you for using core-js ( https://github.com/zloirock/core-js ) for polyfilling JavaScript standard library!
➤ YN0000: │ core-js@npm:3.32.2 STDOUT
➤ YN0000: │ core-js@npm:3.32.2 STDOUT The project needs your help! Please consider supporting core-js:
➤ YN0000: │ core-js@npm:3.32.2 STDOUT > https://opencollective.com/core-js
➤ YN0000: │ core-js@npm:3.32.2 STDOUT > https://patreon.com/zloirock
➤ YN0000: │ core-js@npm:3.32.2 STDOUT > https://boosty.to/zloirock
➤ YN0000: │ core-js@npm:3.32.2 STDOUT > bitcoin: bc1qlea7544qtsmj2rayg0lthvza9fau63ux0fstcz
➤ YN0000: │ core-js@npm:3.32.2 STDOUT
➤ YN0000: │ core-js@npm:3.32.2 STDOUT I highly recommend reading this: https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md
➤ YN0000: │ core-js@npm:3.32.2 STDOUT
➤ YN0000: └ Completed in 7s 133ms
➤ YN0000: · Done in 22s 158ms
setting yarn version...
➤ YN0000: Done in 0s 10ms
assets precompile starting...
error This project's package.json defines "packageManager"<EMAIL_ADDRESS>However the current global version of Yarn is 1.22.22.
Presence of the "packageManager" field indicates that the project is meant to be used with Corepack, a tool included by default with all official Node.js distributions starting from 16.9 and 14.19.
Corepack must currently be enabled by running corepack enable in your terminal. For more information, check out https://yarnpkg.com/corepack.
rake aborted!
jsbundling-rails: Command install failed, ensure yarn is installed
/opt/render/project/.gems/ruby/3.3.0/gems/jsbundling-rails-1.3.1/lib/tasks/jsbundling/build.rake:6:in `block (2 levels) in <main>'


Add --backend-snapshot-with-purging-changes flag

What this PR does / why we need it:
This commit implements the --backend-snapshot-with-purging-changes flag.
If the above flag is used, changes that are not needed because they are recorded in the snapshot are removed to save storage.
This enables the option to delete old changes when creating a snapshot.
Which issue(s) this PR fixes:

Fixes #288
Special notes for your reviewer:
More specifically, the changes that are deleted are before the lowest serverSeq recorded in the syncedseqs collection.
So it is based on the most lastly updated value in syncedseqs, not the changes just before the snapshot.
The reason is to avoid an error when there is a process of finding change when working UpdateAndFindMinSyncedTicket function.
Does this PR introduce a user-facing change?:

Users can now use the '--backend-snapshot-with-purging-changes' flag when run yorkie server. This can help save db storage.
yorkie server --backend-snapshot-with-purging-changes

Additional documentation:

Checklist:

[x] Added relevant tests or not required
[x] Didn't break anything

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

@chromato99 Thanks for your contribution.
Does history command work after purging changes?
https://github.com/yorkie-team/yorkie/pull/360

Ah, I forgot the history command and didn't test it..
When I rebased with the newly added document ls command commit and test it now, it seems that the ListChangeSummaries is assuming that there are all changes, so there is an error.
I think it can fix, when the --backend-snapshot-with-purging-changes flag exists, just print the existing changes not from seq 1.
I'll edit the code and commit it.

As shown in the screenshot above, when the --backend-snapshot-with-purging-changes flag is used, only changes since the latest snapshot are displayed.
However, I think that too many functions have been added for exception handling. If you have any good comments, please feel free to tell:)

Thanks for the test.
The history will be reduced after introducing revisions that point to meaningful changes in the future.
Could you fix the conflict by rebasing or merging the main branch?

Yes, I resolved the conflict!

There was a problem with the auto merged part, so I rebase it.

I think I overlooked the test. Thanks for your comments.
I will work on the test part more.

I added simple handling for hisotry_test!


feat(dbaas): OpenSearch service type support

Added comment about database properties (and outdated code-comment), otherwise LGTM!


Re-evaluate / re-implement fonts

[ ] re-evaluate fonts

[x] What Font Should I Use?
[x] How to choose the right face for a beautiful body
[x] main text-body font, sans serif:

Origin: https://www.fontsquirrel.com/fonts/dejavu-sans
Selection: https://github.com/github/mona-sans

SIL OFL v1.1
variable font
current favorite

https://www.fontsquirrel.com/fonts/be-vietnam

SIL OFL v1.1
great readability (as evaluated wth Be Vietnam Pro on Googlefonts)
https://github.com/bettergui/BeVietnamPro

https://www.fontsquirrel.com/fonts/fira-sans

SIL OFL v1.1
really huge set of glyphs
really many variations
probably even better: https://github.com/bBoxType/FiraGO

https://www.fontsquirrel.com/fonts/source-sans-pro
https://www.fontsquirrel.com/fonts/arimo
https://www.fontsquirrel.com/fonts/pt-sans
https://www.fontsquirrel.com/fonts/rubik

SIL OFL v1.1
slightly rounded edges, might be too playful for the desired impression

https://www.fontsquirrel.com/fonts/dosis
https://www.fontsquirrel.com/fonts/lato
https://www.fontsquirrel.com/fonts/tanohe-sans
https://www.fontsquirrel.com/fonts/encode-sans
https://www.fontsquirrel.com/fonts/khula
https://www.fontsquirrel.com/fonts/spartan-mb
https://www.fontsquirrel.com/fonts/luiss

[ ] source code font, monospace: tbd

https://www.fontsquirrel.com/fonts/fira-code
https://www.fontsquirrel.com/fonts/hack
https://www.fontsquirrel.com/fonts/recursive-sans

This is a true variable font! It may be used to provide normal text, bold text, italic text and monospaced text, all from a single font file!
https://www.recursive.design/
Doesn't work as body text font!

[ ] quote font, serif: tbd

https://www.fontsquirrel.com/fonts/playfair-display
https://www.fontsquirrel.com/fonts/inria-serif
https://www.theleagueofmoveabletype.com/goudy-bookletter-1911
https://www.fontsquirrel.com/fonts/libre-caslon

[ ] check implementation of the provided webfonts

[ ] https://developer.mozilla.org/en-US/docs/Learn/CSS/Styling_text/Web_fonts
[ ] https://developer.mozilla.org/en-US/docs/Learn/CSS/Styling_text/Fundamentals#font_families
[ ] https://blog.logrocket.com/how-to-use-web-fonts-css/
[ ] https://css-tricks.com/snippets/css/using-font-face-in-css/
[ ] https://css-tricks.com/how-to-load-fonts-in-a-way-that-fights-fout-and-makes-lighthouse-happy/
[ ] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Fonts/Variable_Fonts_Guide
[ ] https://web.dev/variable-fonts/
[ ] https://variablefonts.io/implementing-variable-fonts/

[x] Check caniuse: Basically all modern browsers already support the feature!
[x] https://blog.logrocket.com/variable-fonts-is-the-performance-trade-off-worth-it/ Might not be worth the effort!

[ ] https://www.cssfontstack.com/

Ranking (without actual testing)

Be Vietnam
FiraGo (with Fira Code for monospace)
Arimo
PT Sans

Resources

https://fonts.google.com/knowledge/choosing_type/a_checklist_for_choosing_type
https://fonts.google.com/knowledge/choosing_type/emotive_considerations_for_choosing_typefaces
https://fonts.google.com/knowledge/choosing_type/pairing_typefaces

Splittet into two dedicated issues, 80% (this issue) completed, see #55 for the remaining 20%.


Implemented lazy attribute creation in pair with Ruby's post version …

…2.2.3 OpenStruct.
Accessor methods are now only created when needed. See pull requests 1033 and 1037 on Ruby's githug for more information on the upstream change.
This fixes #38.

How does the OpenStruct in 2.2.3dev handle respond_to? for lazily defined methods vs its older behavior? Does it act like the methods exist, or will it return false until it defines a given method?
I will take a closer look at the PR tonight or this weekend, but it would probably be a good idea to get Travis to run against ruby-head as well. Travis' ruby 2.2 support looks like it uses 2.2.0 instead of the latest stable 2.2.

In 2.2.3 and earlier repond_to? would return true since all methods are defined as soon as the key is present in the table hash. Lazy definition of accessor methods post-2.2.3 would mean that it could return false if not accessed before. To overcome this, the repsond_to_missing? has been added to post 2.2.3 OpenStruct. I have copied this behaviour in my patch.
BTW: there already exist a couple of tests in open_struct_behavior_spec.rb that check exactly that (#respond? and #methods tests).
TL;DR; It behaves the same.

Sounds good. I will look at getting it merged soon.
On Thu, Oct 29, 2015 at 1:51 AM, Kris Dekeyser<EMAIL_ADDRESS>wrote:

In 2.2.3 and earlier repond_to? would return true since all methods are
defined as soon as the key is present in the table hash. Lazy definition of
accessor methods post-2.2.3 would mean that it could return false if not
accessed before. To overcome this, the repsond_to_missing? has been added
to post 2.2.3 OpenStruct. I have copied this behaviour in my patch.
BTW: there already exist a couple of tests in open_struct_behavior_spec.rb
that check exactly that (#respond? and #methods tests).
TL;DR; It behaves the same.
—
Reply to this email directly or view it on GitHub
https://github.com/aetherknight/recursive-open-struct/pull/39#issuecomment-152114858
.

@aetherknight Thanks for working on this gem!  2.3.0 is supposed to be released in 2 weeks, so I tested @Kris-LIBIS's work in this PR against:

2.3.0-preview2
2.2.3
2.1.7
2.0.0-p647
1.9.3-p547

It's good on all of those versions.
In case others see this against master...
master is currently breaking on 2.3.0-preview2 due to the referenced issue.  It fails with:
NameError or NoMethodError exceptions like these:
  1) RecursiveOpenStruct indifferent access overwriting values keeps original keys after resetting value
     Failure/Error: recursive.foo.first[:bar].first[:foo] = :foo

     NoMethodError:
       undefined method `first' for nil:NilClass
     # ./spec/recursive_open_struct/indifferent_access_spec.rb:141:in `block (5 levels) in <top (required)>'

  2) RecursiveOpenStruct OpenStruct 2.0 methods delete_field removes the value
     Failure/Error: singleton_class.__send__(:remove_method, sym, "#{sym}=")

     NameError:
       method `foo' not defined in #<Class:#<RecursiveOpenStruct:0x007ff6ac40d440>>
     # ./lib/recursive_open_struct.rb:86:in `remove_method'
     # ./lib/recursive_open_struct.rb:86:in `delete_field'
     # ./spec/recursive_open_struct/ostruct_2_0_0_spec.rb:26:in `block (4 levels) in <top (required)>'

@jrafanie I just pushed a 1.0.0 release of ROS out which incorporates the changes. The main API breaking change has to do with #34 and #40 . Let me know if you encounter any regressions.
The travis builds are claiming to fail, but that is because I added 2.3.0 to the .travis.yml file to automatically support it once it is officially released. The ruby-head tests are passing, however.

@aetherknight Nice, thank you!  I'll try it out and report any problems.


Front-end portability

The site should be portable - a partner should be able to clone the code and spin up their own front end, just changing some config files for colour themes, links to logos / images / branding, etc.
New instantiations of the site will have to point (via (a) config file(s)) to their input sources for records and other data.
Front-end devs should sync carefully with back-end devs to make sure that new instances are stable and can stably connect to their sources within the ODIS Architecture. This issue will be cross-linked to a demonstration case with IOC Africa.

https://github.com/iodepo/oih-ui/blob/feature/restyling/frontend/README.md


Improve  osm_id_geometry function

Added ST_MultiPolygon, MultiLineString and ST_MultiPoint to osm_id_geometry function
Replace use of GeometryType with ST_GeometryType

Good.
OSM ID is no longer really correct if we do clustering though anyway. But that is not a problem of this PR.


Add basic multi-year support

Work in progress
Simplify and try to refactor the code in #741 to make a more manageable pull request.
Implement basic multi-year support.
Pull request details
Describe the changes made in this pull request

List of related issues or pull requests
Related to #740 and #741
Collaboration confirmation
As a contributor I confirm

[x] I read and followed the instructions in README.dev.md
[ ] The documentation is up to date with the changes introduced in this Pull Request (or NA)
[ ] Tests are passing
[ ] Lint is passing

My approach was:
Start from Ni's PR
Remove all investment_year (changed to year in some cases) and new constraints
Focus on having a new column year, keeping Ni's structure changes, and making the tests pass
Don't think too much about timeframe
Don't think about efficiency
The situation so far is
Tests are passing, but not 100% coverage, and docs are broken.
It is rebased on top of main.
The changes are still massive and maybe that is unavoidable. 95% of places with a graph[a].prop need a small change to add [year].
There are 6 commits, mostly independent, but not atomic.
The model right now is essentially a model per year.
I've decided to keep the new investment variables (with sparse indexes) as it is, because the alternative would be figuring out a worse temporary way of dealing with years.

Open questions:

Can we make this even smaller?
How do timeframe and year interact?

@gnawin

I noticed we used the parameter active in many places, that was on me because back then I was not fully sure about the data structure and now I have more ideas. I just want to mention that most probably we'll have to adapt that soon. Do you think this would be a structural change then? I think we have no other way out for now, but still I'd like to raise this question.

I think it won't be as bad. Also, checking for active should be fine either way.

I also want to double-check with you that the changes to the model in this PR, i.e., the variables and objective, only add an index to the current model. And that all the results would only have an extra year index, which is 2030 by default. Is this correct?

The changes to the model should be only "add year to variables".
All the results for existing test cases should not change. The year 2030 was added for all of them, but since it is the same for all of them, nothing changes.

And a related question: even if we don't do multi-year, do we always have to have the year index for the outputs? Probably a separate issue, but I'm thinking maybe we could, in such cases, modify the outputs so we don't have the year index.

That's probably better handled as post-processing. The full output data includes the year, and removing it for this case doesn't feel like a Tulipa task.

Thanks for the review!


Leave some suggestions for future features

Any ideas would be appreciated and taken into consideration in the future, please leave some below it would help me grow this project into something larger.

personally i would like a simpler system of setting up things like Take profits and stop losses when i set a market order.
I am going to try running your code on golang, when i get the time, but i couldnt see how to set up an order like
"market buy SL 500pips TP 1000pips" sort of input.

Add feature to update stoploss and take profit

Done - I have pushed it to main branch

Add feature to update stoploss and take profit

Done - I have pushed it to main branch

personally i would like a simpler system of setting up things like Take profits and stop losses when i set a market order.
I am going to try running your code on golang, when i get the time, but i couldnt see how to set up an order like
"market buy SL 500pips TP 1000pips" sort of input.

This has also been done and is pushed to the main branch

awesome, saw the code changes to that TP SL thing zleki, just thinking the "examples" buy stuff needs to be updated now

awesome, saw the code changes to that TP SL thing zleki, just thinking the "examples" buy stuff needs to be updated now

You're right, i'll edit them thanks.

Would like to get market data

Would like to get market data

Unfortunately it cannot be done due to their api restrictions

is there anyway I can submit trailing stop loss with if then in order /modify order

is there anyway I can submit trailing stop loss with if then in order /modify order

Yeah but calculations must be done server side because dxtrade doesn't offer trailing stops on their platform unfortunately

i think an installation guide and running guide might be useful. Am currently noob at golang, so not knowing where to start is tough. :)
Thank you for the library anyways :D

@zLeki thank you very much for your awesome work

@zLeki Thanks for your work, currently working on an EA for MT5 to copy trades to DXTrade, the only thing is that I cannot find any documentation using the https://dxtrade.*****.com/api/ endpoint? Where did you find this?

A lot of digging through the chrome network tab lmao

A lot of digging through the chrome network tab lmao @0xRowie

I was afraid you were going to say that, I'm doing so myself right now 😭 @zLeki
Thanks for the quick response! I appreciate it.

is there an ability to grab previous candle history?

To the best of my understanding, it seems like it can't be done. But, feel free to try your hand at it. I suggest you look at the websocket contents because the info you want is there. Sadly, the code can only get candlestick data in the browser.

is there an ability to grab previous candle history?

I was able to solve this using web socket and requesting for quote. Please check the network trace of the dxtrade. it has lot of features.

@kpathan Thank you for your help! I am pushing an update which includes the ability to fetch candlestick data.

I would like to calculate lot size with fixed amount to risk.
Ex: $250 to risk, With Entry, Stoploss. Take Profit is also know, but does not matter.
I am new to forex, so I need some help with that
Thanks in Advance.

@kpathan Thank you for your help! I am pushing an update which includes the ability to fetch candlestick data.

Great work!!!

how can i run this, noob in go

Hello,
in the description of project is published the following information.
"API for dxtrade that can be used with all golang applications to open, close, and manage positions with your dxtrade account. It works with all prop firms or companies that use dxtrade"
We have tried to connect this SDK with any DXTRADE account but without success.
Could you provide some small example how to use your SDK with any DXTRADE account ?
Thank you in advance.


Update french translation file

Short description of what this resolves:
Hi, I updated/corrected some french translation.
Changes proposed in this pull request:

Correct french translation
Remove unnecessary capital letters
Add missing "ext.config.lastDownload" translation

How Has This Been Tested?
This PR only change values of translation file.
Screenshots (if appropriate):
🦄
Checklist:

[ ] I have read the contribution guidelines.
[ ] My change requires a change to the documentation and GitHub Wiki.
[ ] I have updated the documentation and Wiki accordingly.

Hi @o3LL
there are some conflicts, you need to resolve them.

Done! I deleted "ext.config.askGistName", since it seem that its not used anymore.

Thanks.


docs: document dictionary responses

Document set, dictionary, and list responses. Enables compiler warning for undocumented publicly visible things; zero warnings after this PR.
Closes #370

Will get to the hit/miss/error issues in a follow up PR


Error in console when running the utils>window example

Describe the bug
Console error when clicking on 'Window' in the 'Utils'
To Reproduce
Steps to reproduce the behavior:
Go to 'https://digipolisantwerp.github.io/acpaas-ui_angular/modules/utils/window'
Expected behavior
works in local version!
Screenshots
If applicable, add screenshots to help explain your problem.
OS (please complete the following information):

Device: MacBook Air
OS: macOS Mojave
Browser: All

Screenshots

Fixed with PR #100


[BACKEND] Fix crash in combine select and if op

When multiple selects gets merged to the same ifop we need to make sure we don't use a stale IfOp during transformation.

Thanks for the review!


remove unused initialization

cleanedUsDollarAmount: str
This will make sure that all branches assign a string before it's used.
For example, something like this:
        cleanedUsDollarAmount: str

        if usDollarFloat.is_integer():
            cleanedUsDollarAmount = str(int(usDollarFloat))
        elif usDollarFloat < 3.5:
            cleanedUsDollarAmount = '{:.2f}'.format(usDollarFloat)

        return [
            f'{match.group(1)} usd',
            cleanedUsDollarAmount
        ]

would make a type checking error, because not all possible branches assign a str to cleanedUsDollarAmount

Thank you!!

I didn't even realize that I did this 😳


feat: is it possible to have access to pages and app both with one trpc setup

Is your feature request related to a problem? Please describe.
When I mixte the 2 installs : one with pages mode and the second with app mode, two use the ~/server I got a conflict:
"src/pages/api/auth/[...nextauth].ts" - "src/app/api/auth/[...nextauth]/route.ts"
"src/pages/api/trpc/[trpc].ts" - "src/app/api/trpc/[trpc]/route.ts"

Describe the solution you'd like to see
Is it possible to make work, each route may use app or pages, vercel say its possible ?
Describe alternate solutions
I have nothing alternate solution.
Additional information
No response

You cannot have the same route (same URL) in app and pages. You may use them together, but they cannot collide. I'd recommend using app router for all your route handlers. You can choose to use both app and pages router for pages if you want (incremental adoption being the no. 1 reason to do so)


view() is rendered when passed as component attribute

Laravel Version
v11.11.1
PHP Version
8.2
Database Driver & Version
No response
Description
The following does not pass the view as a View class, but renders it to HTML.
<x-test :content="view('content')" />

As it turns out, this only happens for Renderable classes. This has been in Laravel since the first commit.
This feels inconsistent as other 'renderable' classes are not converted, such as Htmlable's. As it's part of the first commit I cannot find why this was added/necessary but making changes to will likely be breaking.

Sidenote: this happened to me in Filament where you can't use slots.

Steps To Reproduce
See: https://github.com/ju5t/view-prop
Commit: https://github.com/ju5t/view-prop/commit/a60d9de4646944306f4e462f51fed8a0fac3c11b

Hi @ju5t. I want to thank you for the clear issue and repro repository. Since this has been something that's been in core for so long I don't think we can consider this a bug but working as intended. Please also note that Htmlable and Renderable are two very different interfaces.


Input metadata small fix

The SCALE_INPUT_METADATA_PATH file doesn't exist so it needs the + operator on open.
The tmp folder does not exist so it needs to be made.

Why the tmp folder?  That seems crappy.

On Sep 10, 2019, at 4:54 PM, Mike Holt<EMAIL_ADDRESS>wrote:
The SCALE_INPUT_METADATA_PATH file doesn't exist so it needs the + operator on open.
The tmp folder does not exist so it needs to be made.
You can view, comment on, or merge this pull request online at:
https://github.com/ngageoint/scale/pull/1781
Commit Summary
added file creation logic
File Changes
M scale/job/management/commands/scale_pre_steps.py (5)
Patch Links:
https://github.com/ngageoint/scale/pull/1781.patch
https://github.com/ngageoint/scale/pull/1781.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Why the tmp folder? That seems crappy.
…

fixed

Are you sure the mkdir won't cause an exception in the pre_step (not in the unit test, but in a deployed state) when it already exists? Python is real picky about this: https://stackoverflow.com/questions/600268/mkdir-p-functionality-in-python

GREAT CALL.  That line was needed when /tmp was in the path but I think it is obsolete now that the metadata file lives in the root folder for inputs.


Ctrl+Shift+0 (Show wrap symbols) does not toggle

First time looking at this light editor...
It seems that the Ctrl+Shift+0 (Show wrap symbols) shortcut does not toggle the option. Can enable it only via menu.
Ctrl+Shift+8 and Ctrl+Shift+9 both works.

Indeed, confirmed.
Does it happen with vanilla Notepad2? I don't recall touching that code at all, but it might be a typo that broke it somewhere along the way.

Does it happen with vanilla Notepad2?
Yes, both in 4.2.25 and 5.0.26beta

Windows IME causes this problem.
https://support.microsoft.com/en-us/kb/967893

Windows IME causes this problem.
https://support.microsoft.com/en-us/kb/967893

Exact! You solved the mystery.
@XhmikosR, perhaps a new shortcut would be better? I'd suggest reduce by one these Ctrl+Shift numbers (7,8,9 instead of 8,9,0), if there's no conflict.


what about multi-person?

Hello, can it works well when multi-person in cross-view?

Thanks. It's a good question. In short, the answer is no. This network only focuses on single-person, similar to Epipolar Transformers.
To make it work on multi-person, you have to modify the architecture since multi-person multi-view setting requires aligning different persons from different views.

thanks your nicely reply, i will try lately!


[alpha13] Sugar Cane(and other crops) duplicates again

And a lot of lags...

This should've been fixed when I fixed growth infusion.

This should've been fixed when I fixed growth infusion.


Add GEOS_Util repo

With the split of GEOS_Util from GMAO_Shared, the develop branch is now not happy since it points to the main branch of GMAO_Shared and now the ldas doesn't see any of GEOS_Util.

@mathomp4, thanks for getting the PR underway.   I suppose adding the new GEOS_Util repo to GEOSldas would be the quickest fix.  But I'm not sure it's what we want.
If we're reorganizing GMAO_Shared and GEOS_Util, I'm not sure "remap_restart" should remain in GEOS_Util/post/remap_restart/.  This utility can be thought of as post-processing, but to me it's equally sensible as a pre-processing utility.
Would it make more sense to add the restart remapping code to the GCM GridComp Utils/mk_restarts directory?  Then the restart-related code would be in one place (for the most part).  The downside may be that it might be harder to phase out the old "regridding" tools if the new tools aren't sitting right next to it.
@sdrabenh: What do you think?

From @sdrabenh:

We had a couple reasons for splitting off GEOS_Util. First, Ricardo always preferred stand-alone GMAO_Shared releases to isolatie plot updates – I guess so he could cherry-pick things more easily. Second, most things outside of GEOS_Util are more relevant to the DAS and it didn’t make sense for me to be deciding the fate of those pull requests. Ricardo had long suggested breaking this out into a separate repository. I tend to agree with you that these regridding tools are really more preprocessing than postprocessing, so I would think the proper place for them would be in @GEOS_Util/pre. Of course that begs the question should mk_restarts also be there as more of a stand-alone package? As far as the perl and python tools remaining next to each other, they still would in “./install/bin” which is the proper directory to be using them. We could even move the pearl script into pre so they would sit together.

It makes sense to me to break up GMAO_Shared.  The two elements of interest to GEOSldas are:

remap_restarts: Since the underlying Fortran code is very closely tied to the model code (at least for Catchment), I don't think we want to move remap_restarts out of the GCM GC.  I didn't check what would be involved in making the underlying utilities work outside of the GCM GC, but my gut feeling is that it would require some duplication of model stuff in GEOS_Util.  If someone can prove me wrong, I'm happy to have all of the restart code in GEOS_Util.  Failing that, I'd add the remap_restarts python scripts into the GCM GC.

Does the DAS use the surface layer science code in GMAO_Shared/GEOS_Shared?  My (uneducated) guess is that this is model code more than DAS code.  This code is the reason that GEOSldas taps into the development ("main") branch of GMAO_Shared.   Arguably, this code hasn't changed in ages, but that doesn't mean it won't ever change.  Is there a better place for the code in "GEOS_Shared" than in the GMAO_Shared repo?

cc: @biljanaorescanin @weiyuan-jiang @mathomp4

I would advocate for tools to regrid restarts be located in @GEOS_Util/pre since they are more than just surface (upper air) and really do not belong in GEOSsurface_GridComp/Utils.

Good point.  I guess I was outing myself as surface-centric ;)    Let's move remap_restarts python scripts to GEOS_Util/pre then.
I'm still hesitant to think that the underlying Fortran could be moved to GEOS_Util without drawbacks.
Any thoughts on the science code in GEOS_Shared?

I would advocate for tools to regrid restarts be located in @GEOS_Util/pre since they are more than just surface (upper air) and really do not belong in GEOSsurface_GridComp/Utils.

Good point. I guess I was outing myself as surface-centric ;) Let's move remap_restarts python scripts to GEOS_Util/pre then. I'm still hesitant to think that the underlying Fortran could be moved to GEOS_Util without drawbacks.

I'm not too worried since those tools are designed to work on restarts dating back to MERRA, so it's not really tied to a specific version of the GEOSgcm_GridComp per se. For future restart changes, the user will have to grab a more recent release of GEOS_Util anyway. Typically, users want the most recent release anyway.

Any thoughts on the science code in GEOS_Shared?

Good question. Scanning through GEOS_Shared most files haven't been touched since we moved to git. I don't think DAS is doing much with these files based on a recent tag by @rtodling :
https://github.com/GEOS-ESM/GMAO_Shared/compare/v1.6.5...rt_g530_1.6.0_merge
Most changes are outside of GMAO_Shared

Scanning through GEOS_Shared most files haven't been touched since we moved to git. I don't think DAS is doing much with these files

If the GEOS_Shared files are used by the model but not the DAS, and if the point of the new repo is to have GMAO_Shared be more focused on DAS code, then wouldn't it make sense to move GEOS_Shared into GEOS_Util, the GCM GridComp, or some other, more model-specific repo?
GEOSldas uses "GEOS_Shared/surface_layer.F90" (which must also be used by the GCM), which is pure model code.
Many of the other routines in GEOS_Shared seem to just support surfacelayer.F90, including fairly basics physics (e.g., "qsat.code"), although there are also other bits with which I'm not familiar.
@mathomp4, @sdrabenh:  Would it be feasible to also remove GEOS_Shared from GMAO_Shared while we're at it?  I don't know where it should go, but it doesn't seem to fit into GMAO_Shared.  If we can move GEOS_Shared, we could remove the GEOSldas dependency on the development ("main") branch of GMAO_Shared.  Please advise, thanks.

@gmao-rreichle As long as the higher-ups are happy, I can pull GEOS_Shared into its own repo as well. Of course, then you get fun things like two repos named GMAO_Shared and GEOS_Shared. But I suppose now we have GMAO_Shared/GEOS_Shared anyway so... 🤷🏼
But if @wmputman, @rtodling, @sdrabenh, etc. agree on it then I can pull it out as well.

@gmao-rreichle I'm not sure why GEOS_Shared should be moved at all, especially if there is not a clear place where it belongs that is better. It is shared by definition of its own name, and I'm sure these routines are not strictly limited to the gcm. I don't necessarily agree that GMAO_Shared is going to be DAS-centric as much as GMAO_Util was quite unique for the modeling group and contained many of @lltakacs scripts including the plot package that we maintain which justified the succession. Additionally, I'd be very hesitant to add yet another sub-repo to a very long list now, especially given how confusing the names would be between the existing GMAO_Shared and a proposed GEOS_Shared. If the criteria to remove the dependency of the main branch for GEOSldas is GEOS_Util, why can't we safely do that now? Aside from 2 files changes 2+ years ago, there haven't been any changes in this directory since we switched to git over 3 years ago. Therefore, it may not be necessary to stay on the bleeding edge of development if it is only this directory. If GEOSldas could be moved off the main branch in lieu of a tag, there wouldn't be so many unforeseen issues with changes. @mathomp4 is it possible the specific files here would require @gmao-rreichle approval for changes? Regardless of that, I would be in favor of leaving GEOS_Shared where it is now unless there is a problem.

I can pull GEOS_Shared into its own repo

I wasn't really thinking a new repo.  Rather, maybe there is a place within an existing repo where this code might live?  To me, this stuff looks like model code that could fit somewhere in GCM GC.

Sorry, I had composed and sent off my previous comment before seeing @sdrabenh's comment..

If the criteria to remove the dependency of the main branch for GEOSldas is GEOS_Shared, why can't we safely do that now?

The dependency exists because GEOS_Shared/surfacelayer.F90 (surface turbulence) is an integral part of the model.  The LDAS needs to stay on the bleeding edge of anything to do with the model's surface, incl. surfacelayer.F90.   The fact that surfacelayer.F90 hasn't been touched in ages doesn't guarantee it's set in stone.  If surfacelayer.F90 remains where it is now, GEOSldas will have to keep pointing to GMAO_Shared "main".  That's not the end of the world.  I just thought it would make sense to check if the modeling group really wants surfacelayer.F90 to remain in GMAO_Shared.

The dependency exists because GEOS_Shared/surfacelayer.F90 (surface turbulence) is an integral part of the model. The LDAS needs to stay on the bleeding edge of anything to do with the model's surface, incl. surfacelayer.F90. The fact that surfacelayer.F90 hasn't been touched in ages doesn't guarantee it's set in stone. If surfacelayer.F90 remains where it is now, GEOSldas will have to keep pointing to GMAO_Shared "main". That's not the end of the world. I just thought it would make sense to check if the modeling group really wants surfacelayer.F90 to remain in GMAO_Shared.

@gmao-rreichle I agree, just because it hasn't changes in while does not guarantee it won't. If @mathomp4 says it's possible to require your approval for PRs touching surfacelayer.F90 or even GEOS_Shared, would that work for the land group? I would really like to get you all off the main branch so you don't get hit over the head with changes quite as often as you do now.

add an entry in .github/CODEOWNERS for surfacelayer.F90 so that any changes would have to be approved by land team

That's an option, of course, although the approval requirement would need to apply to all of the files that are used by surfacelayer.F90 (or all of GEOS_Shared for simplicity).
The benefit of this approach is that the land team would be alerted to any changes in GEOS_Shared before they are merged into "main".  The downside is that it would require manual intervention (i.e., testing) each time GEOS_Shared is touched.
With the dependency on the "main" branch, on the other hand, the testing of GMAO_Shared "main" in GEOSldas happens automatically with the LDAS Nightly tests, albeit after the fact.

I would really like to get you all off the main branch so you don't get hit over the head with changes quite as often as you do now.

Since there have no changes to GEOS_Shared, this wasn't really an issue, and the changes of last Friday were detected by the LDAS Nightly tests as designed.  Most of what's happening in GMAO_Shared is actually of no consequence for GEOSldas, and that is the case in both of the above options.
To summarize: Either way is fine with me.  All we need is a formal and automated process that alerts the land team of any changes in GEOS_Shared.  I'll leave it up to @mathomp4 and @sdrabenh to pick which option works better as a whole.

@gmao-rreichle Well, surfacelayer.F90 seems to depend on MAPL and DragCoefficients.F90.
I could add any/all of:

surface-preproc-team
land-team
landice-team
etc.

as an (additional) CODEOWNER to those files if you like. I need to update the GMAO_Shared CODEOWNERS anyway, so let me know what you'd prefer.
There is also atmOceanIntLayer.F90 which is...so many teams? Land? Atmosphere? Ocean? I mean, at least @sanAkel ...

Honestly, maybe letting the Land Team know anytime anything is touched in GMAO_Shared is a good thing. I mean, good ol qsat seems to affect everyone!

@mathomp4:
Since surfacelayer.F90 is not preprocessing, it should be "land-team".  The dependency extends beyond DragCoefficients.F90.  See #include statements within the latter.

letting the Land Team know anytime anything is touched in GMAO_Shared is a good thing. I mean, good ol qsat seems to affect everyone!

Yes, but I don't think we need to know anything in GMAO_Shared.  Anything in GEOS_Shared should be sufficient.

I think a key difference here is that GEOSldas is an operational system with dependencies in GEOS_Shared. I don't think we need approvals from a whole bunch of teams or the entire shared repo, just the minimum necessary to catch anything before it impacts products. Nightlies and CI checks should be sufficient for everyone else. Let's add the land-team as a code owner of GEOS_Shared and we can finally have GEOSldas using a tag. Yay!

I removed the dependency on the GMAO_Shared "main" branch: https://github.com/GEOS-ESM/GEOSldas/pull/623/commits/9cba134509d6ec896e3397fb99efe4cc315c6579
@mathomp4: Please go ahead and add the land-team as CODEOWNERS of GMAO_Shared/GEOS_Shared
@biljanaorescanin:  Please test this PR.  If all tests pass, please approve and merge.
@sdrabenh: If you still think it's a good idea, please move GEOS_Util/post/remap_restart to GEOS_Util/pre.  Since the present PR points GEOSldas to the existing GEOS_Util v1.0.1 release, we can worry later about any changes that this might require for GEOSldas (likely not an issue anyway since we should only need executables from GEOS_Util).
I hope this resolves everything.  Please let me know if you have any questions or concerns.  I wouldn't be surprised if I got something wrong again...

@sdrabenh: If you still think it's a good idea, please move GEOS_Util/post/remap_restart to GEOS_Util/pre. Since the present PR points GEOSldas to the existing GEOS_Util v1.0.1 release, we can worry later about any changes that this might require for GEOSldas (likely not an issue anyway since we should only need executables from GEOS_Util).

I'm fine with moving all restart regridding tools into @GEOS_Util/pre since that is more logical. That think that should be rather straightforward since the files are in the same repo.

Good catch @mathomp4 'atmOceanIntLayer.F90' can go wherever-- new place. In a few years, I will deprecate its functionality.

All tests passed.


Use long term statistics instead of state only

Checklist

[x] I am running the latest version of the card
[ x I checked if there isn't another feature request opened with the same request
[xI checked that the feature is not already available in the dev branch

Is your feature request related to a problem? Please describe.
I would like to use the long term statistics data, that are not purged.
Nowadays we can just use the states data, that by default is purged in 10 days.
Describe the solution you'd like
As mentioned before
Describe alternatives you've considered
None
Additional context
I would like to have a consumption/generation kwh  graph with data more than 10 days.

After upgrading and clearing all the caches, I still get only the last 10 days. How do I switch to the long term statistics?


Don't run code on importing data module

This avoids import loops and is a stepping stone towards pluggable data layers.

@dosu Do you see any potential pitfalls or issues coming from this branch, looking at the overall code structure?


Enable specifying Validator implementation in ValidationControllerFactory.createForCurrentScope()

from: https://github.com/aurelia/validation/pull/338
cc @dkent600 @doktordirk

The test 'createForCurrentScope' results in the injection of "Validator " instead of StandardValidator.  This seems like an error, but is not reported by the test.
The test 'createForCurrentScopeWithValidator' fails if you supply {} as the validator for ValidationControllerFactory.createForCurrentScope.

the cheapest way might even be appropriate
  create(validator?: Validator) {
    const controller = this.container.invoke(ValidationController);
    if (validator) {
      controller.validator = validator;
    }
    return controller ;
  }


godep get fetches dependencies unnecessarily

godep get x fetches all x's dependencies as go get x would, even when they aren't needed since all x's depencencies are vendored with godep.

Also, godep restore fails without a network connection even though local versions exists in the godep workspace. Is this how godep is designed to work or is it a bug?

I would also like to know this, I have instances in AWS in a VPC so go get wont work there. If all the source code is available in the godep workspace why is this not utilized?

Same, running into an issue with a private repo on github. Will look at this code and see if we can add some flags to the godep restore command and if not, will see about submitting a patch.

get is a holdover from when godep didn't save the files. You generally don't need to use it.


feat(runner): Add silent option to run

This allows you to use runner.run without it having to log to stdout. Useful for scripts that are already spawning Karma and can simply log from that process.

Closing due to inactivity. Feel free to open a new issue/pr if this is still relevant for you.


systembus-notify: 1.0 -> 1.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/rfjakob/systembus-notify/releases.
meta.description for systembus-notify is: "System bus notification daemon"
meta.homepage for systembus-notify is: "https://github.com/rfjakob/systembus-notify"
meta.changelog for systembus-notify is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

directory tree listing: https://gist.github.com/0c83164329883f71c0c13d8de815e95f

du listing: https://gist.github.com/c3a73369d3f3cc2fdd808fba1b4eb0bf

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
systembus-notify

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/x59bn9f6hnsmj6dx57ihajrp4dnhynwm-systembus-notify-1.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A systembus-notify https://github.com/r-ryantm/nixpkgs/archive/0c69cd70066a0ebd5aa957babbb97c424a691128.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/x59bn9f6hnsmj6dx57ihajrp4dnhynwm-systembus-notify-1.1
ls -la /nix/store/x59bn9f6hnsmj6dx57ihajrp4dnhynwm-systembus-notify-1.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review 1

1 package built:

systembus-notify

Maintainer pings

Result of nixpkgs-review pr 96157 1

1 package built:
- systembus-notify


Fix unresolved Python object links in news fragments for 3.0

As witnessed on https://falcon.readthedocs.io/en/3.0.0b1/changes/3.0.0.html, some links to Python objects are not resolved (shown as dark bold text instead). Revise and improve the affected news fragments.
An easy way to build the preview version is:
tox -e towncrier

[ ] Fix Towncrier fragments
[ ] Explore Sphinx options if there is a flag to emit a warning in this scenario

don't we have an action gate for this?

We do, but apparently this does not generate any warning in Sphinx.

I think sphinx should have a flag for it. I definitely saw them sometimes, but I'm far from being an expert, so I may be mistaken

Sphinx warns about broken :ref:s, and similar, but AFAICT not about unresolved Python links.

Factored out part of this issue so we can delay to 3.1 -- https://github.com/falconry/falcon/issues/1888


Navbar indicator bugs out when page is refreshed

Basic Information
Navbar indicator points back to the home icon after a page refresh regardless of what route it is at.
Description of the issue

[ ] Fix the navbar indicator by using the next route api and useEffect

Other Information
Potential scopes:

I have pushed a fix to the i51 branch.  It uses the next/route api but not useEffect.  It bases the initial value of currentPage on the first segment of the page URL.  Should I create a pull request for this?

Sure


regular git gc doesn't do any good while cloning

I had a problem with a ~7GiB TFS repo being cloned to a 130 GiB git repo. The cloning from TFS took ages (>12h, quite a long history).
I then found out that  when I cloned that git repo again it shrunk to around 7GiB.
I'm was fiddling around with the source to fix export matadata not being applied to branches and so I reran the whole cloning. I wanten to lower the HDD space used during the clone, so I started to edit the default git repack settings. Then I accidentially broke it (and whole git gc - invalid pack.windowmemory value in global .gitconfig), so git-tfs couldn't do the git gc it. It does continue to clone though, so just the regular git gc runs were omitted.
Results:
time to clone went from 12h to 3h
size went from 130GiB to 8GiB (12GiB on disk). It did produce some 1.3 mio files, but a git gc at the ver end fixes that

Today I read in the google forum that some other guy found out it had to do with git gc silently failing, I'll definately check that out

Confirmed caused by failing git gc