Add comparison of null/nil safety and syntax

I researched these features because I was wondering if either language had a solution like Rust’s Option. Neither language does.
I decided the comparison result was “?” because D is better by default because more of its built-in types are non-nullable, but Nim can be made safer than D if you put in the work of redefining everything using the experimental not nil type annotation.

By the way, regarding this part of my description of Nim’s null handling:

The notnil feature was made experimental in 2018, but in 2020 its brief documentation is still in the wrong section of the manual

I plan to make a PR for Nim to move the not nil documentation to the correct section of the manual. I will update this PR if and when that PR is merged.
In that future update to this PR, I will update the link to not nil’s documentation. But I won’t remove all mentions of the docs being in the wrong section of the manual – it having been that way for years is still good evidence that not much attention is paid to this feature.

thanks for the PR! just click resolve when you've addressed each point (easier to track)

ping @roryokane
also see this:
https://irclogs.nim-lang.org/06-04-2020.html#13:52:31

Araq | isNil could be deprecated, it's pointless

which echos what I was thinking as well, now that seq/string can't be nil

Only ptr and ref types (and cstrings) can be nil

actually, also pointer, but... can be fixed, later.
super thanks! merging!


Feature/multi version flat db

PR description
Draft version of multi-version flat db

creates bonsai context concept
creates FlatDbArchiveStrategy
kikori worldstate provider integrated into BonsaiWorldStateProvider (not suitable for eth_getProof)

There are a handful of hacks that are marked with TODOs that are there for testing expedience.
skipping CI while in draft form
Fixed Issue(s)

fixes #5846

Context from conversation with @mattnelson, this implementation is a single column family implementation.  Read and write performance degrades as multiple versions 'pile up' in the worldstate column family.  A partitioned version of this implementation that uses separate column families for 'hot' (read/write) and a 'history' (read-only) should enable prevent degradation of execution performance, and should provide adequate historical RPC performance for use cases like block explorers.
@matkt, @jframe  - this would be like a manual checkpoint implementation, where the check point is dynamic, and we use trie logs to push old state into the history partition.

Context from conversation with @mattnelson, this implementation is a single column family implementation. Read and write performance degrades as multiple versions 'pile up' in the flat worldstate column families. A partitioned version of this implementation that uses separate column families for 'hot' (read/write) and a 'history' (read-only) should prevent degradation of execution performance, and should provide adequate historical RPC performance for use cases like block explorers.
@matkt, @jframe - this would be like a manual checkpoint implementation, where the check point is dynamic, and we use trie logs to push old state into the history partition.

seems to be a good idea


client_url is hardcoded in slave.pp

This PR intends to give the possibility to change it

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

@zonArt Could you squash these commits down and give us a headsup when you feel this PR is ready?

@jhoblitt IMHO squashing commits isn't necessary, it's often nice but meh


Bugfix/LIVE-8007 - LLD - Allow text to break in onboarding link

📝 Description
Allow text to break in onboarding link, thus fixing long text in link getting cropped
Before:

After:

❓ Context

JIRA or GitHub issue: LIVE-8007

✅ Checklist
Pull Requests must pass the CI and be code reviewed. Set as Draft if the PR is not ready.

[x] npx changeset was attached.
[ ] Covered by automatic tests.
[ ] Impact of the changes:

🧐 Checklist for the PR Reviewers

[x] The code aligns with the requirements described in the linked JIRA or GitHub issue.
[x] The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
[x] There are no undocumented trade-offs, technical debt, or maintainability issues.
[ ] The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
[x] Any new dependencies have been justified and documented.
[x] Performance considerations have been taken into account. (changes have been profiled or benchmarked if necessary)

isn't this part covered by screenshot testing? (which is one rare candidate that screenshot would help on)
we don't want to redo the whole onboarding screenshots on turkish but it could be just one specific screen that we could screenshot. may be overkill too but it's why we can't check "test automated" i guess


NewspaperPage image derivative creation

We need following image derivatives when a primary NewspaperPage file is a TIFF or PDF:

JPEG Thumbnail.
JPEG at original resolution (consumption asset)
JP2 / JPEG 2000 (preservation asset)
TIFF if original upload was grayscale JP2 or JPEG???

Thumbnails
Hyrax creates these for us, so we do not need to do much of anything.
JPEG at original resolution
We need JPEG derivatives suitable for use in IIIF viewers.
JPEG 2000
If a non-JPEG2000 image asset is uploaded as the master, we should generate and encode a JPEG2000 asset to store as a derivative, at the original resolution, as follows:

If original asset is grayscale, format according to the NDNP Profile for JPEG 2000.
If original asset is color, output something that is either lossless or "visually lossless" TBD, scope of which still needs definition.

For now, treat 1-bit black/white as grayscale; we need to determine if creation of a JPEG 2000 asset is warranted in this case, as it adds no preservation value per-se, nor technical value.

Couple comments:

Think we could remove JPEG at original resolution. The rationale being that:

A full-size JPEG isn't really necessary since we are assuming the presence of a IIIF-compliant image server (e.g. RIIIF, Loris, Cataloupe). All of these image servers use JP2 files to generate JPEG derivatives on the fly.

Add PDF

PDF files for each page are part of the NDNP digitzation output
PDF downloads were surfaced as a functional requirement

Remove TIFF if original upload was grayscale JP2 or JPEG

There's not much benefit in creating TIFs if they don't exist (no such thing as 'upsampling')
Some institutions may not have the storage space for large batches of TIF files

JPEG 2000

Since these are needed for the image server functionality, we should always create, even for 1-bit black/white original source files

@ebenenglish updated description per comments.
On the PDF front, we likely don't make PDFs strictly compliant with NDNP specs for now, because that assumes embedded OCR text, and I do not want to let that be a distraction for now.

Re: PDF, we need to determine what use case of this is.  Download for on-screen display?  Printing?
NDNP PDF profile suggests PDF images should be JPEG down-sampled to 150ppi.  The question is whether such down-sampling is generally acceptable?  Are all assets going to be readable at 150ppi?

I believe that the primary use case would be download for on-screen display.
I think the downsampling to 150 ppi should be acceptable for this use case.


azure managed disk error

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az disk list
Errors:
No module named 'antlr4'
Traceback (most recent call last):
lib/python3/dist-packages/knack/cli.py, ln 206, in invoke
    cmd_result = self.invocation.execute(args)
azure/cli/core/commands/__init__.py, ln 528, in execute
    self.commands_loader.load_arguments(command)
dist-packages/azure/cli/core/__init__.py, ln 300, in load_arguments
    loader.load_arguments(command)  # this adds entries to the argument registries
azure/cli/command_modules/vm/__init__.py, ln 31, in load_arguments
    from azure.cli.command_modules.vm._params import load_arguments
azure/cli/command_modules/vm/_params.py, ln 31, in <module>
    from azure.cli.command_modules.monitor.actions import get_period_type
azure/cli/command_modules/monitor/actions.py, ln 7, in <module>
    import antlr4
ModuleNotFoundError: No module named 'antlr4'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az disk list

Expected Behavior
Environment Summary
Linux-5.4.0-48-generic-x86_64-with-glibc2.29
Python 3.8.2
Shell: bash

azure-cli 2.0.81

Extensions:
azure-devops 0.17.0

Additional Context

hi @progzilla could you pls uninstall 2.0.81 and install latest azure cli via instruction here: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view=azure-cli-latest? This is a known issue tracked in #14011

Duplicate of #14011


Is it possible to undo/redo ?

Is it possible to detect undo/redo?

Here is undo / redo feature: https://github.com/Nicejinux/NXDrawKit
So you can investigate how it was implemented and then try implement it in the "Photo Editor" lib :)


Update service-gateway-high-availability-clusters.md

Update to explain CPU & memory usage

#sign-off


Error activating SSL

Greetings, after activating the lines in nginx.conf I change the 2 files in the certs folder obtaining them from sslforfree.com then in hub.docker.com I create the docker but when I start it it presents the following error:
nginx: [emerg] cannot load certificate "/opt/certs/live.canal6.hn.crt": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/opt/certs/live.canal6.hn.crt','r') error:2006D080:BIO routines:BIO_new_file:no such file)

Hi @canal6hn,
Are you mounting the volumes containing the certs? Do you have a docker or docker-compose command you can share?

Closing. Feel free to re-open if you can provide the info above.


fix(addon-table): added a check that total is zero

I figured that it is not necessary to output tuiDropdown at total === 0
Closes #7025

Cherry pick into v3.x would be great :)


Store the geopoint in three dimensions

This PR changes the way we store the geo points in the RTree.
Instead of considering the latitude and longitude as orthogonal coordinates, we convert them to real orthogonal coordinates projected on a sphere with a radius of 1.
This is the conversion formulae.

Which, in rust, translate to this function:
pub fn lat_lng_to_xyz(coord: &[f64; 2]) -> [f64; 3] {
    let [lat, lng] = coord.map(|f| f.to_radians());
    let x = lat.cos() * lng.cos();
    let y = lat.cos() * lng.sin();
    let z = lat.sin();

    [x, y, z]
}

Storing the points on a sphere is easier / faster to compute than storing the point on an approximation of the real earth shape.
But when we need to compute the distance between two points we still need to use the haversine distance which works with latitude and longitude.
So, to do the fewest search-time computation possible I'm now associating every point with its DocId and its lat/lng.

⚠ Should be merged once MeiliSearch v0.25.0 is released :) This fix is for v0.26.0


IconColor has no effect when loading Icon from SVG in FluentNavLink

🐛 Bug Report
IconColor has no effect when loading Icon from SVG in FluentNavLink
💻 Repro or Code Sample
Create a project using the fluentblazorwasm template. Build and run. Note the color of the icons are Color.Accent
🤔 Expected Behavior
Expect icon to have color specified.
😯 Current Behavior
💁 Possible Solution
🔦 Context
Discovered issue after adding Microsoft.FluentUI.AspNetCore.Components.Icons to use different icons. IconColor works as expected when specifying the Icon by construction.
<nav>
    <FluentNavMenu Width="250" Collapsible="true" Title="Custom navigation menu" Expanded="false">
        <FluentNavLink Href="/" Match="NavLinkMatch.All" Icon="@Icon.FromImageUrl("/images/home.svg")" IconColor="Color.Accent">Home</FluentNavLink>
        <FluentNavLink Href="mode" Icon="@(new Icons.Regular.Size20.Tv())" IconColor="Color.Accent">Counter</FluentNavLink>
        <FluentNavLink Href="counter" Icon="@Icon.FromImageUrl("/images/counter.svg")" IconColor="Color.Accent">Counter</FluentNavLink>
        <FluentNavLink Href="weather" Icon="@Icon.FromImageUrl("/images/weather.svg")" IconColor="Color.Accent">Weather</FluentNavLink>
    </FluentNavMenu>
</nav>```

## 🌍 Your Environment

* OS & Device: Windows 11
* Browser : Microsoft Edge, Google Chrome, Apple
* .NET:  .net8
*  FluentUi: v4.2.1

Hi Gary,
IconColor will indeed not work when loading an SVG file. That is sort of 'by design' as we can't use the same way of processing the icon as we do with the 'construction' way.
In the other hand, the menu should not be using the FromImage way anymore. We decided to include the Icon package by default in the template sites but I seem to have forgotten the Wasm one. Will correct that for next release.

I suspect the issue is related to loading the img element from an SVG file instead of rendering the svg element.

Hi Gary,
IconColor will indeed not work when loading an SVG file. That is sort of 'by design' as we can't use the same way of processing the icon as we do with the 'construction' way.
In the other hand, the menu should not be using the FromImage way anymore. We decided to include the Icon package by default in the template sites but I seem to have forgotten the Wasm one. Will correct that for next release.

Thanks for the quick response.  So, I suspect we will be getting updated templates too 😁

@vnbaaij
I like the idea of being able to load the icon from an svg file. It would provide a way for users to provide their own custom icons but still leverage the functionality built into FluentIcon.
I'm thinking of extending FluentIcon by adding a FromUrl method that would render the svg element. Would you be willing to consider a PR, assuming I can get it all to work?

Yes, of course! Just keep in mind that we can't 'interfere' with the rendering easily so things like color need to be specified in the source (url or image).

Closing this as it works like this by design. Looking forward to the PR

Comment made by @dvoituron for #1328 could be helpful for use in the PR.
https://github.com/microsoft/fluentui-blazor/issues/1328#issuecomment-1892245014

Gary, can you elaborate. I don't understand what you mean with tyour last comment.

Gary, can you elaborate. I don't understand what you mean with tyour last comment.

I've been following the issues and saw a suggested solution for another problem that Denis suggested. I had not realized that the svg content could be specified in the base Icon constructor. It'sa much cleaner approach than what I was playing with. I was originally playing with a writing a new render fragment with the svg path.
Denis's approach would be more consistent with the existing implementation. So, I abandoned my work and intended to rewrite it. But, I got busy and dropped a note here as a reminder.


[Misc] Remove deprecated names

This PR removes the deprecated identifiers vllm.inputs.PromptInput, vllm.inputs.LLMInputs, vllm.inputs.EncoderDecoderLLMInputs, and vllm.multimodal.MultiModalInputs, all of which have been renamed.
It also introduces the deprecated decorator to other deprecated functions so that type checkers can emit warnings for them.

@njhill can you verify whether it's safe to remove these deprecated names? Thanks!


az deployment sub create returns unstructured error output message

This is autogenerated. Please review and update as needed.
Describe the bug
The error output that the az tool is outputting is not structured and hard to read, see below:
➜  az deployment sub create -f main.bicep -l southcentralus
{"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"Conflict","message":"{\r\n  \"status\": \"Failed\",\r\n  \"error\": {\r\n    \"code\": \"ResourceDeploymentFailure\",\r\n    \"message\": \"The resource operation completed with terminal provisioning state 'Failed'.\",\r\n    \"details\": [\r\n      {\r\n        \"code\": \"DeploymentFailed\",\r\n        \"message\": \"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.\",\r\n        \"details\": [\r\n          {\r\n            \"code\": \"Conflict\",\r\n            \"message\": \"{\\r\\n  \\\"error\\\": {\\r\\n    \\\"code\\\": \\\"VaultAlreadyExists\\\",\\r\\n    \\\"message\\\": \\\"The vault name 'fooBar' is already in use. Vault names are globaly unique so it is possible that the name is already taken. If you are sure that the vault name was not taken then it is possible that a vault with the same name was recently deleted but not purged after being placed in a recoverable state. If the vault is in a recoverable state then the vault will need to be purged before reusing the name. For more information on soft delete and purging a vault follow this link https://go.microsoft.com/fwlink/?linkid=2147740.\\\"\\r\\n  }\\r\\n}\"\r\n          }\r\n        ]\r\n      }\r\n    ]\r\n  }\r\n}"}]}}

Command Name
az deployment sub create
Errors:
The error message is hard to read and is shown to user in an unstructured way, please offer a better experience so that it is easier to use.
To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Ensure your deployment includes an acr with a name that already exists.
az deployment sub create -f {} -l {}

Expected Behavior
A better structured error message
Environment Summary
Linux-<IP_ADDRESS>-microsoft-standard-WSL2-x86_64-with-glibc2.2.5
Python 3.8.11
Installer: HOMEBREW

azure-cli 2.27.0 *

Additional Context

ARM

@asilverman if possible, it would be helpful if you could also include the .bicep file you're using to deploy this resource.


Keep eBPF maps separately even though KubeArmor is restarted

There could be some possibilities that KubeArmor is restarted due to unexpected reasons.
In this case, KubeArmor will lose the container-awareness stored in eBPF maps
and it cannot map the system events with the corresponding containers.
To prevent such a problem, KubeArmor needs to maintain eBPF maps separately (e.g., /sys/fs/bpf/...).

Hi @nam-jaehyun. We would need to modify this maps like[1]
https://github.com/accuknox/KubeArmor/blob/be1a0e39f7931ef6fe74f24b7f7ef35013f83ee8/KubeArmor/BPF/system_monitor.c#L84
to a pinned one?
BPF_TABLE_PINNED("hash", u32, u32, pid_ns_map, 1024, "/sys/fs/bpf/pid_ns_map");

@oneiro-naut Yes, something like that. However, let's think about this later.
Once the previous tasks are done, we can think about this and some related tasks as next steps.

Sure @nam-jaehyun. I understand.

KubeArmor previously needed to catch the init process of a container to get the container information.
Since KubeArmor doesn't need the init process of a container to get the information, we don't need to address this issue.


Add Support for Adafruit ESP32-S3 and ESP32-S2 Feather Boards

Is your feature request related to a problem? Please describe.
This is a request to add support for the very popular family of Adafruit ESP32-S3 Feather and ESP32-S2 Feather boards.
As we already have support for the Xtensa ESP32-S3 and ESP32-S2 SoCs, I'm hoping it would be relatively less effort to add support for the Adafruit ESP32-S3 & ESP32-S2 Feather boards.
Describe the solution you'd like
I'd like to see a common board definition to support these Adafruit ESP32-S3 & ESP32-S2 Feather boards. Folks can then add their own overlays to support the board variants that come with on-board TFT, fuel gauge, sensors, or Flash/PSRAM.
Describe alternatives you've considered
Currently there isn't any support for the Adafruit ESP32-S3 & ESP32-S2 Feather boards.
Additional context
Here is a list of the current Adafruit ESP3-S3 & ESP32-S2 Feather boards that this request will be able to support.

Adafruit ESP32-S3 Feather

8MB Flash / No PSRAM, Fuel Gauge MAX17048,
https://www.adafruit.com/product/5323
4MB Flash / 2MB PSRAM, MAX17048
https://www.adafruit.com/product/5477
4MB Flash / 2MB PSRAM, TFT ST7789 240x135, MAX17048
https://www.adafruit.com/product/5483
4MB Flash / 2MB PSRAM, MAX17048, Reverse TFT ST7789 240x135 + buttons
https://www.adafruit.com/product/5691

Adafruit ESP32-S2 Feather

8MB Flash / 2MB PSRAM
, https://www.adafruit.com/product/5300
4MB Flash / 2MB PSRAM, MAX17048, https://www.adafruit.com/product/5000
4MB Flash / 2MM PSRAM, MAX17048, TFT ST7789 240x135, https://www.adafruit.com/product/5300
4MB Flash / 2MB PSRAM, MAX17048, Reverse TFT ST7789 240x135 + buttons
https://www.adafruit.com/product/5345
4MB Flash / 2MB PSRAM, MAX17048, BME280 sensor, https://www.adafruit.com/product/5303
16MB Flash / 8MB PSRAM
, https://www.adafruit.com/product/4769

Hello,
I’ve been looking to see if I can leverage board xiao_esp32s3 or esp32s3_devkitm, as the Adafruit esp32s3 Feather also uses ESP32-S3-Mini-1 SoC.
If so, I expect the changes to add support for the Adafruit esp32s3 boards may be relatively small.
I’ll be available for any testing if needed.

Just ran a few quick tests. It looks like I’ll be able use board xiao_esp32s3 for some initial tests with the Adafruit ESP32S3 Feather boards.
I expected esp32s3_devkitm boards to work with the Adafruit esp32s3 boards as both are ESP32-S3-Mini-1 but no. Perhaps some mismatch flash partitions.
Anyway, for now I’ll override GPIOs and I2C in an overlay to conduct some tests using xiao_esp32s3 and provide some updates.

You should be able to get that working adding overlays and necessary configs. You are welcome to submit a PR to bring support to this boards.

Yes - xiao_esp32s3 board works!
Build using  esp32s3_ devkitm did’t work though it is ESP32-S3-Mini-1.
@sylvioalves - Any reason why esp32s3_ devkitm didn’t work? The esp32s3 TFT Feather is 4MB Flash and 2MB PSRAM.

I've setup a new board Adafruit_esp32s3_tft_feather locally.
Added  and tested:

onboard GPIOs - builtin led, user button
I2C with SSD1306 and a sensor
SPI with ST7789 135x240 (same as the onboard display)
feather_header connector
on-board MAX17048

Items remaining to configure & test

regulator  control via GPIO to control power to the I2C STEMMA connector and onboard ST7789 display via GPIO 21
I2C device connected to STEMMA connector
On-board ST7789 135x240 display
Neopixel (Zephyr GPIO "bit-banging" is only supported for couple of boards, not sure what options exist)

When using the regulator devicetree binding control via GPIO 21, I've verified that the regulator comes on at power-on I2C STEMMA connector, seeing 3.26V. I2C is in a READY state but the SSD1306 is DISABLED.
Below, you can see that I2C is  READY and has sent commands to SSD1306 but its initialization failed.
Under Arduino, init_variant() call sets GPIO 21 high to enable power to I2C STEMMA and onboard TFT. The regulator devicetree binding does the same in Zephyr.

Does anyone have any suggestion what may be going on?
A few other things to try

use gpio-hog but I haven't found any sample code and also don't know if it'll work with ESP32-S3 if there isn't a Espressif compatible that supports gpio-hog.

use a pre-kernel SYS_INIT() call.

Does anyone have any suggestions as how best to initialize the GPIO for the TFT/I2C STEMMA connector power?
Thanks.
00:00:00.228,000] <err> i2c_esp32: I2C transfer error: -14
[00:00:00.228,000] <err> ssd1306: Failed to initialize device!
*** Booting Zephyr OS build zephyr-v3.5.0-4872-gcf14d4f1fd6d ***
[00:00:00.228,000] <inf> main: main_thread
Display device not ready
[00:00:00.228,000] <dbg> cfb: cfb_framebuffer_init: number of fonts 2
[00:00:00.317,000] <inf> display: Index[0] font dimensions  5x8
[00:00:00.317,000] <inf> display: Index[1] font dimensions  8x8
[00:00:00.317,000] <inf> display: Selected font: index[3]
[00:00:00.317,000] <inf> display: x_res 128, y_res 64, ppt 8, rows 8, cols 128
[00:00:00.317,000] <inf> display: Zephyr v3.5.99

[00:00:00.317,000] <inf> display: xiao_esp32s3
uart:~$ device list
devices:
- rtc@60021000 (READY)
- gpio@60004800 (READY)
- gpio@60004000 (READY)
- trng@6003507c (READY)
- uart@60000000 (READY)
- uart@60038000 (READY)
- i2c@60013000 (READY)
- reg-tft-power (READY)
- ssd1306@3c (DISABLED)
uart:~$

closed


Fixes #1427: update codecov/codecov-action v4 API

Closes #1427

Looks like my changes still are not fixing the issue.
I've added my info to this https://github.com/codecov/codecov-action/issues/1248#issuecomment-1969338042
If there's no movement on that issue I'll create a new one.
For now I propose we fall back to v3.


DOC: linking to custom BLAS/LAPACK locations is not clear

Issue with current documentation:
I have tried to figure out how the meson (new) build system understands the linking stages for BLAS and LAPACK. But there seems to some missing points. Perhaps it is my ignorance in how meson understands flags etc.
So I want to build my own scipy and NOT use pip or conda. I also want to forcefully go away from using distutils (to be prepared for 3.12).
**scipy version: 1.10.1 **
I have tried to understand this page:
https://docs.scipy.org/doc/scipy/dev/contributor/building_faq.html#how-do-i-use-a-custom-blas-distribution-on-linux
However, when trying to build with meson:
 meson setup build-dir -Dblas=blis
The Meson build system
Version: 1.0.1
Source dir: /home/software/bash-build/.compile/py-3.11/scipy-1.10.1
Build dir: /home/software/bash-build/.compile/py-3.11/scipy-1.10.1/build-dir
Build type: native build
Project name: SciPy
Project version: 1.10.1
C compiler for the host machine: gcc (gcc 12.2.0 "gcc (GCC) 12.2.0")
C linker for the host machine: gcc ld.bfd 2.40
C++ compiler for the host machine: g++ (gcc 12.2.0 "g++ (GCC) 12.2.0")
C++ linker for the host machine: g++ ld.bfd 2.40
Cython compiler for the host machine: cython (cython 0.29.33)
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -Wno-unused-but-set-variable: YES
Compiler for C supports arguments -Wno-unused-function: YES
Compiler for C supports arguments -Wno-conversion: YES
Compiler for C supports arguments -Wno-misleading-indentation: YES
Compiler for C supports arguments -Wno-incompatible-pointer-types: YES
Library m found: YES
Fortran compiler for the host machine: gfortran (gcc 12.2.0 "GNU Fortran (GCC) 12.2.0")
Fortran linker for the host machine: gfortran ld.bfd 2.40
Compiler for Fortran supports arguments -Wno-conversion: YES
Checking if "-Wl,--version-script" : links: YES
Program cython found: YES (/opt/gnu/12.2.0/python/packages/3.11.2/cython/0.29.33/bin/cython)
Program python3 found: YES (/opt/gnu/12.2.0/python/3.11.2/bin/python3)
Found pkg-config: /opt/generic/build-tools/1.0/bin/pkg-config (1.9.4)
Program pythran found: YES (/opt/gnu/12.2.0/python/packages/3.11.2/pythran/0.12.1/bin/pythran)
Run-time dependency threads found: YES
Library npymath found: YES
Library npyrandom found: YES
Run-time dependency blis found: YES 0.9.0
Found CMake: /opt/generic/build-tools/1.0/bin/cmake (3.25.3)
WARNING: CMake Toolchain: Failed to determine CMake compilers state
Run-time dependency openblas found: NO (tried pkgconfig and cmake)
Run-time dependency openblas found: NO (tried pkgconfig and cmake)

scipy/meson.build:135:0: ERROR: Dependency "OpenBLAS" not found, tried pkgconfig and cmake

basically regardless of the blas=<> argument. Tried, default, none and blis (my actual library).
The above is actually a bit misleading since users may think that this is the blas option which is not discovered, it is not, it is the lapack option.
I have lapack installed in a directory with no pc or cmake files. Is it possible to link that library to meson?
meson setup build-d -Dblas=blis -Dlapack=lapack
...
WARNING: CMake Toolchain: Failed to determine CMake compilers state
WARNING: CMake Toolchain: Failed to determine CMake compilers state
Run-time dependency lapack found: NO (tried pkgconfig and cmake)

scipy/meson.build:135:0: ERROR: Dependency "lapack" not found, tried pkgconfig and cmake

There is little documentation on how to bypass the dependency checking, and even with env-vars (not going to be supported: https://github.com/mesonbuild/meson/issues/9).
The whole problem of fixing names for dependencies makes it difficult to customize the build. I.e. if -Dblas=<argument> where <argument> has the restriction that it must be a name that used via pkg-config, i.e. pkg-conf --libs <argument>. So it seems to me that I have to provide a manual *.pc file for customizing a library usage? Really? :disappointed:
I tried:

put everything in FC flags etc., but this also fails since the dependency is forcefully added regardless of whether linking can occur
put complete information in the -Dlapack='-L/path/to/lapack/... -llapack option, to no avail

python setup.py works but
I can get scipy to be installed using the regular setup.py installation, but that will use my numpy site.cfg which I am not keen on.
Idea or request for content:
It would be really valuable if the documentation showed how to link to a BLAS library located in a custom folder, without a pc file. That would show end-users how to play around with settings, and/or test various BLAS implementations (lets for now forget about flexiblas ;) ).
Additional context (e.g. screenshots, GIFs)
No response

You can start fiddling with meson.build file for changing the blas and lapack dependencies and meson-options.txt to modify the openblas parts.
But since you are going against the grain, please expect a lot of strange issues. These tools are very new and we don't have flexibility to accommodate every custom workflow.

So the suggestion would be to add custom pkg-config files ad-hoc and use those?

Then the thing I would propose is to document this, users in the scientific community looks at numpy/scipy for best practices, so documenting this would be great IMHO!
I. E

no packages can be linked without pkg-config files or cmake inclusions
environment variables will never be able to tweak compilation
create temporary pkg-config files for tweaking build options.

Don't get me wrong I struggled to build scipy on windows for months. So I hope you don't think I'm being dismissive. I really mean it when I say these are brand new tools we are dealing with and meson team was exceptionally receptive. This doesn't mean that all is unicorns and rainbows.
However we have to start with a minimum number of assumptions to make sure certain things are, at least, in place. Then we would consoder the edge cases slowly.
Like I mentioned there are certain options in meson to achieve custom linking and dependencies but our tools are not ready yet. So it is instrumental that you fiddle with it too. Or someone who knows how to do it tells how it is. But we are not ready to document what's allowed and what's not.

I have tried to understand this page: https://docs.scipy.org/doc/scipy/dev/contributor/building_faq.html#how-do-i-use-a-custom-blas-distribution-on-linux

Could you please have a look at https://docs.scipy.org/doc/scipy/dev/contributor/meson_advanced.html#select-a-different-blas-or-lapack-library instead? That should be the right page, and I think it should answer your questions. If not, please point out the gaps and I'll try to address them.
Unfortunately we have two sets of build docs right now - we'll get rid of the setup.py related ones very soon; hopefully it'll be easier to find then.

Related question to maintainers: should we clean the docs now? The "advanced Meson" page is quite difficult to find, and the setup.py content basically is no longer relevant even though it's still possible to trigger that build (but not via pip for example).

The roadmap is to be using meson as the main build system, with setup.py being retired. I'd like all relevant meson related info coming to the front and setup.py documentation moving backwards.
It looks like https://docs.scipy.org/doc/scipy/dev/contributor/building_faq.html could be culled by quite a lot.

I am also guilty of occasionally finding and losing this page. Apologies for not remembering earlier in this discussion.

I am +1 for retiring the old doc. Since we are not going to really add new information there, I think it's occasionally fine to use an older version for people in need of these.

I'll have a go at cleaning up the docs today. There's also still a bunch of places with very detailed explanations on distutils usage; I'll replace those with "look at examples in current meson.build files".

Fixing this up completely is a little messy. I'm going to simplify the "build from source" docs a lot. We've got the same instructions (or different variants) in about ten different places. The "system-level dependencies" part is quite nice, and then it goes downhill quickly. I'm going to get rid of the "this is Meson, and here is how it compares to the old thing" parts too. We can simplify it down to:

System dependencies and how to install them (already in good shape)
Install from source for production with pip or local development with dev.py (already in good shape too)
Relevant build customizations users may need:

BLAS/LAPACK selection
Compiler selection
Build types (debug/release builds, optimization levels, etc.)
Controlling the Fortran ABI used
Cross compilation

Info for packagers/redistributors
Background content on how Meson works and FAQ entries (trim that down, but some stuff is relevant)

There is very little of use left in the macOS/Windows/Ubuntu/Conda parts, once the "system dependencies" part is done, everything else is effectively the same.

I'd like to also use the self-documentation features of the build system as much as possible. We have:

python dev.py --help and python dev.py <subcommand> --help
meson configure to show all Meson builtin and SciPy-specific build options
meson introspect, build.ninja and good logging to figure out what's actually happening

The build docs are also very hard to discover. It's some of the most commonly needed info, but:

Not linked from the front page of the docs](http://scipy.github.io/devdocs/) at all (only a link out from the docs to the website, and then a hard to spot link back into contributor/building.rst
Not linked from the Developer guide front page either
Only linked from the middle of the quickstart guide page, and one of very many links on the Contributor guide

It needs to start from a single, easy to discover place. It could be a separate section under Developer guide or even one level up and put it in the top navbar, or even get rid of Getting started (which is basically empty and not useful) and put it as one of the four "panels" on the front page of the docs.
The use of tabs in some of the newer pages is quite nice - we should have more of that. Any info like Windows/macOS/Linux-specific details and pip/build/dev.py/etc. usage is short enough that it can be in a tab, rather than spread over different pages.
I'd like to review / agree on the outline and where it goes first, before major surgery. It won't take much time to clean it all up, but I want to do it in one go because shuffling around existing info and making sure the flow is still nice is half the work here.

Don't get me wrong I struggled to build scipy on windows for months and I'm supposed to be a maintainer. So I hope you don't think I'm being dismissive. I really mean it when I say these are brand new tools we are dealing with and meson team was exceptionally receptive. This doesn't mean that all is unicorns and rainbows.

Thanks for this sentiment. I am continuously struggling to find a path in the package nightmare of python. There are too many tools and too few standards... :(
I know this isn't easy and I can see this frustration across the Python community. I truly hope that the coming years will try to manage a more standardized approach, pep 517 + friends.
And then meson + scikit-build and others are another layer of complexity. I am not blaming anybody, but I can just see that the obfuscation and very diverse avocations of different build-tools, ends up being a problem for the small dev's who cannot figure out what is the endorsed approach.

However we have to start with a minimum number of assumptions to make sure certain things are, at least, in place. Then we would consoder the edge cases slowly.

Agreed!

Like I mentioned there are certain options in meson to achieve custom linking and dependencies but our tools are not ready yet. So it is instrumental that you fiddle with it too. Or someone who knows how to do it tells how it is. But we are not ready to document what's allowed and what's not.

Ok. I will do then. :)
Let me note one thing about meson that is not clear for builders. Environment variables. One expects that env-vars are obeyed, CC, CFLAGS. Now meson is very particular here to never allowing env-vars. I understand their concerns and decisions, but perhaps this needs a clarification in the documentation (here as well).
References: https://github.com/mesonbuild/meson/issues/9 and https://github.com/mesonbuild/meson/pull/2796
Yet, some of the flags are still read: https://github.com/mesonbuild/meson/issues/4664
Finding this in the documentation is not easy... :(

I have tried to understand this page: https://docs.scipy.org/doc/scipy/dev/contributor/building_faq.html#how-do-i-use-a-custom-blas-distribution-on-linux

Could you please have a look at https://docs.scipy.org/doc/scipy/dev/contributor/meson_advanced.html#select-a-different-blas-or-lapack-library instead? That should be the right page, and I think it should answer your questions. If not, please point out the gaps and I'll try to address them.

Yes, this is much better, thanks!
Could I suggest that the Note in https://docs.scipy.org/doc/scipy/dev/contributor/meson_advanced.html#select-a-different-blas-or-lapack-library is complimented by the filename of the pkg-config file and the resulting meson commandline for building it. It is relatively clear, but.. :)
Another thing, on the documentation pages it is not easy to go back and forth in the pages. For instance, if I just follow your link to the advanced meson page, I cannot easily find this https://docs.scipy.org/doc/scipy/dev/contributor/meson.html, no links to that page? And vice-versa. No link from the simple -> advanced.
It seems to me that the section structure is missing, somehow? (this is a generic problem I think)

Unfortunately we have two sets of build docs right now - we'll get rid of the setup.py related ones very soon; hopefully it'll be easier to find then.

That would be great! The older versions documentations still works, so one could link to prior versions documentations in a simple statement where it is then much clearer that it is deprecated. Basically what @tupul said :)

Fixing this up completely is a little messy. I'm going to simplify the "build from source" docs a lot. We've got the same instructions (or different variants) in about ten different places. The "system-level dependencies" part is quite nice, and then it goes downhill quickly. I'm going to get rid of the "this is Meson, and here is how it compares to the old thing" parts too. We can simplify it down to:
1. System dependencies and how to install them (already in good shape)

2. Install from source for production with `pip` or local development with `dev.py` (already in good shape too)

3. Relevant build customizations users may need:

* BLAS/LAPACK selection

* Compiler selection

* Build types (debug/release builds, optimization levels, etc.)

* Controlling the Fortran ABI used

* Cross compilation

4. Info for packagers/redistributors

5. Background content on how Meson works and FAQ entries (trim that down, but some stuff is relevant)

There is very little of use left in the macOS/Windows/Ubuntu/Conda parts, once the "system dependencies" part is done, everything else is effectively the same.

It would also be nice to discuss how to change CFLAGS etc. It is not clear to me whether the CFLAGS from meson build-setup or from the dev.py file are used. So if I do:
meson -Dc_args='-g' ...
CFLAGS="-O3" python dev.py ...

what would happen where?
Thanks for all of the discussion!

I know this isn't easy and I can see this frustration across the Python community. I truly hope that the coming years will try to manage a more standardized approach, pep 517 + friends.
And then meson + scikit-build and others are another layer of complexity. I am not blaming anybody, but I can just see that the obfuscation and very diverse avocations of different build-tools, ends up being a problem for the small dev's who cannot figure out what is the endorsed approach.

I totally see and feel the pain here, but if it helps: I'm quite confident we're near the end of that very long tunnel. Most projects and all build tools (except Poetry, which will follow soon) have adopted PEP 517. For compiled code, everyone is dropping distutils/setuptools at a good pace, and we will have only two serious general-purpose build systems left: Meson/meson-python and CMake/scikit-build-core. Those are not that dissimilar and are even collaborating on design of UX and features.

Could I suggest that the Note in https://docs.scipy.org/doc/scipy/dev/contributor/meson_advanced.html#select-a-different-blas-or-lapack-library is complimented by the filename of the pkg-config file and the resulting meson commandline for building it. It is relatively clear, but.. :)

Thanks for the suggestion! I'll fix that. Also, I haven't forgotten that you're the author of part of the more advanced BLAS/LAPACK selection knobs in numpy.distutils (thanks again!). If I may ping you for a review of the docs/behavior of the like-for-like replacements in Meson once I'm done with those, it'd be great to get your input on that.

Another thing, on the documentation pages it is not easy to go back and forth in the pages

Agreed, I want to fix this in one go with my proposed restructure above. The sidebar content will also be much more organized then.

It would also be nice to discuss how to change CFLAGS etc.

Thanks, I'll add that. It should be included in Build types (debug/release builds, optimization levels, etc.)
For the basics:

Meson understands all the most standard env vars, like CC, FC, CFLAGS, LDFLAGS
It uses CLI flags for everything else, and those can be passed through config_settings when using pip/build
When using dev.py, that level of customization is available only for the most commonly used things, e.g. python dev.py build --werror --debug does what you expect there (selects a debug build and passes -Werror in a compiler-independent way)

If you want to get fancy beyond what dev.py build --help shows, you can separately run meson setup build <options-you-want> followed by dev.py build. I'll admit that this is okay but not ideal, and it could benefit from a way to directly pass any flag through to meson setup (e.g., add dev.py build --setup-arg <your-desired-arg-here>).

meson -Dc_args='-g' ...
CFLAGS="-O3" python dev.py

I hope the above answer helps. I'll note that you should not pass -g or -O3 like that with Meson, it has better CLI flags for this. You want to do it in one line ideally:

what works right now is: CFLAGS="-O3" python dev.py build --debug
what it should become is one of:

python dev.py build --debug --optimization 3 (for an option like -O3 that is common enough to have its own flag)
python dev.py build --debug --setup-arg b_lto=true (e.g., for enabling link-time-optimization, or any other Meson build option)

I totally see and feel the pain here, but if it helps: I'm quite confident we're near the end of that very long tunnel. Most projects and all build tools (except Poetry, which will follow soon) have adopted PEP 517. For compiled code, everyone is dropping distutils/setuptools at a good pace, and we will have only two serious general-purpose build systems left: Meson/meson-python and CMake/scikit-build-core. Those are not that dissimilar and are even collaborating on design of UX and features.

Ok, I'll try and adapt to scikit-build-core then. More work :)

Could I suggest that the Note in https://docs.scipy.org/doc/scipy/dev/contributor/meson_advanced.html#select-a-different-blas-or-lapack-library is complimented by the filename of the pkg-config file and the resulting meson commandline for building it. It is relatively clear, but.. :)

Thanks for the suggestion! I'll fix that. Also, I haven't forgotten that you're the author of part of the more advanced BLAS/LAPACK selection knobs in numpy.distutils (thanks again!). If I may ping you for a review of the docs/behavior of the like-for-like replacements in Meson once I'm done with those, it'd be great to get your input on that.

Happy to help. :)
And yes, please do ping me!

Another thing, on the documentation pages it is not easy to go back and forth in the pages

Agreed, I want to fix this in one go with my proposed restructure above. The sidebar content will also be much more organized then.

Great!

It would also be nice to discuss how to change CFLAGS etc.

Thanks, I'll add that. It should be included in Build types (debug/release builds, optimization levels, etc.)
For the basics:
* Meson understands all the most standard env vars, like `CC`, `FC`, `CFLAGS`, `LDFLAGS`

* It uses CLI flags for everything else, and those can be passed through `config_settings` when using `pip`/`build`

* When using `dev.py`, that level of customization is available only for the most commonly used things, e.g. `python dev.py build --werror --debug` does what you expect there (selects a debug build and passes `-Werror` in a compiler-independent way)

  * If you want to get fancy beyond what `dev.py build --help` shows, you can separately run `meson setup build <options-you-want>` followed by `dev.py build`. I'll admit that this is okay but not ideal, and it could benefit from a way to directly pass any flag through to `meson setup` (e.g., add `dev.py build --setup-arg <your-desired-arg-here>`).

Ok.

meson -Dc_args='-g' ...
CFLAGS="-O3" python dev.py

I hope the above answer helps. I'll note that you should not pass -g or -O3 like that with Meson, it has better CLI flags for this. You want to do it in one line ideally:
* what works right now is: `CFLAGS="-O3" python dev.py build --debug`

* what it should become is one of:

  * `python dev.py build --debug --optimization 3` (for an option like `-O3` that is common enough to have its own flag)
  * `python dev.py build --debug --setup-arg b_lto=true` (e.g., for enabling link-time-optimization, or any other [Meson build option](https://mesonbuild.com/Builtin-options.html#base-options))

Yes, this would be great to have! :)
It was just a contrived example :)

I'd like to also use the self-documentation features of the build system as much as possible. We have:

python dev.py --help and python dev.py <subcommand> --help
meson configure to show all Meson builtin and SciPy-specific build options
meson introspect, build.ninja and good logging to figure out what's actually happening

You mean that we could have a page which is just the output of all help commands? Why not, would be similar to how backend APIs are documented. I just did a superficial check and it appears there are tools for that like https://github.com/RiveryIo/md-click

The build docs are also very hard to discover. It's some of the most commonly needed info, but:

Not linked from the front page of the docs](http://scipy.github.io/devdocs) at all (only a link out from the docs to the website, and then a hard to spot link back into contributor/building.rst
Not linked from the Developer guide front page either
Only linked from the middle of the quickstart guide page, and one of very many links on the Contributor guide

Happy to discuss the structure 😃 cc @melissawm
We tried here to make a compelling user story. That's why for now the build instructions are under the Editing SciPy section.

It needs to start from a single, easy to discover place. It could be a separate section under Developer guide or even one level up and put it in the top navbar, or even get rid of Getting started (which is basically empty and not useful) and put it as one of the four "panels" on the front page of the docs.

I agree that we could rework the Getting Started page. But I would not put dev instructions. This page is targeting users. I would not say compiling is intended as regular users.
But maybe the Development tab should be renamed to not only say contributors but also advanced users. Or maybe we even need an advanced user tab, or have a section in the tutorials and rename the section?? Lot of options to discuss.

The use of tabs in some of the newer pages is quite nice - we should have more of that. Any info like Windows/macOS/Linux-specific details and pip/build/dev.py/etc. usage is short enough that it can be in a tab, rather than spread over different pages.

Agreed 👍 We migrated a few things already but there is still work to do.

I'd like to review / agree on the outline and where it goes first, before major surgery. It won't take much time to clean it all up, but I want to do it in one go because shuffling around existing info and making sure the flow is still nice is half the work here.

We can make a special meeting or even discuss it during our next community meeting. What do you think?

You mean that we could have a page which is just the output of all help commands?

No, quite the opposite. This always goes out of date, as the current state of our docs shows. I want to explain the principle only, and then say something like "for any details on build options and how to use them, see dev.py build --help".

or even discuss it during our next community meeting.

next community meeting sounds good to me

We had a good discussion at the community meeting with both some new contributors and some old hands. The most popular idea was to replace the "Getting Started" tile on the front page of the docs (http://scipy.github.io/devdocs/), which is basically empty, with a dedicated "Building from source" section. We'd then still have four tiles:
User guide                API reference

Building from source      Developer guide

I probably won't get started on that this week, but it'd be good to hear any concerns with that plan.


Proper fragment usage, unified usage of PlayableQRCode and QRLocation

This supercedes #239, I guess I should've structured this better to not depend like that, or roll them all up into one.
This pull request tries to do 2 things:

a major refactor to clean things up around the scanning or QR codes. Previously, data was haphazardly passed without bundling and without organization, and this PR attempts to fix some/most of that clutter and disorganization.
image uploading

Refactor
Changes to PlayableQRCode

Since this class always will be associated with a player, I went ahead and added this as part of the class. In this case, we needed the player anyway, so this reduced what we have to pass to the FragmentAddQRCode when adding a QR Code.
This class was made serializable, which means we can put it into a bundle so if the fragment gets killed (for example, this actually happened to me while uploading the image. Since we start a new activity, android is free to kill off that fragment, and when we get back from the camera app, we're SOL if we don't save anything to the bundle.

QRLocation was also made serializable to accommodate this as well

This class was also made "firestore serializable" which means we can directly insert the object into the database, and the necessary serialization will take place.
PlayableQRCode code = doc.toObject(PlayableQRCode.class)

The only caveat that I know of right now is that playerId does not get set automatically - I'm still trying to figure out if this can even be done at all. Manually, calling PlayableQRCode.setPlayerId(doc.getReference().getParent().getParent().getId()) should work ™

Changed the method names AddQRToDatabase → addToDb to be more consistent w/ naming
QRLocation handles lat/long universally now, and removes the need for the programmer to ever think of geohashes again, except eg when they need to query for them specifically

Other changes

Anywhere a lambda function could be used, I did, because I don't see a point in the verbosity of classes (see here for a dramatic example - from 16 lines to 5
I seem to recall code @kezzayuno wrote with a snapshot listener because I was going to improve it, but I can't seem to find any mention of it anymore 😬. At this point I'm too lazy to go find a reference to it, maybe tomorrow
renamed AugmentedCamera → QRCodeProcessor. The first name makes 0 sense IMO

Image Uploading
Images are uploaded to Firebase Storage, the bucket currently allows every path unlimited r/w access. Maybe one day I'll fix this, lol. There's not much to say about this, the database receives an image URL. In the future, I need to implement deleting images when the QR code is deleted, this would be a job for cloud functions. You can't delete a image based on URL, but you need a reference, which is a separate type of path. Lucky for us, I just store the images in the most logical way possible (/qrCodes/userId/qrCodeId) so we can come up with the reference based on the user's ID and QR ID. Images are compressed to JPEGs with quality set to 85, which I think is a semi decent balance of quality/size.
Unfinished

The layout contains a progress bar (think loading spinner icon thingy, this is just what android calls them for some reason) which currently shows up in a random spot. I'd like to have some sort of overlay instead, but I haven't gotten around to this.
FragmentLibraryRemoveQR.java and QRLibrary are kinda in a half baked err half mise en place - I unfortunately branched from a branch which had these...sorry. I don't know if/how hard this is to undo so this is the small price we pay for a refactor - some random code into main
FragmentProfile.java

also I made this a draft because I really want critical comments (and not merged as soon as it builds 😉), i know a lot of this is long changes but if you have any questions about my approach please lmk, I wrote this at like 5am so we would both stand to benefit from another pair of eyes on this

For the "FragmentLibraryRemoveQR.java and QRLibrary are kinda in a half baked err half mise en place - I unfortunately branched from a branch which had these...sorry. I don't know if/how hard this is to undo so this is the small price we pay for a refactor - some random code into main". Does this break the application at the moment?

It should be too hard to fix QRLibrary and FragmentLibraryRemoveQR. From what I understand, lamda function is replacing the new "classname" for .set"classname", correct me if I'm wrong. Everything looks good, Great work

@kezzayuno

when do you recall me talking about it (in what context)?

I just saw the code and if I remember correctly the blame (git blame, I'm not blaming problems lol) was on you. Didn't want to reduce functionality somehow with a bad merge.

Does this break the application at the moment?

No


Fails to resolve dependencies with Vite

Describe the bug

When trying to resolve a token with one or more dependencies, the error TypeInfo not known for "Bar" is thrown.
To Reproduce
Reproduced on StackBlitz
Sample code:
import '@abraham/reflection';

import { container, singleton } from 'tsyringe';

@singleton()
export class Foo {
  constructor() {}
}

@singleton()
export class Bar {
  constructor(public foo: Foo) {}
}

console.log(container.resolve(Foo)); // Works
console.log(container.resolve(Bar)); // Throws Uncaught Error: TypeInfo not known for "Bar"

Tested with:
{
  "scripts": {
    "start": "vite",
    "build": "tsc && vite build"
  }
}

Expected behavior

The token Bar should have been successfully resolved with its Foo dependency set.
Versions
{
  "devDependencies": {
    "typescript": "^4.9.5",
    "vite": "^5.2.9"
  },
  "dependencies": {
    "@abraham/reflection": "^0.12.0",
    "tsyringe": "^4.8.0"
  }
}

References

Why can't reflect-metadata be used in vite
Make tsyringe decorators works with Vite

This can be fixed using (@rollup/plugin-typescript)[https://www.npmjs.com/package/@rollup/plugin-typescript]:

Install @rollup/plugin-typescript
Create vite.config.mjs:import typescript from '@rollup/plugin-typescript';
import { defineConfig } from 'vite';

export default defineConfig({
  plugins: [typescript()]
})

Set "module": "ESNext" in tsconfig.json


Support animations of visConfig, filters, and mapState

Synchronizes kepler's mapState with hubble's whenever it is updated so that zoom-based scaling correctly applies to layers.

Supports keyframe definitions on scene now using special object keys.
Supported Keyframes (by key name):

camera: mapState animation
hubble_timeFilter applies time filter keyframe to first time filter listed in kepler. (only one filter is supported right now)
any visConfig of a layer can by animated by using the layer's label as a key.

This interface is very experimental, and will change.

Pull Request Test Coverage Report for Build 836286555

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 750187791:
0.0%

Covered Lines:
2

Relevant Lines:
2

💛  - Coveralls


173 video with placeholder image

Fix #173
Test URLs:

Before: https://main--hlx-test--urfuwo.hlx.live/draft/mlangford/standard-chartered-total-workforce-solution
After: https://173-video-with-placeholder-image--hlx-test--urfuwo.hlx.live/draft/mlangford/standard-chartered-total-workforce-solution

Changes scripts/script.js to allow for multiple players rather than just YouTube.  In this case, LinkedIn, but introduces a configuration feature that can be extended.

look into this one?
https://pagespeed.web.dev/analysis/https-173-video-with-placeholder-image--hlx-test--urfuwo-hlx-page-draft-mlangford-standard-chartered-total-workforce-solution/9ah6lqdqbh?utm_source=psi&utm_medium=redirect&form_factor=mobile

look into this one? https://pagespeed.web.dev/analysis/https-173-video-with-placeholder-image--hlx-test--urfuwo-hlx-page-draft-mlangford-standard-chartered-total-workforce-solution/9ah6lqdqbh?utm_source=psi&utm_medium=redirect&form_factor=mobile

Unfortunately, this uses external players which drag in a ton of external scripts.  It's one of the main reasons we don't allow these kinds of things on the .COM site (data privacy compliance is the other major one).  The LinkedIn player is particularly terrible.
On thing I note too is this test page loads two players - that's an unlikely use case.
This uses an intersection observer to only load the players when the user gets there (I'm not clear how the page speed scan handles that actually - does it execute those immediately or emulate a human scroll speed??), so at least the players aren't blocking ICP (in practical use anyway), but if using these players is a requirement, I'm not sure what else to do.   My original plan to use placeholder images so the user had to manually click/tap before player code was loaded would have been more performant I think, but that need changed.  I'd be open to suggestions to improve this, as I'm not sure what else can be done given the UX requirements.

look into this one? https://pagespeed.web.dev/analysis/https-173-video-with-placeholder-image--hlx-test--urfuwo-hlx-page-draft-mlangford-standard-chartered-total-workforce-solution/9ah6lqdqbh?utm_source=psi&utm_medium=redirect&form_factor=mobile

Unfortunately, this uses external players which drag in a ton of external scripts. It's one of the main reasons we don't allow these kinds of things on the .COM site (data privacy compliance is the other major one). The LinkedIn player is particularly terrible.
On thing I note too is this test page loads two players - that's an unlikely use case.
This uses an intersection observer to only load the players when the user gets there (I'm not clear how the page speed scan handles that actually - does it execute those immediately or emulate a human scroll speed??), so at least the players aren't blocking ICP (in practical use anyway), but if using these players is a requirement, I'm not sure what else to do. My original plan to use placeholder images so the user had to manually click/tap before player code was loaded would have been more performant I think, but that need changed. I'd be open to suggestions to improve this, as I'm not sure what else can be done given the UX requirements.

Agree - let's proceed


azcopy can be excessive, hurting performance and writing logs too large

Preflight Checklist

[X] I have installed the latest version of Storage Explorer.
[X] I have checked existing resources, including the troubleshooting guide and the release notes.
[X] I have searched for similar issues.

Storage Explorer Version
1.26.0
Regression From
No response
Architecture
i86
Storage Explorer Build Number
No response
Platform
Windows
OS Version
Windows 10; 17763
Bug Description
Logs can become very big. Unusably so.
Happens when doing operations on a deep directory with a lot of files.
azcopy logging is quite useful for failed transactions. But can it be pruned a bit?
Steps to Reproduce

Open a blob container with a lot (hundreds of thousands) of nested directories and files.
Do some operation that works on the full tree. Copy, delete, etc.
Check the logs at "C:\Users\<user>\.azcopy".
See:

Actual Experience
Logs grow large enough to possibly crash a system.
Expected Experience
No response
Additional Context
No response

BTW the setting to disable Log's does not disable all logs. In the subfolder 'plans' I still had a few GB's written in two days.

Storage Explorer doesn't have the ability to tell AzCopy to not-keep plan files around. We will talk to them about this.

The default should likely not be info.

It has been recommended to us that we stick with Info. When something bad happens/something fails/something goes wrong, it is very helpful to have the log files around to confirm what has happened. Perhaps there is more we can in the UI though to help you out. Maybe a quick way to delete the logs/plans of a finished transfer?

We discussed this today and have decided to add a setting which when enabled will have Storage Explorer auto delete AzCopy logs of successful transfers. Unsure if we can do anything about the plan files though.

The new auto delete log setting should be shipping with 1.28.0.


[Suggestion] Adding player to Nuke Event

This is a suggestion for the NukeEvent, it would be really handy if we could get the player that activates and desactivates the nuke.

Also perhaps add an output to continue or not the action

Both are done and coming in Smod 3.0.0


Group member from other country

A group administrator shall be able to add existing person from other country. Note that a group administrator cannot create a new person in another country.

Implemented in release 1.0.5.


Labels not shown in Firefox

When viewing README in FF, there are no icons at all, just a free space:

Hi @inliquid! Thanks for noticing!
I'm sorry for your bug, has it been fixed?
If not, could you please specify your Firefox Browser version?
Thanks!

hey @inliquid!
I hope, the issue has been resolved, so I'm closing it.

It works! Thank you.


[GUI] Add Electrum backend option to Installer & update Settings

Following #1222, we will need to add an Electrum option in the Installer and update the Settings page accordingly.

For the installer, we currently have this page:

We could either:

add the Electrum option to this same page (perhaps one row per option instead of columns), or
add a preceding page "Select Bitcoin backend type" with options "Bitcoin node" (which then goes to above page) & "Electrum" (a new page to enter Electrum details and check connection).

Perhaps we should opt for fewer pages/clicks, in which case (1) would be better.

I like the idea of having the 3 options in columns, each in a card with a title that needs to be clicked on to collapse and show the text and the button next.

Intuitively (but probably I'm missing something), I would expect to have a three step choice:

Do you want to use the remote backend (Liana Connect) or your own node? (this is the part of @edouardparis' PR)
If your node, do you already have one or do you want us to install a pruned one? (basically the same choice we have now changing the wording to mention that there is also Electrum in the former option)
If you have one, local bitcoind or electrum?

The choice branching would be something like:

Liana Connect [Default]
My own Node

Connect to an existing Node

Connect to my local Bitcoin Core
Connect to Electrum

Download a pruned liana-managed one

In this case, electrum would be an option in the following page in which you put your IP and so on:

The reason for that is that people could be confused by the fact of having two options to link to their own node at that stage.
What am I missing?

Thanks for the suggestions. It makes sense to consider how these options and the flow will link with the Liana Connect option.

Do you want to use the remote backend (Liana Connect) or your own node? (this is the part of @edouardparis' PR)

I tend to think of "node" as Bitcoin Core, so I think we could change this to "or your own backend (Bitcoin node or Electrum server)".

If your node, do you already have one or do you want us to install a pruned one? (basically the same choice we have now changing the wording to mention that there is also Electrum in the former option)

Changing the existing wording would be the simplest thing, but having the three cards would also be nice.

In this case, electrum would be an option in the following page in which you put your IP and so on

If we stick with the single "manage your own backend" option, then I think we could have another radio button at the top of this page to select the backend type ("Bitcoin node" or "Electrum" server) and then the contents below would change accordingly. The title of the page would be "Set up connection to the Bitcoin backend".
If we have three separate options, then we would just need to add a new page for the Electrum connection and the existing "Set up connection to Bitcoin full node" page would stay the same.

I tend to think of "node" as Bitcoin Core, so I think we could change this to "or your own backend (Bitcoin node or Electrum server)".

I think your wording is more precise. I added a proposal on this step in #970, so that we can keep the discussion about it there.

Changing the existing wording would be the simplest thing, but having the three cards would also be nice.

I tend to think that the main criteria of choice is: do you already have a node/server to connect to or do you want us to manage (and download) one for you? That's why I personally lean a little bit more towards changing the wording and adding the Electrum option in the following screen. But let's see if we can find an agreement or other arguments.

If we stick with the single "manage your own backend" option, then I think we could have another radio button at the top of this page to select the backend type ("Bitcoin node" or "Electrum" server) and then the contents below would change accordingly. The title of the page would be "Set up connection to the Bitcoin backend".

Yes, that's very similar to how I imagined it.

If we have three separate options, then we would just need to add a new page for the Electrum connection and the existing "Set up connection to Bitcoin full node" page would stay the same.

So, to recap, the options at the moment are:

Change the wording of the "Bitcoin Node management" step to include Electrum  but leaving the two choices. Edit the following step ( "Set up connection to the Bitcoin backend") to have a choice between local bitcoind and an electrum server, with its specific settings.
Adding a third card to the "Bitcoin Node management" step. Adding a new page to setup the electrum settings, similar to what we do for the local bitcoind.

In terms of effort required, do you see any major difference between the two?

In terms of effort required, do you see any major difference between the two?

Perhaps slightly simpler to have a separate page for setting up Electrum, but either way should be similar effort.

After clarifying the previous step in the relative PR, among the two options for showing Electrum I would personally go with the first:

Change the wording of the "Bitcoin Node management" step to include Electrum but leaving the two choices. Edit the following step ( "Set up connection to the Bitcoin backend") to have a choice between local bitcoind and an electrum server, with its specific settings.

I would see the wording of the first two options (what now is the "Bitcoin Node Management" step - we should consider changing this title as well imho) something like:

I already have a node
Select this option if you already have a bitcoin node running locally or remotely. Liana will connect to it.
I want Liana to automatically install a Bitcoin node on my device
Liana will install a pruned (i.e. "compressed") node on your computer. You won't need to do anything except having some disk space available (~25GB required) and waiting for the initial synchronization with the network (it can take some days according to your internet connection speed).
[the two parenthesis with the estimation space and time possibly should be shown only if the network chosen is mainnet]

The wording has to be reviewed and validated of course, but I think it makes it simpler and less redundant.
If the user selects 1, there should be two options:
a. Connect to a local node on this machine -> Bitcoin Core
b. Connect to a remote node (on another device) -> Electrum Server
as @darosior pointed out:

In the super-unlikely the user wants to connect to a locally running Electrum server (if so he must be technical) we can always have a redirection to the Electrum setup step there.

Other opinions or comments?

Regarding Electrum, the user could in principle enter any valid URL, e.g. a public instance. We could add some text to recommend only connecting to a self-hosted Electrum server for privacy reasons.

definitely needs to be self hosted. It should be very clear that it's not just a recommendation, but important


MacOS headless usage

Hi there,
First of all, thanks for making this package, it works perfectly for the protected site(s) I want to scrape!
My issue is that headless mode does not work on Mac. You already mentioned this in your README:

The headless option only works on linux, and requires Xvfb to be installed. Could theoretically work on Mac OS with xquartz but I don't have a Mac to test with, so feel free to PR.

I did install xquartz and your example only works by removing the headless option.
You mentioned you can't test it on here so I'm willing to do so but I would need some pointers on where to start if possible.
Thanks!

Hey, @Stef16Robbe nice to hear! I am not too sure myself as well. I mentioned it in the readme after I did some googling when creating this package, but I'm not up to date on what is required to make it work with xquartz. Xvfb is used as a virtual display, to support headless mode, and xquartz is supposed to replace that.
If you have the time I would suggest to look up some examples of xquartz usage and how we can use that as a virtual display.
If you have anything specific I can help brainstorm

So I've taken a look already and xquartz does not seem to be the real/first problem here. I installed it and with it came the xvfb cli util, which I'm assuming will function similarly.
The issue I'm tackling right now is that the Darwin build of Go does not support syscall.SysProcAttr.Pdeathsig (used here)

Darwin build
Linux build

So I'll have to find a way to manually kill it on exit. Working on that first.

Yeah windows has the same problem, that's why its separated now. But asides from killing it, does xvfb seem to work then?

So just plain copy-pasting the linux build to darwin and running the tests does not work, I get an EOF error on these lines in display_darwin.go
bufr.ReadString('\n') is returning the EOF error, stated in it's docs:

If ReadString encounters an error before finding a delimiter, it returns the data read before the error and the error itself (often io.EOF). ReadString returns err != nil if and only if the returned data does not end in delim.

...
	go func() {
		bufr := bufio.NewReader(pipeReader)
		s, err := bufr.ReadString('\n')
		ch <- resp{s, err}
	}()

	var display string
	select {
	case resp := <-ch:
		if resp.err != nil {
			log.Println("newFrameBuffer() error: ", err)

			return nil, resp.err
		}
...

➜  chromedp-undetected (master) go test -v -count=1 .
=== RUN   TestRunCommand
    chrome_test.go:39: Attempt 1/3
2023/06/04 12:27:55 newFrameBuffer() error:  <nil>
    chrome_test.go:39: Attempt 2/3
2023/06/04 12:27:55 newFrameBuffer() error:  <nil>
    chrome_test.go:39: Attempt 3/3
2023/06/04 12:27:55 newFrameBuffer() error:  <nil>
    chrome_test.go:71: 3 errors occurred:
        	* create context: EOF
        	* create context: EOF
        	* create context: EOF
...

I'm new to Go and unfamiliar to Goroutines so I'm not entirely sure how data is getting fed into the Reader but I'll take a deeper dive later.

So, some testing later I managed to get rid of the error above, except I'm not entirely sure how. I ran the tests with sudo a couple of times because of what I read here, and I believe I ran the xauth command manually once which might have generated some files...?
I get multiple running instances of xvfb because they aren't killed like we discussed above:
scraping/chromedp-undetected [master●] » ps -ef | grep -i 'xvfb'
    0 12823     1   0  8:25PM ttys000    0:00.05 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12827     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12831     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12835     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12839     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12843     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12847     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12851     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12855     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12859     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12863     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24
    0 12867     1   0  8:25PM ttys000    0:00.04 Xvfb -displayfd 3 -nolisten tcp -screen 0 1920x1080x24

And then errors from xauth saying it can't access the Security extension (tried with & without sudo)?:
scraping/chromedp-undetected [master●] » sudo go test -v -count=1 .
=== RUN   TestRunCommand
    chrome_test.go:39: Attempt 1/3
/opt/X11/bin/xauth generate :0 . trusted
xauth: (argv):1:  couldn't query Security extension on display ":0"
    chrome_test.go:39: Attempt 2/3
/opt/X11/bin/xauth generate :0 . trusted
xauth: (argv):1:  couldn't query Security extension on display ":0"
    chrome_test.go:39: Attempt 3/3
/opt/X11/bin/xauth generate :0 . trusted
xauth: (argv):1:  couldn't query Security extension on display ":0"
    chrome_test.go:71: 3 errors occurred:
        	* create context: exit status 1
        	* create context: exit status 1
        	* create context: exit status 1
...

I have never worked with xauth / xvfb before so this is a little out of my league ATM. I'll see what I can try later this week.


refactor(@angular-devkit/build-optimizer): skip search for empty pure import list

Thanks for optimizing this 👍


trying to use gemini as an LLM

When I need to from openagi.llms.gemini import GeminiModel, it asks me to install ..to install pip install langchain-google-genai and then there is a conflict between dependencies from openAGI mainly with pydandic and is circular. so the flow for this error..is try to install openagi first, then try to use gemini API and import langchain-google-genai and errors of conflicts with dependencies appear. the code really works well with azure.
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
langchain-google-genai 2.0.0 requires langchain-core<0.4,>=0.3.0, but you have langchain-core 0.1.52 which is incompatible.
langchain-google-genai 2.0.0 requires pydantic<3,>=2, but you have pydantic 1.10.7 which is incompatible.

Thanks for addressing the issue, will resolve it

https://github.com/aiplanethub/openagi/commit/79cf2563f9faa7aafb8f85e96b450c7aebf4cd3d
we have fixed the dependency issue. The new release will be made by the EOD


tf.print can't print chinese characters

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
win10 1909
TensorFlow installed from (source or binary):
pip install tensorflow
TensorFlow version (use command below):
2.0.0
Python version:
3.7.4

Describe the current behavior
import tensorflow as tf
tf.print("中文测试")
tf.print("Chinese test")
print("中文测试")
print("Chinese test")

current output is
涓枃娴嬭瘯
Chinese test
中文测试
Chinese test
expected output is
中文测试
Chinese test
中文测试
Chinese test

I have tried on colab with TF version 2.0 , TF Nightly version 2.1.0-dev20191229 and i am not seeing any issue. Please, find the gist here. Thanks!

I have tried on colab with TF version 2.0 , TF Nightly version 2.1.0-dev20191229 and i am not seeing any issue. Please, find the gist here. Thanks!

Hi , @ravikyram . When I run the code on linux by using python test.py or in jupyter (no matter on linux or windows) , It works well. But when I run it in powershell or cmd , it's strange that only tf.print can't output correctly . When I change windows global character encoding from ``GBKtoutf8``` , both of them works well ......

@DachuanZhao
Can we close this issue since the query is been resolved? Thanks!


[DON'T MERGE YET] adding Nelson Mandela Bay Municipality, South Africa

Couldn't find a license, but here's the conform in case anyone has more luck.
Website: http://www.nelsonmandelabay.gov.za/Business.aspx?pageID=154

Wow, look at that density!

I've asked them about the license today via http://www.nelsonmandelabay.gov.za/DepartmentFeedback.aspx.

I think this is fine to merge, it's CC-BY.
Here's the response to my email about the license:
Good Day

We are still in the process of updating the terms and conditions but in
essence below are the terms.

1)
NMBM makes no warranty of any kind, expressed or
implied, with regard to the data and shall not be held liable
in any event for any incidental or consequential damages in
connection with or arising out of the use of this data.
2)
Provide credit to the NMBM when using the data.

3)
You can redistribute the data but please then also send on the T&C.

Kind Regards
Franco Cilliers
GIS Analyst
NMBM
Tel:<PHONE_NUMBER>
-33.961766, 25.621739
2nd Floor Algoa House
Chapel Street, Central, PE

LGTM, merging.


Provider does not return schema, so it gets killed by terraform.

Seeing this in the logs when I run terraform.
TF_LOG=trace terraform plan

2022-06-23T15:40:39.544-0700 [DEBUG] plugin: starting plugin: path=.terraform/plugins/registry.terraform.io/apparentlymart/javascript/0.0.1/darwin_amd64/terraform-p
rovider-javascript_v0.0.1 args=[.terraform/plugins/registry.terraform.io/apparentlymart/javascript/0.0.1/darwin_amd64/terraform-provider-javascript_v0.0.1]
2022-06-23T15:40:39.549-0700 [DEBUG] plugin: plugin started: path=.terraform/plugins/registry.terraform.io/apparentlymart/javascript/0.0.1/darwin_amd64/terraform-pr
ovider-javascript_v0.0.1 pid=12210
2022-06-23T15:40:39.549-0700 [DEBUG] plugin: waiting for RPC address: path=.terraform/plugins/registry.terraform.io/apparentlymart/javascript/0.0.1/darwin_amd64/terraform-provider-javascript_v0.0.1
2022-06-23T15:40:39.595-0700 [DEBUG] plugin: using plugin: version=5
2022-06-23T15:40:39.595-0700 [DEBUG] plugin.terraform-provider-javascript_v0.0.1: 2022/06/23 15:40:39 [INFO] provider plugin server (protocol 5) listening on /var/folders/zn/g3308mln01lfmk2t03lkn6bc0000gn/T/rpcplugin832424433/server.sock
2022/06/23 15:40:39 [TRACE] GRPCProvider: GetSchema
2022-06-23T15:40:39.662-0700 [TRACE] plugin.stdio: waiting for stdio data
2022-06-23T15:40:39.662-0700 [WARN]  plugin.stdio: received EOF, stopping recv loop: err="rpc error: code = Unimplemented desc = unknown service plugin.GRPCStdio"
2022/06/23 15:40:39 [TRACE] No provider meta schema returned
2022/06/23 15:40:39 [TRACE] GRPCProvider: Close
2022-06-23T15:40:41.663-0700 [WARN]  plugin: plugin failed to exit gracefully
2022-06-23T15:40:41.665-0700 [DEBUG] plugin: plugin process exited: path=.terraform/plugins/registry.terraform.io/apparentlymart/javascript/0.0.1/darwin_amd64/terraform-provider-javascript_v0.0.1 pid=12210 error="signal: killed"

Hi @ferozed,
From looking in the main Terraform Core source code, it doesn't seem like "No provider meta schema returned" is an error situation, and instead it just reflects that this provider isn't making use of a particular feature of Terraform ("provider meta") that isn't relevant to it.
Although the TRACE logs are pretty chatty with lots of random minutia, I don't see anything here which looks like an error. GRPCProvider: GetSchema means that Terraform Core asked the provider for its schema, which seems to have succeeded because the message you indicated is in the success codepath of the provider client in Terraform Core, and then separately Terraform Core ran GRPCProvider: Close which is implemented on Unix systems by sending the plugin a SIGKILL signal, and we can see in the last line that is indeed how the plugin exited.
So with all of that said: whatever problem you've seen here, I don't think this trace log explains it. Can you say some more about what you tried to do, what you expected to happen when you tried it, and what happened instead? Thanks!

Hi!
Yeah, I just thought that SigKill was pointing to some bug., I usually dont see it when running AWS terraform providers.
If you dont think it is an issue, that is fine.


build rhel stemcell failed by RHEL 7 stemcell behaves like a CentOS 7 or RHEL 7 stemcell installed by image_vsphere_cdrom stage File "/etc/sysctl.conf" should contain "dev.cdrom.lock=0"

Failures:

RHEL 7 stemcell behaves like a CentOS 7 or RHEL 7 stemcell installed by image_vsphere_cdrom stage File "/etc/sysctl.conf" should contain "dev.cdrom.lock=0"
Failure/Error: it { should contain 'dev.cdrom.lock=0' }
expected File "/etc/sysctl.conf" to contain "dev.cdrom.lock=0"
Shared Example Group: "a CentOS 7 or RHEL 7 stemcell" called from ./spec/stemcells/rhel_7_spec.rb:6
./spec/support/stemcell_centos_rhel_7_shared_examples.rb:65:in `block (4 levels) in <top (required)>'
./spec/support/stemcell_image.rb:8:in`block (3 levels) in <top (required)>'
./lib/bosh/stemcell/disk_image.rb:35:in `while_mounted'
./spec/support/stemcell_image.rb:6:in`block (2 levels) in <top (required)>'

Closing due to inactivity. If this is still an issue on recent stemcells please open a new issue in https://github.com/cloudfoundry/bosh-linux-stemcell-builder


Question about OneSignalPushAdapter

I migrate my push notification to parse server. But I found a problem for android:

The new sdk (1.13.0) doesn't work for my existing code. I can't get the push notification any more.
New push will only support GCM for android which is not what I want because some of my clients are in China which I believe that the Google service is blocked.

That's why I'm seek of new solution. And I found OneSignalPushAdapter example in the document. My question is if I still can use the same Android/iOS Client SDK? Thanks.

iOS should be fine, the adapter is for the actual delivery of notifications, should be transparent to the client registering for push.  Non-GCM Android will not work, though, unless PPNS gets implemented.
PPNS spec: https://github.com/ParsePlatform/parse-server/wiki/PPNS-Protocol-Specification

Thanks for your information. I'm able to get my ios application work in both parse.com or parse server. Is there any plan to implment PPNS for Android?


Fibers not being installed under node v8.1.2

Complains about node-gyp not being found.

Please file this issue in the fibers project. Thanks!

Hi, I have the same problem and this is resolved in version 2 of fibers.
Greenkeeper already upgrade the package.json, so all we need is a new version in NPM


[Bug] Missing shape infer for conv2d

Note: This bug is triggered by an unconventional use of Ratex. Normally what I am describing below should not happen.
Description
I was trying to inspect the lazy tensor IR of the LeNet example without using ratex.jit.script. I was expecting that the lazy tensor IR would contain all PyTorch operators in fwd, bwd, and weight update, but the example crashed before generating the lazy tensor IR graph. More precisely, it crashed during shape inference when trying to lower to RAF:
RuntimeError: [22:29:54] /home/ubuntu/ratex/ratex/ratex/csrc/compiler/raf_node_lowering.cpp:1374: Shape inference not supported for operator: aten::convolution_overrideable

The convolution_overrideable operator is not listed in the function and thus falls to the default case. Seems like we are only supporting a small set of native PyTorch operators over here, which is sufficient if we only consider ops used during weight update but will error out for many ops inside the fwd/bwd passes.
Tentative Solution
The solution is conceptually simple, that is, to add the missing cases for all other operators. My concern here is that whether this is necessary, because this won't be triggered if we use Ratex normally. Please let me know if you have any suggestions.

We will have a better support for the ops after Awais's work @anadeem2. He will soon add the support for matmul and other operators that are used in Bert-like model. The support for CV model might still need help.

Addressed in PR #16.


[FEATURE] Add cloud saves

Describe the solution you'd like
Add a class and macro supporting cloud saves.
Overwrite the GameSettings.cs file to support cloud saving automatically.
Tasklist

[ ] Look into the currently existing interface on interacting with PlayerPrefs.  See if the same interface can be used for.
[ ] Add JSON support (saving and recalling via Unity JSON libraries).
[ ] Look into what other services to potentially integrate with.  Add these items as potentially a new issue on this project.

Additional context
Carry-over from the old Bitbucket Mercurial project:
https://bitbucket.org/OmiyaGames/hg-template-unity-project/issues/70/add-cloud-saves

Closing as duplicate of #8


Update page.file source path with original source, fixes #12

This approach uses the on_pre_page event to update the page absolute source path attribute. It should fix issues when combining mkdocs-monorepo-plugin with plugins that depend on that attribute, like mkdocs-git-authors-plugin and mkdocs-git-revision-date-localized-plugin.

@timvink Thanks for the PR! Looks good to me.
Before I merge, there's two things:

Version change. Bump up the version in /setup.py (I think right now it should be 0.4.5 given it isn't a breaking change). A simple change note in docs/CHANGELOG.md would be good too.
Test coverage. Add test cases against the two plugins (i.e. mkdocs-git-authors-plugin and mkdocs-git-revision-date-localized-plugin. It would be good to ensure that over time we can retain compatibility with these two plugins. I would suggest three cases: plugin A, plugin B, and then one with plugin A and B. You should be able to easily add them in our test.bats file and then by making two folders (just copy the ok folder as a base) in our fixtures folder. You might need to add those dependencies to our root requirements.txt file too (linked here) although probably in a separate PR we should have two - one for prod, one for testing.

Let me know if you need more guidance, hoping we can ship this change soon! :)

Thanks for the guidance!
I added the unit tests. I had to add apt-get install git to the unit test setup in order for the tests to run.
Note that I fixed the versions of the plugins in requirements.txt.. I don't want to break any CI in case of future updates. I would recommend to consider setting up https://dependabot.com/ for this project, you will get a MR from a bot as soon as there are any updates to dependencies.
Let me know if there is anything else I can improve :)

Hi @bih, is there any chance we could move this solution forward? Can I help in any way?

@pauloribeiro-codacy @timvink Finally got around to merging this. Sorry for the waiting on your side folks! :-)

Just tried updating to this. It was working fine before this change, and now I'm getting a KeyError on one of my docs:
KeyError: '/var/folders/z6/gndttzfn5z34y_wkpmm9fyyw0000gp/T/docs_373fzmc5/best_practices/README.md'

@bih any idea?

I also ran into the same issue. Here's the traceback:
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.8.3/x64/bin/mkdocs", line 8, in <module>
    sys.exit(cli())
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/site-packages/mkdocs/__main__.py", line 159, in build_command
    build.build(config.load_config(**kwargs), dirty=not clean)
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/site-packages/mkdocs/commands/build.py", line 274, in build
    _populate_page(file.page, config, files, dirty)
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/site-packages/mkdocs/commands/build.py", line 163, in _populate_page
    page = config['plugins'].run_event(
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/site-packages/mkdocs/plugins.py", line 94, in run_event
    result = method(item, **kwargs)
  File "/opt/hostedtoolcache/Python/3.8.3/x64/lib/python3.8/site-packages/mkdocs_monorepo_plugin/plugin.py", line 62, in on_pre_page
    page.file.abs_src_path = self.files_source_dir[page.file.abs_src_path]
KeyError: '/tmp/docs_senr2psd/Chart/configuration/monitoring.md'

Hmm, that's not good.
I'm having trouble reproducing this locally. Which plugins do you have activated? Doing mkdocs serve or mkdocs build? And if it's a small site, a tree of the structure might also help to pinpoint the issue.
Somehow these files were not registered when the mono repo merged the docs:
https://github.com/timvink/mkdocs-monorepo-plugin/blob/ba2e410d811bf5566a677e41373a6d5c479bd630/mkdocs_monorepo_plugin/merger.py#L67
I need to figure out why..

Yes, I was also noticing this. In the traceback the temporary folder mentions:
/tmp/docs_xxxxxxxx/Chart/configuration/monitoring.md
But the Markdown file is actually in a /docs folder inside the "Chart" submodule repository:
/docs/configuration/monitoring.md

I found the root cause & created a hotfix to solve it: https://github.com/spotify/mkdocs-monorepo-plugin/pull/19. Sorry for missing this :(
@bih hope you can review + merge quickly, as we now have a bug in production..

I believe we still have an incompatibility with the git-revision-date-localized plugin. When I have both plugins activated, Git does not detect the temporary folder as a local Git repository:
Traceback (most recent call last):
  File "/home/prcr/.local/bin/mkdocs", line 11, in <module>
    sys.exit(cli())
  File "/home/prcr/.local/lib/python3.6/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/home/prcr/.local/lib/python3.6/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/home/prcr/.local/lib/python3.6/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/prcr/.local/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/prcr/.local/lib/python3.6/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/home/prcr/.local/lib/python3.6/site-packages/mkdocs/__main__.py", line 152, in build_command
    build.build(config.load_config(**kwargs), dirty=not clean)
  File "/home/prcr/.local/lib/python3.6/site-packages/mkdocs/commands/build.py", line 236, in build
    config = config['plugins'].run_event('config', config)
  File "/home/prcr/.local/lib/python3.6/site-packages/mkdocs/plugins.py", line 94, in run_event
    result = method(item, **kwargs)
  File "/home/prcr/.local/lib/python3.6/site-packages/mkdocs_git_revision_date_localized_plugin/plugin.py", line 36, in on_config
    self.util = Util(path=config["docs_dir"])
  File "/home/prcr/.local/lib/python3.6/site-packages/mkdocs_git_revision_date_localized_plugin/util.py", line 14, in __init__
    git_repo = Repo(path, search_parent_directories=True)
  File "/home/prcr/.local/lib/python3.6/site-packages/git/repo/base.py", line 181, in __init__
    raise InvalidGitRepositoryError(epath)
git.exc.InvalidGitRepositoryError: /tmp/docs_o4kb_ykw

This is just a wild guess, but could it be that the .git folder is not being copied to the temporary folder?

OK that's unfortunate. Thanks for the persistent reports, really helpful !
I did some more research and here's what's going on:
1. bats testing not working
All units tests pass, but the follow fails with the InvalidGitRepositoryError error:
mkdocs build -f __tests__/integration/fixtures/ok-mkdocs-git-revision-date-localized-plugin/mkdocs.yml

--> @bih Perhaps this is something you can fix on your end, as it seems like something is wrong with bats? Not urgent though.
2. Finding the .git folder
mkdocs-git-authors-plugin works fine with monorepo now, but mkdocs-git-revision-date-localized-plugin gives InvalidGitRepositoryError . Here's why:

revision-date looks in the config["docs_dir"] folder for .git,  on the on_config() plugin event. This is because some users have their .git folder inside the docs/ folder (f.e. when using git submodules), context in this PR. monorepo changes the value of the docs_dir to the temporary folder, so it's looking in the wrong place.
git-authors stores the current working directory on __init__, and recursively looks upward for a .git folder. In the future, it should also use the docs_dir for the same reason as the revision-date plugin.

A potential solution should be able to access config["docs_dir"] before monorepo changes it. mkdocs runs plugin events in the order they are defined. So the solution is actually quite simple; change in your mkdocs.yml the ordering from:
plugins:
  - monorepo
  - git-revision-date-localized

to:
plugins:
  - git-revision-date-localized
  - monorepo

On my side I will work on a new release of mkdocs-git-revision-date-localized-plugin that raises an instructional error if the plugin ordering is wrong. I opened https://github.com/timvink/mkdocs-git-revision-date-localized-plugin/issues/34 for that.

Thanks @timvink, the workaround of reordering the plugins in the mkdocs.yml works for me. :+1:


[Bug] Used exports are excluded with the "unused export" comment when using export * as ...

Reproducible in vscode.dev or in VS Code Desktop?

[X] Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

[ ] Not reproducible in the monaco editor playground

Monaco Editor Playground Code
No response
Actual Behavior
Steps to reproduce:

Clone https://github.com/microsoft/monaco-editor
cd samples/browser-esm-webpack-monaco-plugin
Add file file.js with one line export * as monaco from 'monaco-editor/esm/vs/editor/editor.api';
Replace import * as monaco from 'monaco-editor/esm/vs/editor/editor.api'; in index.js with import { monaco } from './file';
NODE_ENV=production npm run build

Result:
dist/main.bundle.js should contain
_common_network_js__WEBPACK_IMPORTED_MODULE_8__/* .RemoteAuthorities.setPreferredWebSchema */ .WX.setPreferredWebSchema(/^https:/.test(window.location.href) ? 'https' : 'http');
but instead it has
/* unused export .RemoteAuthorities.setPreferredWebSchema */ undefined(/^https:/.test(window.location.href) ? 'https' : 'http');
which cause a runtime error (you can open dist/index.html in browser to see)
You can switch between the old line in index.js and the new one to see the difference.
Works similar in development mode.
Expected Behavior
Shouldn't exclude used exports
Additional Context
It's not the webpack bug https://github.com/webpack/webpack/issues/15346

Also, I can confirm that changing
        ...pre.map((include) => `require(${stringifyRequest(include)});`),
        `module.exports = require(${stringifyRequest(`!!${remainingRequest}`)});`,
        ...post.map((include) => `require(${stringifyRequest(include)});`)

to
        ...pre.map((include) => `import(${stringifyRequest(include)});`),
        `import * as xxx from ${stringifyRequest(`!!${remainingRequest}`)};`,
        `export default xxx;`,
        ...post.map((include) => `import(${stringifyRequest(include)});`)

inside include.ts helps


Support Active Directory Authentication for MS SQL in native-image

Copied from original issue https://github.com/quarkusio/quarkus/issues/36587:
Description
As of now, quarkus does not support Active Directory Authentication in native mode with the MS SQL driver. Since this is a standard authentication method for databases hosted in azure, it would be nice if quarkus supported AD authentication in native mode.
User story
As a quarkus developer, developing a native image application
When I connect to a MS SQL database
Then I want the possibility to use AD authentication

Hi everyone! I'm having the same problem in native mode, did you find a solution that you can share? Thanks :D

Hello @yoinercoding, thanks for reaching out to me. Unfortunately, I haven't worked on this issue yet, will let you know once there is a working solution.

Hi! @majguo Thanks for replying. If I can help in any way, please let me know :D ✅

@yoinercoding looking at the original issue https://github.com/quarkusio/quarkus/issues/36587 may be of interest. It seems that it is getting some traction.