It doesn't effect when pictures are “webp” format [bug]

Is your feature request related to a problem? Please describe.
It doesn't effect when pictures are “webp” format.  It works when the format are png & jpeg, but when copy a batch pictures from internet , the default format become webp, and the rules uneffect!
Describe the solution you'd like
hope to support webp format , especially copy a batch pictures from internet!
Describe alternatives you've considered
when copy some words and pictures more than one , the format changed, from png or jpeg become webp, and rename rules useless
it works when copy a single png picture

It doesn't effect when pictures are “webp” format  (copy more pictures become webp format)

The plugin converts png to jpeg , what it has to do with webp...
To be honest I cannot understand a thing.
See how to write bug reports:
https://marker.io/blog/how-to-write-bug-report


Build questions ./configure missing?

Please excuse this is it's novice-level questions.  I am following the INSTALL.md instructions.  I'm on Ubuntu 16.10 x64.  Questions:

After cloning the initial Github fizmo project, I did 'git submodule update --init --recursive' - is that correct?
I find no ./configure to run.  Is a step missing in the INSTALL.md to run 'autoconf'?
after running 'autoconf', I did get a configure. Next I run './configure' but get this error: configure: error: cannot find install-sh, install.sh, or shtool in . "."/.  I did apt-get install shtool but the error still persists after rerunning autoconf and ./configure.
autoconf reported two problems, listed below.

configure.ac:51: error: possibly undefined macro: AM_INIT_AUTOMAKE       If this token and others are legitimate, please use m4_pattern_allow.       See the Autoconf documentation. configure.ac:57: error: possibly undefined macro: AM_CONDITIONAL
Thank you.

ok, some progress, I found instructions on forum: http://www.intfiction.org/forum/viewtopic.php?f=7&t=19868&start=20#p108284

I have a second computer running Ubuntu 16.04 LTS x64, and I have the same problem with fizmo-sdl2 and fizmo-ncursesw crashing even with just '--help'.  fizmo-console works fine. Any ideas?

Opened Issue #4 related to the Ubuntu 16.04 x64 crashes, I might have found where it is bombing.
Related to ./configure issues. If I do ./configure --enable-tracing the code fails to compile with make:
 fizmo-ncursesw.c:361: undefined reference to `_trace_log_z_ucs'

Hi, and thanks for reporting your problem.
First, if you only need fizmo-console or fizmo-ncursesw, you can install these from the package repository using "apt-get install fizmo-console" or "apt-get install fizmo-ncursesw".
For all the other frontends you have to build these from source. Before building, you'll have to install the required development packages by running the following commands as root:
apt-get install gcc make pkg-config autoconf automake
apt-get install libxml2-dev libncursesw5-dev libsdl2-dev
apt-get install libsndfile1-dev libjpeg-dev libpng-dev libfreetype6-dev
For the build itself there are two ways to do this. The first one is by downloading the pre-packed version from the official site:
wget https://fizmo.spellbreaker.org/source/fizmo-0.8.3.tar.gz
tar -xf fizmo-0.8.3.tar.gz
cd fizmo-0.8.3
mkdir -p $HOME/opt/fizmo
./configure --prefix=$HOME/opt/fizmo
make -j4 install
~/opt/fizmo/bin/fizmo-sdl --help
If you need / want the latest beta-ish version from github you can try the following:
git clone --recursive https://github.com/chrender/fizmo
cd fizmo
The "autoreconf" will generate the configure script and everything else automake needs:
autoreconf -fi
mkdir -p $HOME/opt/fizmo
./configure --prefix=$HOME/opt/fizmo
make -j4 install
~/opt/fizmo/bin/fizmo-sdl --help
I've tried both ways on 16.10 and both appear to work. Maybe you can give it a try to see if this helps.

Thank you for the help! I followed your directions for the github checkout.  Good news is that now on one of my 16.10 x64 systems the --help segfault is gone and the fizmo-ncursesw is now working.  fizmo-sdl2 is crashing once a story starts after the 'story splash screen' on stories like Bronze.zblorb - again, the same story works fine now with fizmo-ncursesw.
I did ./configure with tracing enabled, here is the trace log: https://gist.githubusercontent.com/BroadcastGames/186fbfa50ca3fd9f690da20cc87019c2/raw/58f7a2ddf3e5c0d57500e0739771de2c63db6eee/tracelog.txt
The only message on crash that appears is Segmentation fault (core dumped), is there a way to compile it or something to get a stacktrace?

Some good news. The last reported GIthub build (previous message) was on my Intel laptop system with Intel GPU and Ubuntu 16.10 x64.  I built it this morning on my Intel desktop with Nvidia GPU and Ubuntu 16.04 x64. The fizmo-ncursesw build seems perfect.

Good news. I've got a diverse set of hardware, one laptop system with Intel GPU and Ubuntu 16.10 x64 clean install (format partitions, not an upgrade). The other a Nvidia GPU and Ubuntu 16.04 x64.  The previous report was on the Ubuntu 16.10 system and now I've done a fresh github checkout and build on the Ubuntu 16.04 x64 Nvidia GPU system.
I'm getting further! Many games work fine. However, fizmo-sdl2 testing, with tracing enabled has a few problems. I'll open new issues related to specific observations.  Thank you again for the assistance!

Thanks for the tracelog, this allowed me to reproduce the problem. It appears that you're running fizmo-sdl2 on a screen smaller than the default size – your size appears to be 600×716, default is 800 × 600 – and fizmo doesn't handle the initial resize correctly.
As a workaround, you can set alternate initial screen sizes, so fizmo-sdl2 doesn't have to do the faulty resize, for example:
fizmo-sdl -ww 640 -wh 480 <story-file>

This made fizmo-sdl2 start up correctly for me, even when running on a smaller screen. Hope this helps for the time being, I'll see that I can fix this in fizmo-sdl2.

I was re-reading the trace, and I noticed something: /home/adminsag/.config/fizmo/story-list.txt is being opened for past attempts of stories that you tried?  So, even though I told it to open "Bronze" on the command line, it is also opening up past games?
I say this - because I had fed some Glulx .gblorb stories into fizmo-sdl2 at one point by accident (I had a mix of games in one folder from testing another app)... and I wonder if that was somehow being 'remembered' in story-list.txt and causing some of my unexplained crashes.
If you want, I can open a new issue - the basic behavior of fizmo-sdl2 is if you hand it an incompatible game (Glulx) it just exits without showing any kind of message explaining why. Even if you pass it an invalid filename, it just exits. ~/opt/fizmo/bin/fizmo-sdl2 missingfile

Commit 4e7fc51eacf1810da978643cc17d4542e8dfbdf8 fixes the startup problem for linux. Fix for Mac OS X and filter-based SDL-processing still to be done.

I believe the startup issue is now also solved for filter-based aka Mac OS X-based SDL-processing in d91b0b93fae1d6bdf42e4b664191cbadc6b69ba1.

The story list keeps track of the story files which have been either opened so far, or found via search actions. Currently these are only used for fizmo-ncursesw – if you're running fizmo-ncursesw all by itself it shows a list of known stories and their descriptions. This data is stored in ~config/fizmo/story-list.txt. In case there's some entry stored which actually doesn't make sense this shouldn't cause any problems, so for the time being you can simply ignore it.

It would be nice indeed if you could open two more issues for the missing exit messages and the messed-up terminal state since this issue thread is now getting rather diverse. However, even if you don't open up new issues I'll see that both will get addressed.

Thank you for the information and software! Opened two new issues. Have a good week!

Thank you, and you too. I've now tested the latest version on Ubuntu 16.10, Debian and Mac OS X, and I believe that the startup issue has been fixed for all of them. Since all the other problems now have their own separate issue assigned I'll close this one. Should you still run in any startup-related problems, please let me know.

Regarding closing this issue, has the INSTALL.md actually been updated to reflect these new build instructions?
FYI, I'm having build problems with remglk missing a file. Here is the steps I'm using:
`mkdir fizmo_emptydir
cd fizmo_emptydir
git clone https://github.com/erkyrath/remglk.git
cd remglk
make
cd ..
git clone --recursive https://github.com/chrender/fizmo
cd fizmo
The “autoreconf” will generate the configure script and everything else automake needs:
autoreconf -fi
mkdir -p $HOME/opt/fizmo
./configure --prefix=$HOME/opt/fizmo --enable-remglk --with-remglk-includedir=../remglk --with-remglk-libdir=../remglk
make -j4 install
`
Results in this error: glk_interface.c:39:17: fatal error: glk.h: No such file or directory  #include "glk.h" (in the middle of the output messages, pretty easy to miss).  I see the file is in remglk/glk.h - am I doing something wrong?

ok, digging deeper, I opened a new issue #12 - the problem is that ./configure says the path is fine but the actual compiler doesn't like the '../" relative path.  Using an absolute path works around the issue.

I've updated the installation instructions in 7880adb8d30fe8522f46d5e1a08210e164a31959 to cover the github sources. As with all the modules, there's now also an “upstream” branch for the fizmo distribution repository which contains everything as required for the distribution tar file (meaning configure, .txts etc).

did a fresh checkout today from github, now a new problem:
checking for /home/user0/linuxTerm/fizmo/fizmo_root7/remglk/glk.h... yes
checking remglk.h usability... no
checking remglk.h presence... no
checking for remglk.h... no
checking for /home/user0/linuxTerm/fizmo/fizmo_root7/remglk/remglk.h... yes
checking for main in -lremglk... no
checking for libremglk in /home/user0/linuxTerm/fizmo/fizmo_root7/remglk... no
checking for libremglk in /usr/lib... no
checking for libremglk in /usr/local/lib... no
Could not find libremglk.
Try setting the location using --with-remglk-libdir.
configure: error: Could not find libremglk.

I did a make on remglk and there is a file libremglk.a in that folder. Any ideas?


Program files /app/out/ folder being deleted nightly.

Type: Bug
C:\Program Files\Microsoft VS Code\resources\app\out directory being deleted nightly for about 2 weeks now. After this happens, open VS Code windows are partially functional but new windows will not open, triggering this error instead.
A JavaScript error occurred in the main process
Uncaught Exception:
Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'C:\Program Files\Microsoft VS
Code\resources\app\out\main.js' imported from C:\WINDOWS\system32
at finalizeResolution (node:internal/modules/esm/resolve:265:11)
at moduleResolve (node:internal/modules/esm/resolve:940:10)
continued...
To fix it, I end all vscode processes in windows task manager, then re-run installer. I've noticed when closing the processes, there are a few vscode install/uninstall processes running when stuck in this state, so I'm not sure if this is due to some self-update going wrong.
Not sure if this is being caused by a VS code bug or my company's antivirus software. Any help would be appreciated.
VS Code version: Code 1.95.0 (912bb683695358a54ae0c670461738984cbb5b95, 2024-10-28T20:16:24.561Z)
OS version: Windows_NT x64 10.0.26100
Modes:
Remote OS version: Linux x64 6.8.0-48-generic

System Info

Item
Value

CPUs
11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz (8 x 2995)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabledwebnn: disabled_off

Load (avg)
undefined

Memory (System)
15.74GB (1.81GB free)

Process Argv
--crash-reporter-id 81949ced-f38a-4b7b-a6fd-0494dce958d4

Screen Reader
no

VM
0%

Item
Value

Remote
SSH: netbox-dev.jsinoc.com

OS
Linux x64 6.8.0-48-generic

CPUs
Intel(R) Xeon(R) Gold 6208U CPU @ 2.90GHz (4 x 0)

Memory (System)
7.67GB (2.34GB free)

VM
0%

Extensions (14)

Extension
Author (truncated)
Version

codespaces
Git
1.17.3

cisco
jam
1.9.1

remote-containers
ms-
0.388.0

remote-ssh
ms-
0.115.0

remote-ssh-edit
ms-
0.87.0

remote-wsl
ms-
0.88.5

remote-explorer
ms-
0.4.3

iosxr
phi
1.0.4

pdf
tom
1.2.2

vscode-docker
ms-
1.29.3

debugpy
ms-
2024.12.0

python
ms-
2024.18.1

vscode-pylance
ms-
2024.11.1

save-as-root
yy0
1.8.0

A/B Experiments
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
pythonnoceb:30805159
asynctok:30898717
pythonmypyd1:30879173
2e7ec940:31000449
pythontbext0:30879054
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
945dj816:31013170
dvdeprecation:31068756
dwnewjupytercf:31046870
newcmakeconfigv2:31071590
impr_priority:31102340
nativerepl2:31139839
refactort:31108082
pythonrstrctxt:31112756
cf971741:31144450
iacca1:31171482
notype1:31157159
5fd0e150:31155592
dwcopilot:31170013
j44ff735:31179530

I have now updated to 1.95.2 through the UI with no trouble. I will monitor in the coming days to see if the issue persists.
Version: 1.95.2 (system setup)
Commit: e8653663e8840adaf45af01eab5c627a5af81807
Date: 2024-11-07T11:07:22.054Z
Electron: 32.2.1
ElectronBuildId: 10427718
Chromium: 128.0.6613.186
Node.js: 20.18.0
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.26100

I can confirm the issue has reoccurred again today.

Here is what my task manager lists when the errorred condition is taking place.

I have been able to stop this behavior by doing two things:

Enabling Windows UAC to get VSCode to NOT run as Administrator all the time.
Replace the VSCode system wide install with the user-scope install.

One or both of these actions have fixed my issue. I still think this should be fixed but at least there is a workaround.


[release/v1.57] Update AMI filter for rocky linux (#1803)

What this PR does / why we need it:
This is a manual backport of #1803.
What type of PR is this?
/kind chore
Does this PR introduce a user-facing change? Then add your Release Note here:
Update AWS AMI filter for rocky linux 8

Documentation:
NONE

@xrstf https://github.com/kubermatic/machine-controller/blob/release/v1.57/examples/operating-system-manager.yaml#L1321
s/v1.3.4/v1.3.6

/lgtm cancel
To avoid retries

/lgtm


Need to be able to set our own operators

E,g, when using new Resolvers\EwResolver(), it would be great if we could do new Resolvers\EwResolver('ends_with'), which would set the regex to look for ends_with rather than ew as the operator.

Thanks for the suggestion!
Currently, for each resolver there are at least 2 operators (one with symbols and one with letters), for e.g. EqResolver can have both eq and =.
So, in order to change these operators through the costructor, an array is expected. The result should be something like this: new Resolvers\EqResolver(['eq', '=', 'equals', 'custom']), in your case new Resolvers\EwResolver(['ew', 'ends_with', '$=']).
You have expressed the will to overwrite the current operators, but if someone wants to "add" and not "overwrite" ? You will have to repeat the default operators.
Also, having a list of Resolvers full of different arrays is kind of ugly, but maybe it just me.
Ultimately you can already change the operators by extending the resolvers and creating your own language.
I'll think more about it later

Fair call,
I didn't research this enough before proposing this suggestion, you're correct that it's trivial to create your own due to the actual node being separate from the resolver.


use bash script for the crate entry point

test...

Current coverage is 0.00% (diff: 100%)

Merging #4501 into master will decrease coverage by 81.22%

@@             master   #4501   diff @@
=======================================
  Files          1293    1293
  Lines         44086   44086
  Methods           0       0
  Messages          0       0
  Branches       7004    7004
=======================================
- Hits          35811       0   -35811
- Misses         5594   44086   +38492
+ Partials       2681       0    -2681

Powered by Codecov. Last update ec91fd3...4d11921

pls check hwy we need bash here, does this add a new dependency on bash, or do we have the dep already?

Ubuntu defaults shell script execution to dash instead of bash.
if [[ ... ]] is not supported in dash
if [[ $2 == es.* ]]; then
    echo "Setting Crate specific settings with the -D option and the es prefix has been deprecated."
    echo "Please use the -C option to configure Crate.\n"
fi

I think it would be possible to replace that with
if printf "%s" $2 | grep -Eq 'es.*'; then
 ...
fi

see http://stackoverflow.com/a/31366734

@dobe or @mfussenegger it should work fine now for most shells.


Type 'never' incorrectly inferred for mixed primitive type properties assignment with strictNullChecks disabled

🔎 Search Terms
strictNullChecks false assign never
🕗 Version & Regression Information

typescript 3.6.0-dev.20190612, 3.6.0, and every version on TS Playground between 3.6.1 and nightly (5.7.0-dev.20240914)
This changed between versions 3.6.0-dev.20190611 and 3.6.0-dev.20190612
This changed in commit or PR 74c6bc1f85c2ab36fdb789aa0ef6ee5dbde5afdd (#31708)

No error in da2aa9781e582bebd531750a4b8a81d9f8be2906

⏯ Playground Link
https://www.typescriptlang.org/play/?strictNullChecks=false&ts=5.6.2#code/C4TwDgpgBA8gRgKygXigbwFBSmATgezAEYB+ALigGdhcBLAOwHMBuLHAsAJnKpoZbZ5CAZh70ArgFs4EXK2xCwAFh4ARAIbAIrAL6sMAegNQAwusrQiFAIIAbW+0KzgtCJSgALdQDdowD9CU6pJ+4NAAFNR0TACUGADG+PTUUABmRChQ4fiIFPAIADRQANYQIBQARIpEFVAAPlBVHJwVMSgAfOhsOQgA2qUgALqZ4vQAJhCpDBBjzFBGUHYA7uog7t7qtrRj3Yj9ZcOoEvZzCwBqm9tQSwH0vHTxwABy4vYmAfHF7rTuqZsWGD0GEMxjMFignAoAAUOM5XO4vL4oGNaKlUrIIPRgOxaJJaC4kaBIO5InwmPUoBJpLI4olktjUpxMtlcrBEEUBpVqrUGk0RK0Ol1sD19kMRuNJtNZvNjABRXAEXDXW73WiPF5vD5fKA-NL-CAAOigsoAHpBHjMoMB8FAZFANlsdsK9gNDpTXrZTsZlqt3LJFUbTeatGMrTa7Q6rjdMar1R73hBPt9fvq2HSUg7MiLXV7FrYVmt7ZdQ+EidBdVF+BSqTJcHE2AsAOr4XDFdQEUZOqDp7E9JmoHpQczoao8TuS+gzIqKUQUcdTSdjIHOhCcUVu+dS3MXR27VfrzLHT0yqA7qMqytxzWJ7W6v62AFAkGmczQYTQ2G4FxuHX0eK2cQJltfB-BxPECWgdRxigHpE2xMsSUrckGg0LRaSSFJUmEZkejydkSjKLkOBqCk+WUAVkE6TAVwPVBN0XXMfULSMu2zA5Dw9bdi2VGNL2eeMtWTPUHwgQFmCAA
💻 Code
type Obj = {
  prop1?: string;
  prop2?: string;
  prop3?: number;
  prop4?: Date;
};

// Case 1: All properties have the same type (string)
const f1 = (obj: Obj, key: "prop1" | "prop2") => {
  obj[key] = undefined; // Always valid
  obj[key] = null; // Valid when strictNullChecks is false
};

// Case 2: Properties have different primitive types (string | number)
const f2 = (obj: Obj, key: "prop1" | "prop3") => {
  obj[key] = undefined; // Error when strictNullChecks is false. Expected to be valid
  obj[key] = null; // Always error. Expected to be valid when strictNullChecks is false
  const val = obj[key]; // Always valid (type is string | number)

  // Workaround
  const obj2 = obj as {prop1?: undefined, prop3?: undefined};
  obj2[key] = undefined; // Valid
  obj2[key] = null; // Valid when strictNullChecks is false
};

// Case 3: Properties include both primitive and object types (string | Date)
const f3 = (obj: Obj, key: "prop1" | "prop4") => {
  obj[key] = undefined; // Always valid
  obj[key] = null; // Valid when strictNullChecks is false
};

🙁 Actual behavior

In Case 2, when strictNullChecks is false:

Assigning undefined results in an error: "Type 'undefined' is not assignable to type 'never'.(2322)"
Assigning null always results in an error: "Type 'null' is not assignable to type 'never'.(2322)"

The behavior is inconsistent across different combinations of property types.

🙂 Expected behavior
Since all properties in Obj are optional, it should be possible to assign undefined to obj[key] regardless of the strictNullChecks setting. Additionally, when strictNullChecks is false, assigning null should be allowed for all cases.
Additional information about the issue
No response

Since all properties in Obj are optional, it should be possible to assign undefined to obj[key] regardless of the strictNullChecks setting.

That would depend on the exactOptionalPropertyTypes setting.

That would depend on the exactOptionalPropertyTypes setting.

I didn't know that. However, at least in TypeScript 5.6.2 and 5.7.0-dev.20240914, it seems that strictNullChecks=false and exactOptionalPropertyTypes=true cannot be used together.


[CARBONDATA-1912] Handling lock issues

Description :
Getting error trace in spark-sql console while executing compaction and alter table rename commands.
Scenario:
execute compaction and alter table rename queries in spark - sql
Even though operation is success , getting error trace on the console
Solution: In compaction we are already handling unlock after operation , so we can handle unlock in catch block instead of finally block.
In alter table rename operation: no need to unlock file on old location which will result error due to table name change.
Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[ ] Any interfaces changed?

[ ] Any backward compatibility impacted?

[ ] Document update required?

[ ] Testing done
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2138/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2428/

Build Failed with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/927/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2156/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2449/

retest this please

retest this please

retest this please

retest sdv please

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2236/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1012/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2494/

LGTM


start to translate the documentation/docs/misc folder to portuguese

[ ] docs(pt): translate docs/misc/faq.md
[ ] docs(pt): translate docs/misc/accessibility-warnings.md
[ ] docs(pt): translate docs/misc/typescript.md
[ ] docs(pt): translate docs/misc/v4-migration-guide.md

@fabiorodriguesroque, first, thank you for offering to help translate this project and impact the community with its conclusion. So @fabiorodriguesroque you can start translating this folder and if you have time you could also review the already translated documents to improve them.


New UID cloner request

Hi, i'm using ChangeUID.ino to clone UIDs from mifare classics 1k to another block 0 writeable tag.
But this way i need PC to change the values of each UID.
So, is possible to make a skech that first read original tag block 0 (UID) and then after few seconds write it to the writeable tag?
I want to make a stand alone device with 16x2 lcd and batterie  to clone uids on the go.
Thanks in advance.

I can clone my own access card into a keychain to make my work easier.
I doing it now with changeUID.ino, it's legitim. It's 100% legal.
You don't know my intentions.
I'm trying to make for people at my work, theirs own credential. Credential that they already have. I can't change their permissions only give then a second key.
Can you understantd those reason?


proc-macro2 is hard pinned in arrow-flight

Describe the bug
By pinning the version of proc-macro used in arrow-flight it prevents updates of the proc-macro crate in downstream dependencies such as Datafusion, resulting in errors such as https://github.com/apache/arrow-datafusion/issues/1498 (when a bugfix to a dependent crate requires upgrading to a newer version of proc-macro2
To Reproduce
See https://github.com/apache/arrow-datafusion/issues/1498
Expected behavior
Be as flexible with the versions allowed as possible
Additional context
Add any other context about the problem here.

Filed request to yank broken crates.io release: https://github.com/dtolnay/quote/issues/204


"az account list" returncode is 0 while not logged in.

az feedback auto-generates most of the information requested below, as of CLI version 2.0.62

Describe the bug

After "az logout", "az account list" output is "Please run "az login" to access your accounts.", but the command's returncode is 0, which I think should be a non-zero value.
To Reproduce

alvin@wechen3-u20-5:~$ az logout
There are no active accounts.
alvin@wechen3-u20-5:~$ az account show
Please run 'az login' to setup account.
alvin@wechen3-u20-5:~$ az account list
Please run "az login" to access your accounts.
[]
alvin@wechen3-u20-5:~$ echo $?
0
Expected behavior

The returncode should be a non-zero value in this case that the returncode can indicate the exception.
Environment summary

Ubuntu 20.04,
alvin@wechen3-u20-3:~/ACC-FACVM-Tooling$ az --version
azure-cli                         2.34.1
core                              2.34.1
telemetry                          1.0.6
Extensions:
mesh                              0.10.7
fdacvm                             0.1.0
ssh                                1.0.0
Dependencies:
msal                              1.16.0
azure-mgmt-resource               20.0.0
Python location '/opt/az/bin/python3'
Extensions directory '/home/alvin/.azure/cliextensions'
Development extension sources:
/home/alvin/ACC-FACVM-Tooling
Python (Linux) 3.8.12 (default, Mar  2 2022, 07:26:21)
[GCC 9.3.0]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Additional context

@jiasli for awareness

By design, list commands never return non zero exit code.
It is returning an empty list [], which is not an exception.
Please see  https://github.com/Azure/azure-cli#exit-codes for detailed explanations of the exit code design.


Modify ci_make wrapper

Generate the reproducer under any conditions
Until now, the reproducer script was generated if and only if the
"command" entry was available in the community.general.make output.
This patch allows to generate the reproducer as a plain JSON file
listing the parameters that were passed to the community.general.make
module.
Note that this should be temporary, until the collection has a new
release embedding the needed change.

Generate logs
Until now, no log were available, unless there was a failure. In this
condition, the log was "lost" in ansible logging.
This patch corrects this issue, by ensuring a proper logging file is
created with the same name as the reproducer script, in the "logs"
directory we create from the ci_setup role.

This PR has:

[x] Appropriate testing (molecule, python unit tests)
[x] Appropriate documentation (README in the role, main README is up-to-date)

/hold
weird, the end-to-end doesn't show the generated things o_O

/unhold
of course there's nothing: ci_make isn't called yet in the end-2-end test.

/hold
Need to work some more tests, just to be 100% on the safe side.

/unhold
Now we get better testing, and it actually helped correcting an issue with the way community.general.make module exposes the command output...

tested locally with logs dir
[chandankumar@fedora ci-framework]$ ansible-playbook foo.yaml
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [localhost] *************************************************************************************************************************************************************

TASK [Gathering Facts ] ******************************************************************************************************************************************************
Friday 31 March 2023  17:28:17 +0530 (0:00:00.011)       0:00:00.011 **********
ok: [localhost]

TASK [ci_make output_dir=/tmp, chdir=/home/chandankumar/Documents/code/github.com/install_yamls, target=help, dry_run=True] **************************************************
Friday 31 March 2023  17:28:21 +0530 (0:00:03.886)       0:00:03.898 **********
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ansible.plugins.action.ci_make.OutputException: /tmp/../logs doesn't exist
fatal: [localhost]: FAILED! => {"msg": "Unexpected failure during module execution: /tmp/../logs doesn't exist", "stdout": ""}

PLAY RECAP *******************************************************************************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

Friday 31 March 2023  17:28:21 +0530 (0:00:00.017)       0:00:03.916 **********
===============================================================================
Gathering Facts ------------------------------------------------------------------------------------------------------------------------------------------------------- 3.89s
ci_make --------------------------------------------------------------------------------------------------------------------------------------------------------------- 0.02s
[chandankumar@fedora ci-framework]$ cat foo.yaml
---
- hosts: localhost
  tasks:
    - ci_make:
        output_dir: "/tmp"
        chdir: "/home/chandankumar/Documents/code/github.com/install_yamls"
        target: help
        dry_run: true
[chandankumar@fedora ci-framework]$

test with log dir
[chandankumar@fedora ci-framework]$ ansible-playbook foo.yaml
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [localhost] *************************************************************************************************************************************************************

TASK [Gathering Facts ] ******************************************************************************************************************************************************
Friday 31 March 2023  17:31:01 +0530 (0:00:00.009)       0:00:00.009 **********
ok: [localhost]

TASK [ci_make output_dir=/tmp/logs, chdir=/home/chandankumar/Documents/code/github.com/install_yamls, target=help, dry_run=True] *********************************************
Friday 31 March 2023  17:31:05 +0530 (0:00:03.852)       0:00:03.862 **********
ok: [localhost]

PLAY RECAP *******************************************************************************************************************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Friday 31 March 2023  17:31:05 +0530 (0:00:00.034)       0:00:03.896 **********
===============================================================================
Gathering Facts ------------------------------------------------------------------------------------------------------------------------------------------------------- 3.85s
ci_make --------------------------------------------------------------------------------------------------------------------------------------------------------------- 0.03s
[chandankumar@fedora ci-framework]$ cat foo.yaml
---
- hosts: localhost
  tasks:
    - ci_make:
        output_dir: "/tmp/logs"
        chdir: "/home/chandankumar/Documents/code/github.com/install_yamls"
        target: help
        dry_run: true
[chandankumar@fedora ci-framework]$ cat /tmp/logs/ci_make_0_.sh
#!/bin/bash
pushd /home/chandankumar/Documents/code/github.com/install_yamls
{"chdir": "/home/chandankumar/Documents/code/github.com/install_yamls", "target": "help"}
popd

/lgtm


VSCode can't reach BCContainer (azure VM using traefik)

We use an Azure VM to host our development environment, we rely on traefik (Setup-TraefikContainerForBcContainers command, traefik image from Tobias Fenster) with the Let's Encrypt option for the SSL certificate.
Certificates issued by this platform are revoked after 90 days.
We tried a self-signed certificate but we have the same problem, unsecured connection in the browser and connection failed from VScode.
We also tried forceHTTP but we must be doing it incorrectly.
There is a way to force an HTTP connection from VScode (what would be the port and url to use in the launch.json file).
There is a way to properly use a self-signed certificate.
Thanks
Pedro
Script container creation:
$credential = New-Object pscredential 'admin', (ConvertTo-SecureString -String 'P@ssword1' -AsPlainText -Force)
New-BcContainer -accept_eula -containerName BC250W1 -artifactUrl https://bcartifacts-exdbf9fwegejdqak.b02.azurefd.net/onprem/25.0.23364.24652/w1 -assignPremiumPlan -auth NavUserPassword -Credential $credential -shortcuts None -updateHosts -PublicDnsName server.westeurope.cloudapp.azure.com -useTraefik

If you use a self-signed certificate, you can try installing that certificate on your computer under trusted certificate authorities - then it might work.
If you are using letsencrypt without traefik - there is a script called renew-letsencryptcertificate, which you can run on the Azure VM - that should work. I actually thought that traefik would renew the certificate automatically.

Thanks Freddy,
Yes, I installed my self-signed certificate on my computer, ...the problem persists.
I will try the command for certificate renewal.
Can you explain to me the use of the forceHTTP option..
Would it be possible to indicate port 80 in the launch.json file?
De : Freddy Kristiansen @.>
Envoyé : jeudi 10 octobre 2024 10:35
À : microsoft/navcontainerhelper @.>
Cc : PERERA AGUILA Pedro @.>; Author @.>
Objet : Re: [microsoft/navcontainerhelper] VSCode can't reach BCContainer (azure VM using traefik) (Issue #3716)
If you use a self-signed certificate, you can try installing that certificate on your computer under trusted certificate authorities - then it might work.
If you are using letsencrypt without traefik - there is a script called renew-letsencryptcertificate, which you can run on the Azure VM - that should work. I actually thought that traefik would renew the certificate automatically.

Reply to this email directly, view it on GitHubhttps://github.com/microsoft/navcontainerhelper/issues/3716#issuecomment-2404453989, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BFZ7PERMBZRHXRMWVBHSZRDZ2Y32BAVCNFSM6AAAAABPWG7FJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBUGQ2TGOJYHE.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

Please use the WEB UI in GitHub instead of answering emails - it is very hard to read messages sent in email to GitHub.
The command will not work on traefik VMs - might even destroy the VM.
The traefik stuff was not created by me and I really don't know the details of how it works, sorry.

On forceHTTP - I think this means that you will communicate with the traefik container using https and the traefik container will communicate with your BC container using HTTP.
You should never try to setup an Azure VM where you authenticate using HTTP,


process reset due to file size limit exceeded

when upgrading ats from 7.1.0 to 7.1.10，
the new server fail to start after old one stopped.
the new server complained "File size limit exceeded" and was terminated,
restart the server ( trafficserver restart ） solved the problem,
but i wonder why it said "File size limit exceeded",  for "ulimit -f" shows unlimited on all my machines.
following are the logs emitted from ats :
[Jun 15 14:21:10.991] Manager {0x7fb6b73d7780} NOTE: [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 25: File size limit exceeded
[Jun 15 14:21:10.991] Manager {0x7fb6b73d7780} NOTE: [Alarms::signalAlarm] Server Process was reset
[Jun 15 14:21:11.993] Manager {0x7fb6b73d7780} NOTE: Relaunching proxy after 1 sec...
[Jun 15 14:21:18.139] Manager {0x7fb6b73d7780} NOTE: [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 25: File size limit exceeded
[Jun 15 14:21:18.139] Manager {0x7fb6b73d7780} NOTE: [Alarms::signalAlarm] Server Process was reset
[Jun 15 14:21:19.141] Manager {0x7fb6b73d7780} NOTE: Relaunching proxy after 2 sec...

If this is still an issue please reopen.


Update web3.py, eth-tester

Next try at what #876 was doing.
There is still a test failure, but I'll report that upstream.

Question posted here: https://github.com/ethereum/web3.py/issues/1412


Separate replace & shift function

According to PR Request from the issue #220, I also think it's a nice idea.
Basically ripping relativedelta part out of replace() to make a new function, shift() & refactoring all related tests.

Excellent, I'll review this and get it merged.

Looks solid. Let me do some testing locally before pushing out this breaking change.

Oops, I miss something, the docs, docs/index.rst. However, docstrings are good enough, I hope.

:100: : this is a huge usability gain !

Would there be a way to make replace call shift so that it doesn't break backward compatibility?
Maybe with a deprecation warning in addition?

@pypingou That shouldn't be a problem; however, I don't know if that's the best option. Let's hear what @andrewelkins says. I could do another PR if needed although I prefer the way this is.

@sipp11 how would it not be a problem? All the calls to .replace() will suddenly stop working, that's pretty much breaking backward compatibility :)

@pypingou Sorry I might reply you too short since it should have been "That shouldn't be a problem to add deprecation warning."
For the breaking change, I'm fine either way since I've fixed them all. Code is much easier to read :)

It's easier to read and I think the change is great but breaking backward compatibility from a release to another is bad. I do think we should announce the change with a deprecation warning for a release (ideally two), then we can clean the code and get ride of .replace().

That makes sense. Can we add the deprecation warning?

Sorry that I couldn't do it sooner, but if you still need it, I restore replace functionality (to shift date) and add deprecation warning if using it. Hopefully I'll get another PR done too.

I've resolved the merge conflicts in https://github.com/crsmithdev/arrow/issues/349

Thanks @sipp11 for the original PR and @Syeberman I'll check out the new PR and close this one.


[tesseract] : arm64-osx: build failure: Expects MacOSX14.4.sdk, fails after upgrade to latest SDKs

Operating system
MacOS
Compiler
Clang
Steps to reproduce the behavior
"vcpkg install" when you have tesseract in the packages
vcpkg.json:
{
  "name": "sdo1",
  "version": "0.1",
  "dependencies": [
    "boost-thread",
    "boost-system",
    "boost-filesystem",
    "boost-asio",
    "boost-beast",
    "boost-uuid",
    "nlohmann-json",
    "json-schema-validator",
    "openssl",
    "opencv",
    "tesseract"
  ]
}
vcpkg-configuration.json:
{
  "registries": [
    {
      "kind": "artifact",
      "location": "https://github.com/microsoft/vcpkg-ce-catalog/archive/refs/heads/main.zip",
      "name": "microsoft"
    }
  ]
}

Failure logs
[main] Configuring project: sdo1
[proc] Executing command: /opt/homebrew/bin/cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=/Users/davidbien/devenv/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_INSTALL_PREFIX=/Users/davidbien/dv/sdo1/out/install/macos-debug -S/Users/davidbien/dv/sdo1 -B/Users/davidbien/dv/sdo1/out/build/macos-debug -G Ninja
[cmake] -- VCPKG-Info: CMAKE_MAP_IMPORTED_CONFIG_MINSIZEREL set to MinSizeRel;Release;None;
[cmake] -- VCPKG-Info: CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO set to RelWithDebInfo;Release;None;
[cmake] -- Running vcpkg install
[cmake] Detecting compiler hash for triplet arm64-osx...
[cmake] Compiler found: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
[cmake] The following packages will be built and installed:
[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake]   * vcpkg-boost:arm64-osx@2024-05-15
[cmake]   * vcpkg-cmake:arm64-osx@2024-04-23
[cmake]   * vcpkg-cmake-config:arm64-osx@2024-05-23
[cmake]   * vcpkg-cmake-get-vars:arm64-osx@2024-09-22
[cmake]   * vcpkg-get-python-packages:arm64-osx@2024-09-29
[cmake]   *<EMAIL_ADDRESS>[cmake]   *<EMAIL_ADDRESS>[cmake] Additional packages (*) will be modified to complete this operation.
[cmake] Restored 97 package(s) from /Users/davidbien/.cache/vcpkg/archives in 3.6 s. Use --debug to see more details.
[cmake] Installing 1/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle vcpkg-cmake-config:arm64-osx: 2.1 ms
[cmake] vcpkg-cmake-config:arm64-osx package ABI: 48c6b814bbf57aed87f093c11f0f81e40ef098a857ca8ce39b0bfda50d788cdf
[cmake] Installing 2/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle vcpkg-cmake:arm64-osx: 2.93 ms
[cmake] vcpkg-cmake:arm64-osx package ABI: deea337f26b29e93ecd37573174146fbdc5d6906b310f141b854a1ed511e48e8
[cmake] Installing 3/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle vcpkg-boost:arm64-osx: 2.5 ms
[cmake] vcpkg-boost:arm64-osx package ABI: dfa4c6b46abd65f13ce77b6640735507587807ff27e630aac0d193f3e2a597f1
[cmake] Installing 4/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-uninstall:arm64-osx: 1.59 ms
[cmake] boost-uninstall:arm64-osx package ABI: b856750cf488e46119bddab454d3206875f3c35f2c33b2da01040c3e166fe856
[cmake] Installing 5/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-cmake:arm64-osx: 4.39 ms
[cmake] boost-cmake:arm64-osx package ABI: 707e429a5ac46490043a63a549da3a3e621dd4f393e5659ed888b6c9269848cb
[cmake] Installing 6/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-headers:arm64-osx: 2.75 ms
[cmake] boost-headers:arm64-osx package ABI: e72ac1cb509f1c7720cf299e1f898fc3ec9908afabb6a00a28732255fa94e4b8
[cmake] Installing 7/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-config:arm64-osx: 73.4 ms
[cmake] boost-config:arm64-osx package ABI: c473e57dd8ef09e416577d25c202ffc25f03eef514f3530ae48c57936d43b53c
[cmake] Installing 8/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-assert:arm64-osx: 3.92 ms
[cmake] boost-assert:arm64-osx package ABI: 7abfc9c9e1c3009cf8ec3fb646fec2e10a9b25de84d24092f9f6a335a13c78ed
[cmake] Installing 9/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-throw-exception:arm64-osx: 3.19 ms
[cmake] boost-throw-exception:arm64-osx package ABI: 0ab78633e3d2afc5acad8b2361753906a790dd74d35100032ece149e01d3d7d2
[cmake] Installing 10/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-predef:arm64-osx: 45 ms
[cmake] boost-predef:arm64-osx package ABI: 6ae3f0819a827fd402b817dd97397667249d2d7b01033633b354799ac99e5642
[cmake] Installing 11/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-winapi:arm64-osx: 52.1 ms
[cmake] boost-winapi:arm64-osx package ABI: 52b258885bd91a612348e3b2f13fc36cee9d52817827c328802ded8b8d2d84e1
[cmake] Installing 12/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-mp11:arm64-osx: 12.2 ms
[cmake] boost-mp11:arm64-osx package ABI: 107c5ba0267843728b382b17547b6145b8fa288be42b8d7a77719fdd283d4db5
[cmake] Installing 13/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-variant2:arm64-osx: 3.48 ms
[cmake] boost-variant2:arm64-osx package ABI: 0d43381e091b3e345edc87680a47da6a116c80120c02ac0887279021b015acd6
[cmake] Installing 14/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-system:arm64-osx: 14.5 ms
[cmake] boost-system:arm64-osx package ABI: e46432aac66e42ea6f4163b492b6bcc85da96d48447efb016ce1c71d8e643904
[cmake] Installing 15/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-static-assert:arm64-osx: 3.94 ms
[cmake] boost-static-assert:arm64-osx package ABI: 880609bf8b6287e423ac27bb434f66ca284f35d2729588713d9cfe86261268c1
[cmake] Installing 16/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-type-traits:arm64-osx: 57 ms
[cmake] boost-type-traits:arm64-osx package ABI: 07679168bc51d63e76a744edd340fcf8ef2fabfb820099e7652c72d75a6b278c
[cmake] Installing 17/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-preprocessor:arm64-osx: 138 ms
[cmake] boost-preprocessor:arm64-osx package ABI: 121f03baee3a4369bc598b7a28cfcc8a1289307794ec9ff53183e9e47c8eebd8
[cmake] Installing 18/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-io:arm64-osx: 6.22 ms
[cmake] boost-io:arm64-osx package ABI: ab1db019b4972ac93d6c1a2320c391860cd66bafd7e1154b3051dcb2512f9841
[cmake] Installing 19/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-core:arm64-osx: 23 ms
[cmake] boost-core:arm64-osx package ABI: 02f783c4c025a292a3689abbc52a63bd6f0a6cfea6ed890dc53ac174a7d3be99
[cmake] Installing 20/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-utility:arm64-osx: 25.6 ms
[cmake] boost-utility:arm64-osx package ABI: 035c37e9cb32704884f94eae8c4a09b4ee4c0e8adcc5083cd6821f44d0e6fc48
[cmake] Installing 21/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-move:arm64-osx: 17.4 ms
[cmake] boost-move:arm64-osx package ABI: fa9c64b22d32ded7072dc7cd90b90996c0792212c710a0ef18a5052cea4967f6
[cmake] Installing 22/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-smart-ptr:arm64-osx: 31.7 ms
[cmake] boost-smart-ptr:arm64-osx package ABI: 7c6846cfe73271e82cde6981da7f7860d53ad7edc86136c5dfbe4c391a0bf212
[cmake] Installing 23/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-detail:arm64-osx: 10.4 ms
[cmake] boost-detail:arm64-osx package ABI: 09ce3f391fb79135eb7e339ab55d5a12c68d35ad15652638fa11abc176ddc76e
[cmake] Installing 24/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-optional:arm64-osx: 8.41 ms
[cmake] boost-optional:arm64-osx package ABI: a479bcf34a7c113caf609703f9664534f12548f54db116c6ed33e0938135c0dc
[cmake] Installing 25/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-mpl:arm64-osx: 309 ms
[cmake] boost-mpl:arm64-osx package ABI: c4cef83209080495c068a232ed642370284f19a6ea6558d45cb36f756795953b
[cmake] Installing 26/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-typeof:arm64-osx: 11.5 ms
[cmake] boost-typeof:arm64-osx package ABI: b741b10db08f0882b4f7d0be75f1884dac8205452f979c0dc1749fad338135ad
[cmake] Installing 27/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-tuple:arm64-osx: 5.45 ms
[cmake] boost-tuple:arm64-osx package ABI: cd1619a1971553f0fb4ce17cc4d90c833ba9eedd05b991a2cd8f1425b824d702
[cmake] Installing 28/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-function-types:arm64-osx: 39.6 ms
[cmake] boost-function-types:arm64-osx package ABI: 1cfd3ac6dea270197790f446757c1416fcdcc903c5d463cd8b5f734c4b266e03
[cmake] Installing 29/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-bind:arm64-osx: 10.2 ms
[cmake] boost-bind:arm64-osx package ABI: fb31e71e03a75c9ee8232e9c6c8e70e360f2a579765dedbc2297be236c891d9a
[cmake] Installing 30/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-function:arm64-osx: 9.66 ms
[cmake] boost-function:arm64-osx package ABI: ddb5712f34f29e1fa262d54326154d27d33ddd8a2162bd12eb3af4906f6b79a5
[cmake] Installing 31/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-functional:arm64-osx: 8.38 ms
[cmake] boost-functional:arm64-osx package ABI: a540b196e294b94e1e9061eeb562ef1982a545e32720fda25f0efec66bd9beaf
[cmake] Installing 32/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-describe:arm64-osx: 10.6 ms
[cmake] boost-describe:arm64-osx package ABI: 6c76f28545c35124aa1aa2034739323695a0eb33f84570dba3b4d52f493590b8
[cmake] Installing 33/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-container-hash:arm64-osx: 10.7 ms
[cmake] boost-container-hash:arm64-osx package ABI: d1154271d52390c73070def6fcb62e20fdceef9a96ce2c980e5ac8858f3a2c03
[cmake] Installing 34/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-fusion:arm64-osx: 330 ms
[cmake] boost-fusion:arm64-osx package ABI: 78826c2589d1531280b30602ec54d6d72fe9e2862c628a89b78e0572f0a0fe1d
[cmake] Installing 35/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-concept-check:arm64-osx: 14.3 ms
[cmake] boost-concept-check:arm64-osx package ABI: 18742ed7577d383211661fa263caa8b36213c5c2da0c177a644147f625c04edc
[cmake] Installing 36/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-iterator:arm64-osx: 27.8 ms
[cmake] boost-iterator:arm64-osx package ABI: 307afa76173e85f3a0a46cc0fb2d3c19247d3ed4571a6813ed3a307842751326
[cmake] Installing 37/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-tokenizer:arm64-osx: 5.12 ms
[cmake] boost-tokenizer:arm64-osx package ABI: 246ccfd11c19922c3a7e0d1ab22d0ac5fd24b7fa4938ee2ff5472c21068c2d53
[cmake] Installing 38/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-integer:arm64-osx: 9.66 ms
[cmake] boost-integer:arm64-osx package ABI: 516876d379aa4355d7100a13c5b7d343011305302c2aa01c3662dfd256b38877
[cmake] Installing 39/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-regex:arm64-osx: 36.5 ms
[cmake] boost-regex:arm64-osx package ABI: a0c676f2f0085c4965e4ba9c49c1057760496e46df64be68aa3657b92e49b1f3
[cmake] Installing 40/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-conversion:arm64-osx: 5.23 ms
[cmake] boost-conversion:arm64-osx package ABI: d30f4dfe0c12bf585bfc50cc2819f17af76c8d097985b285a66409fd264528b4
[cmake] Installing 41/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-array:arm64-osx: 6.91 ms
[cmake] boost-array:arm64-osx package ABI: 24ed4ea087ff1fe94fa88b54ac63bb3dd14d3207b9d643c20d3555434d8b9153
[cmake] Installing 42/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-range:arm64-osx: 49.2 ms
[cmake] boost-range:arm64-osx package ABI: 8a1f1f9d555b4b320181b4d7599b40a89670f403b8946a09413d680b9a5333d0
[cmake] Installing 43/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-numeric-conversion:arm64-osx: 11.4 ms
[cmake] boost-numeric-conversion:arm64-osx package ABI: 4f89ba4bb7eee1f4a9bbfebeebb5769cad5d9a4c3d2a181c82d23b8705145a00
[cmake] Installing 44/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-intrusive:arm64-osx: 49.3 ms
[cmake] boost-intrusive:arm64-osx package ABI: 2bdc7df0e1dc0b770ae5afbc48618bf1ea0369f22cb250b09e0d4594aa9fc2ea
[cmake] Installing 45/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-container:arm64-osx: 35.4 ms
[cmake] boost-container:arm64-osx package ABI: 0adcbe82225857f954d9c03b861dcc2ebcf01f6ff3d9ba313a218c256b985507
[cmake] Installing 46/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-lexical-cast:arm64-osx: 9.53 ms
[cmake] boost-lexical-cast:arm64-osx package ABI: ec6f257cac3fc2facc8bbb913a5d5072a3001faec8d358f3cf9fba9c1e3203cb
[cmake] Installing 47/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-unordered:arm64-osx: 21 ms
[cmake] boost-unordered:arm64-osx package ABI: b9b20d669fd665e1ed606cd8e0221f89b1a617d9e55e2f4fc43e5774c8cf41a4
[cmake] Installing 48/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-exception:arm64-osx: 12.2 ms
[cmake] boost-exception:arm64-osx package ABI: 5567a61895aa492bf3d650129130205618a648474c7c00330a55456c3e123085
[cmake] Installing 49/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-algorithm:arm64-osx: 31.1 ms
[cmake] boost-algorithm:arm64-osx package ABI: ecb398f0d77e102c8eedb231e9372768c085943d3fdbec4ef5098b28a00ee41a
[cmake] Installing 50/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-date-time:arm64-osx: 34.9 ms
[cmake] boost-date-time:arm64-osx package ABI: 5e429f540d19116e5806ad9dd0947b3755655ef04c5f75ff3e65dab168c047b7
[cmake] Installing 51/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-pool:arm64-osx: 9.27 ms
[cmake] boost-pool:arm64-osx package ABI: b72920ebbe4e200a3c15d353cffa0ac696a7f2c7b0531868fc46f40b4e8d3e19
[cmake] Installing 52/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-context:arm64-osx: 30 ms
[cmake] boost-context:arm64-osx package ABI: ccce70bcabcc2202a3fb6e63b739b163d2f521b2046a6a10489f4c7ab4febcca
[cmake] Installing 53/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-coroutine:arm64-osx: 19.8 ms
[cmake] boost-coroutine:arm64-osx package ABI: e87b2c5e41f5f8c49b80d2ae99f380bc093e1232b2137150213b285a94f399d1
[cmake] Installing 54/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-align:arm64-osx: 21.4 ms
[cmake] boost-align:arm64-osx package ABI: 7f22579e7b62b938f6e677a305abe68619f4ea5a9f825f0beabbc785bf0551da
[cmake] Installing 55/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-asio:arm64-osx: 201 ms
[cmake] boost-asio:arm64-osx package ABI: 4dbb335a8796cc1fb33e2a23583d23bba42d1855881f5cdb35af9c8db502d10c
[cmake] Installing 56/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-type-index:arm64-osx: 10.4 ms
[cmake] boost-type-index:arm64-osx package ABI: 2f0e8016957fbb3d9b24f8f1692ab2f8c0bfcbbad32722d9842972c8365f2b73
[cmake] Installing 57/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-static-string:arm64-osx: 6.1 ms
[cmake] boost-static-string:arm64-osx package ABI: 647269acb25f6de71292832d13d0b9945d3ddac2b77efad47fd1ea9865441577
[cmake] Installing 58/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-logic:arm64-osx: 6.33 ms
[cmake] boost-logic:arm64-osx package ABI: 4c58dd9f16afe91ac6470c229804e29ca25652c626b8a6c1b2c5ef7b229abd78
[cmake] Installing 59/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-endian:arm64-osx: 19.2 ms
[cmake] boost-endian:arm64-osx package ABI: 8df1ed9b9523a1387b92a5006bc5f277896cfa83881f0cc10019229f9cfad607
[cmake] Installing 60/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-beast:arm64-osx: 91.3 ms
[cmake] boost-beast:arm64-osx package ABI: b24b198edb2c077fb8a6a9a7c0b678613f1dcdaa5547192745e89dbb8045f219
[cmake] Installing 61/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-scope:arm64-osx: 13.5 ms
[cmake] boost-scope:arm64-osx package ABI: fef96df8f5ce57156df1fefb8a8550d0c9f6adbfa49ea08158936ecd9cc2e0ee
[cmake] Installing 62/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-atomic:arm64-osx: 47.5 ms
[cmake] boost-atomic:arm64-osx package ABI: 6d7d62d61fa6c7a5ab780ad3e2da76e47536f3e54a588168bdb801995a0384cd
[cmake] Installing 63/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-filesystem:arm64-osx: 10.7 ms
[cmake] boost-filesystem:arm64-osx package ABI: 6cdf283297be7b2f9cb9ce99b81b5f38be57a1dfcb11c570dc5058d096e68c07
[cmake] Installing 64/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-ratio:arm64-osx: 8.61 ms
[cmake] boost-ratio:arm64-osx package ABI: edba3ef438e703c37b7d76236710895210d98759a0040bd890bd347706bef595
[cmake] Installing 65/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-chrono:arm64-osx: 22.3 ms
[cmake] boost-chrono:arm64-osx package ABI: 84b22adf8620b2216613f88da4e14ed9180c2b673cfcf938e7939d16cba5ce16
[cmake] Installing 66/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-thread:arm64-osx: 55.4 ms
[cmake] boost-thread:arm64-osx package ABI: 6d906c9bf0c1423c5f35b623c5bdd3e9cfd9bbe0d4304c000bffb65421e01a95
[cmake] Installing 67/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle boost-uuid:arm64-osx: 29.3 ms
[cmake] boost-uuid:arm64-osx package ABI: 38ad74951b0602aa6ad8b538e1ac1518b9f89c7c1c178bccdeab5fde46de31fc
[cmake] Installing 68/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle nlohmann-json:arm64-osx: 22.7 ms
[cmake] nlohmann-json:arm64-osx package ABI: d321d3a6216ac98ad5d3c64d98f487d3cddb76f1d126b00bf557fd9cb09729c0
[cmake] Installing 69/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle json-schema-validator:arm64-osx: 7.46 ms
[cmake] json-schema-validator:arm64-osx package ABI: 63ae70711de462ca7c5433c6f9cacfceddadd81a90ca57f6233c6d8932ca6dbe
[cmake] Installing 70/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle libwebp:arm64-osx: 14.1 ms
[cmake] libwebp:arm64-osx package ABI: 052d418bf6a9be6dd0a236c0cf63ba9cfec52461c15be87f0327fb78cf8dd430
[cmake] Installing 71/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle zlib:arm64-osx: 8.33 ms
[cmake] zlib:arm64-osx package ABI: ef300598acbd33c863502fd74b2e53b5cfdc7fdb4571f43c3593fce2e810259a
[cmake] Installing 72/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle liblzma:arm64-osx: 17.8 ms
[cmake] liblzma:arm64-osx package ABI: 9082623a12ef91f4338ff4693473e5b9f561437d1c12b173176e8c6b5bdd243c
[cmake] Installing 73/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle libjpeg-turbo:arm64-osx: 12.2 ms
[cmake] libjpeg-turbo:arm64-osx package ABI: 35fbb900aff42dda782a8863831473a38c708451ccb8bc9a22c2866cb53561da
[cmake] Installing 74/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle tiff:arm64-osx: 9.18 ms
[cmake] tiff:arm64-osx package ABI: 9ec43d7f14725659a4e5bffb2f9ca5dcc6aadef758d490187b134f58525b7403
[cmake] Installing 75/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle quirc:arm64-osx: 15.2 ms
[cmake] quirc:arm64-osx package ABI: 0e0ee0d1201d1f6425a7c6cd588ee7638b8e00f7e98351ef6243d6033a29a8b9
[cmake] Installing 76/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle libpng:arm64-osx: 28 ms
[cmake] libpng:arm64-osx package ABI: aa81240cbbc83f3e275be8aa0d4221af84976892c2894cb4a1ca265ed66ed33e
[cmake] Installing 77/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle abseil:arm64-osx: 279 ms
[cmake] abseil:arm64-osx package ABI: 1f266d4f57c773651513626751fa43316bc9a3df761a55b446cab950167a2141
[cmake] Installing 78/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle utf8-range:arm64-osx: 10.7 ms
[cmake] utf8-range:arm64-osx package ABI: 2d17833edd7dbf6ac6a430f8d2ebe1913ee01b20f4459ecfda1ab02461f9ff7f
[cmake] Installing 79/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle protobuf:arm64-osx: 86.9 ms
[cmake] protobuf:arm64-osx package ABI: 248edae86026c9fef57f125043b7e393cc795edbacd0b46dbc91d24ac2e96530
[cmake] Installing 80/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle flatbuffers:arm64-osx: 19.4 ms
[cmake] flatbuffers:arm64-osx package ABI: e5558d9f3be069e581c764045e858d82ce374079eef926f1ff7f3d8bb75f6794
[cmake] Installing 81/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle vcpkg-get-python-packages:arm64-osx: 6.5 ms
[cmake] vcpkg-get-python-packages:arm64-osx package ABI: 9c4f8e6333f55a25ca4a8e11ff2a42e73ea8253f22566a3147b0659c8f7ac389
[cmake] Installing 82/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle opencv4:arm64-osx: 154 ms
[cmake] opencv4:arm64-osx package ABI: f7d547173ab2e8859568f2b9063c4b2437597f9110528d107f1791bbeae825d7
[cmake] Installing 83/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle opencv:arm64-osx: 6.6 ms
[cmake] opencv:arm64-osx package ABI: d74aefd9b0c08c5cc96a836dc4b14e8d86c1f363d7bca4d03bdb67668eb7e6f3
[cmake] Installing 84/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle vcpkg-cmake-get-vars:arm64-osx: 7.44 ms
[cmake] vcpkg-cmake-get-vars:arm64-osx package ABI: b1f55fd29a6807149cab654c744d40dc1a89b38f6d94469acf3e2f49e6305b1d
[cmake] Installing 85/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle openssl:arm64-osx: 84.8 ms
[cmake] openssl:arm64-osx package ABI: 6e6027b5c7d46e072d632ad2ff97bd874a818ff8bf8985944001a5fc63e256a2
[cmake] Installing 86/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle zstd:arm64-osx: 9.95 ms
[cmake] zstd:arm64-osx package ABI: f39455c9a1ba25d659cbabb25087b80cae90d2d2ec49443d211b0192d86930b5
[cmake] Installing 87/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle lz4:arm64-osx: 11 ms
[cmake] lz4:arm64-osx package ABI: 592f3d7e192054f8370c45053667b81ab211215b87c07f5d50ab011f9a4970d8
[cmake] Installing 88/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle libiconv:arm64-osx: 6.75 ms
[cmake] libiconv:arm64-osx package ABI: 91e9a4b2e6616038b42b037ad47b79a0a6e0dda687cb427eab783105746bea27
[cmake] Installing 89/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle libxml2:arm64-osx: 38.3 ms
[cmake] libxml2:arm64-osx package ABI: fb67196e5ea70048f2b0858811b72c13c27acec2910cfb82721fb302c2a2caa4
[cmake] Installing 90/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle mbedtls:arm64-osx: 46.2 ms
[cmake] mbedtls:arm64-osx package ABI: dc2f918beecbb1450dd5fbf01fa77097eac3bab237481baecc2de6da33b8e418
[cmake] Installing 91/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle bzip2:arm64-osx: 9.93 ms
[cmake] bzip2:arm64-osx package ABI: 1c032f1e4be936bad8c25c30478f912d43985c0e86ff47aee56ef4f06a5e672f
[cmake] Installing 92/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle libarchive:arm64-osx: 11.3 ms
[cmake] libarchive:arm64-osx package ABI: f38b0c6df7b92a2e812ae09cdf963f64e71e01211d86b2012b70fb7f9df95811
[cmake] Installing 93/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle openjpeg:arm64-osx: 13.4 ms
[cmake] openjpeg:arm64-osx package ABI: 8894e5e21df84d7049ca698138f9d7a6d584cd23334c0ef1275782c29a5b08a8
[cmake] Installing 94/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle giflib:arm64-osx: 22.2 ms
[cmake] giflib:arm64-osx package ABI: 27c3c6a7b90819b5077f20aeafa5801b5c3d2295c19fda1aca1dd7f7aa9b1527
[cmake] Installing 95/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle leptonica:arm64-osx: 21.8 ms
[cmake] leptonica:arm64-osx package ABI: 6167f870f71a899ca59f266760b9f90f312591d55f0a8b9196f058c619d342c8
[cmake] Installing 96/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle curl:arm64-osx: 15.5 ms
[cmake] curl:arm64-osx package ABI: b2e8d3aac9da1c3d5b52faa6eac1a70ed543874fd595258e8acfbf022a1fa181
[cmake] Installing 97/97<EMAIL_ADDRESS>[cmake] Elapsed time to handle tesseract:arm64-osx: 76.6 ms
[cmake] tesseract:arm64-osx package ABI: fffb240cdd4834c2f2dcacb11e81d02ed32871dd5ff4608e0f7d1795c6b10352
[cmake] Total install time: 3.3 s
[cmake] boost-system provides CMake targets:
[cmake]
[cmake]   # this is heuristically generated, and may not be correct
[cmake]   find_package(boost_system CONFIG REQUIRED)
[cmake]   target_link_libraries(main PRIVATE Boost::system)
[cmake]
[cmake] boost-asio provides CMake targets:
[cmake]
[cmake]   # this is heuristically generated, and may not be correct
[cmake]   find_package(boost_asio CONFIG REQUIRED)
[cmake]   target_link_libraries(main PRIVATE Boost::asio)
[cmake]
[cmake] boost-beast provides CMake targets:
[cmake]
[cmake]   # this is heuristically generated, and may not be correct
[cmake]   find_package(boost_beast CONFIG REQUIRED)
[cmake]   target_link_libraries(main PRIVATE Boost::beast)
[cmake]
[cmake] boost-filesystem provides CMake targets:
[cmake]
[cmake]   # this is heuristically generated, and may not be correct
[cmake]   find_package(boost_filesystem CONFIG REQUIRED)
[cmake]   target_link_libraries(main PRIVATE Boost::filesystem)
[cmake]
[cmake] boost-thread provides CMake targets:
[cmake]
[cmake]   # this is heuristically generated, and may not be correct
[cmake]   find_package(boost_thread CONFIG REQUIRED)
[cmake]   target_link_libraries(main PRIVATE Boost::thread)
[cmake]
[cmake] boost-uuid provides CMake targets:
[cmake]
[cmake]   # this is heuristically generated, and may not be correct
[cmake]   find_package(boost_uuid CONFIG REQUIRED)
[cmake]   target_link_libraries(main PRIVATE Boost::uuid)
[cmake]
[cmake] The package nlohmann-json provides CMake targets:
[cmake]
[cmake]     find_package(nlohmann_json CONFIG REQUIRED)
[cmake]     target_link_libraries(main PRIVATE nlohmann_json::nlohmann_json)
[cmake]
[cmake] The package nlohmann-json can be configured to not provide implicit conversions via a custom triplet file:
[cmake]
[cmake]     set(nlohmann-json_IMPLICIT_CONVERSIONS OFF)
[cmake]
[cmake] For more information, see the docs here:
[cmake]
[cmake]     https://json.nlohmann.me/api/macros/json_use_implicit_conversions/
[cmake]
[cmake] json-schema-validator provides CMake targets:
[cmake]
[cmake]   # this is heuristically generated, and may not be correct
[cmake]   find_package(nlohmann_json_schema_validator CONFIG REQUIRED)
[cmake]   target_link_libraries(main PRIVATE nlohmann_json_schema_validator::validator)
[cmake]
[cmake] openssl is compatible with built-in CMake targets:
[cmake]
[cmake]   find_package(OpenSSL REQUIRED)
[cmake]   target_link_libraries(main PRIVATE OpenSSL::SSL)
[cmake]   target_link_libraries(main PRIVATE OpenSSL::Crypto)
[cmake]
[cmake] tesseract provides CMake targets:
[cmake]
[cmake]   # this is heuristically generated, and may not be correct
[cmake]   find_package(Tesseract CONFIG REQUIRED)
[cmake]   target_link_libraries(main PRIVATE Tesseract::libtesseract)
[cmake]
[cmake] tesseract provides pkg-config modules:
[cmake]
[cmake]   # An OCR Engine that was developed at HP Labs (1985-1995) and Google (2006-2018).
[cmake]   tesseract
[cmake]
[cmake] -- Running vcpkg install - done
[cmake] Compiling under MacOS
[cmake] Google Test version: v1.14.0
[cmake] -- Found ZLIB: optimized;/Users/davidbien/dv/sdo1/out/build/macos-debug/vcpkg_installed/arm64-osx/lib/libz.a;debug;/Users/davidbien/dv/sdo1/out/build/macos-debug/vcpkg_installed/arm64-osx/debug/lib/libz.a (found suitable version "1.3.1", minimum required is "1")
[cmake] -- Found ZLIB: optimized;/Users/davidbien/dv/sdo1/out/build/macos-debug/vcpkg_installed/arm64-osx/lib/libz.a;debug;/Users/davidbien/dv/sdo1/out/build/macos-debug/vcpkg_installed/arm64-osx/debug/lib/libz.a (found version "1.3.1")
[cmake] -- Website URL:
[cmake] Unit test: test1
[cmake] Unit test: test2
[cmake] Unit test: test3
[cmake] -- Configuring done (11.0s)
[cmake] CMake Error in CMakeLists.txt:
[cmake]   Imported target "Tesseract::libtesseract" includes non-existent path
[cmake]
[cmake]     "/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include"
[cmake]
[cmake]   in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:
[cmake]
[cmake]   * The path was deleted, renamed, or moved to another location.
[cmake]
[cmake]   * An install or uninstall procedure did not complete successfully.
[cmake]
[cmake]   * The installation package was faulty and references files it does not
[cmake]   provide.
[cmake]
[cmake]
[cmake]
[cmake] CMake Error in CMakeLists.txt:
[cmake]   Imported target "Tesseract::libtesseract" includes non-existent path
[cmake]
[cmake]     "/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include"
[cmake]
[cmake]   in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:
[cmake]
[cmake]   * The path was deleted, renamed, or moved to another location.
[cmake]
[cmake]   * An install or uninstall procedure did not complete successfully.
[cmake]
[cmake]   * The installation package was faulty and references files it does not
[cmake]   provide.
[cmake]
[cmake]
[cmake]
[cmake] CMake Error in CMakeLists.txt:
[cmake]   Imported target "Tesseract::libtesseract" includes non-existent path
[cmake]
[cmake]     "/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include"
[cmake]
[cmake]   in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:
[cmake]
[cmake]   * The path was deleted, renamed, or moved to another location.
[cmake]
[cmake]   * An install or uninstall procedure did not complete successfully.
[cmake]
[cmake]   * The installation package was faulty and references files it does not
[cmake]   provide.
[cmake]
[cmake]
[cmake]
[cmake] CMake Error in CMakeLists.txt:
[cmake]   Imported target "Tesseract::libtesseract" includes non-existent path
[cmake]
[cmake]     "/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/usr/include"
[cmake]
[cmake]   in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:
[cmake]
[cmake]   * The path was deleted, renamed, or moved to another location.
[cmake]
[cmake]   * An install or uninstall procedure did not complete successfully.
[cmake]
[cmake]   * The installation package was faulty and references files it does not
[cmake]   provide.
[cmake]
[cmake]
[cmake]
[cmake] -- Generating done (0.1s)
[cmake] CMake Generate step failed.  Build files cannot be regenerated correctly.
[proc] The command: /opt/homebrew/bin/cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=/Users/davidbien/devenv/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_INSTALL_PREFIX=/Users/davidbien/dv/sdo1/out/install/macos-debug -S/Users/davidbien/dv/sdo1 -B/Users/davidbien/dv/sdo1/out/build/macos-debug -G Ninja exited with code: 1
Additional context
No response

Questions: (1) Why does it build under some triplets and merely install under others? (2) Can I somehow force the build for installs that aren't working?
BTW: it is awesome that tesseract is building under iOS again - that was also broken for a while.
[cmake] Building<EMAIL_ADDRESS>[cmake] /Users/davidbien/devenv/vcpkg/triplets/community/arm64-ios-simulator.cmake: info: loaded community triplet from here. Community triplets are not built in the curated registry and are thus less likely to succeed.
[cmake] -- Using cached tesseract-ocr-tesseract-5.5.0.tar.gz.
[cmake] -- Extracting source /Users/davidbien/devenv/vcpkg/downloads/tesseract-ocr-tesseract-5.5.0.tar.gz
[cmake] -- Applying patch fix_static_link_icu.patch
[cmake] -- Applying patch fix-link-include-path.patch
[cmake] -- Applying patch target-curl.diff
[cmake] -- Using source at /Users/davidbien/devenv/vcpkg/buildtrees/tesseract/src/5.5.0-726910878f.clean
[cmake] -- Configuring arm64-ios-simulator
[cmake] -- Building arm64-ios-simulator-dbg
[cmake] -- Building arm64-ios-simulator-rel

Maybe vcpkg doesn't take the MacOSX SDK as a flag to determine if the binary cache is up to date.
You may need to remove all the binary caches in your local machine and try again.

Maybe vcpkg doesn't take the MacOSX SDK as a flag to determine if the binary cache is up to date.

Having the SDK path in exported CMake config is a port bug.


Deprecate Slim 3 style callables in Slim 4

We haven't been able to type hint any callables throughout the codebase because we still support the callable format used in Slim 3:
https://github.com/slimphp/Slim/blob/4.x/Slim/CallableResolver.php#L59 which is equivalent to a string formatted like so: Class:method
This just seems like synthax sugar to me which doesn't positively outweigh the benefits of typehinting. I'm not sure exactly as I didn't implement them but I'm definitely open to feedback from the community if anyone feels there's still a need for them.
My main reasons for wanting to deprecate them as of Slim 4 is so we can type hint callables everywhere in the codebase as well as there are already enough methods in my opinion to declare a callable:

Foo::class works when __invoke() is implemented
my_callback_function global function name
function () {...} anonymous functions
['Class', 'method'] an array with the class name and method
[$object, 'method'] an array with an instantiated object and method name

Im general, I'm in favour of controller:action as it's a clean way to define an action method in a lazily instantiated class.
I'm open to alternatives as long as they are easy for write in the routes.php file.

We have to make a hard choice here @akrabat as we were discussing internally yesterday. This is the main question that arose from our conversation:
How do you deprecate Class:method strings for route handlers and force the callable typehint in our function signatures without removing the functionality entirely and keeping the synthax short?
We need the following characteristics to the changed behavior:

Ability to lazy load route handlers
Ability to instantiate the object via a DIC and call a specific method of the instantiated object
Or ability to instantiate and pass container into the constructor, then call a specific method of the instantiated object

Problems:
A valid callable type only works for statically called methods Class::staticMethod, ['Class', 'staticMethod'], anonymous functions or methods on an already instantiated object [$object, 'method']
One way it could be done:
Create a short named function which is bound to callable resolver. It could be obtained via an instantiation of App:

class App {
    ...
    /**
     * This function returns a generator function that returns an anonymous function
     * bound to CallableResolver that returns the result of resolved callable when executed
     */
    public function getDeferredResolverGenerator(): Closure
    {
        return (function ($callable) {
            return (function () use ($callable) {
                $args = func_get_args();
                $resolved = $this->resolve($callable);
                return $resolved(...$args);
            })->bindTo($this);
        })->bindTo($this->callableResolver);
    }
}

$g = $app->getDeferredResolverGenerator();

$app->get('/hello', $g('Class:Method'));

To my mind, I'd rather it was cleaner for the user and having a weird function isn't it when this "just works" in Laravel, Symfony, etc.
Maybe have a set of sibling methods that are type-hinted for users who care?

Besides strict type hinting I suppose I don't see any other upside to removing this.

Is it possible to use a Callable in Slim 4, like [Some::class, 'action']?
Concatenating is a bit ugly. 🙂

Hi @glen-84
Of course, why not? Callables are supported (even closures).

@adriansuter My apologies, I was reading this section of the documentation, and didn't realize that I had missed the earlier section on route callbacks. 🤦♂


require() of ES Module node_modules\string-width\index.js from node_modules\wide-align\align.js not supported

Environment
Stackblitz environment and local

Operating System: Windows_NT
Node Version:     v16.17.0
Nuxt Version:     3.5.2
Nitro Version:    2.4.1
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:     -
Runtime Modules: -
Build Modules:    -

Reproduction
https://stackblitz.com/edit/github-e7ro7z?file=README.md
Describe the bug
Nuxt can't seem to work due to a dependency.
❯ yarn why wide-align
yarn why v1.22.19
[1/4] 🤔  Why do we have the module "wide-align"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found<EMAIL_ADDRESS>info Reasons this module exists
   - "nuxt#nitropack#@vercel#nft#@mapbox#node-pre-gyp#npmlog#gauge" depends on it
   - Hoisted from "nuxt#nitropack#@vercel#nft#@mapbox#node-pre-gyp#npmlog#gauge#wide-align"
info Disk size without dependencies: "16KB"
info Disk size with unique dependencies: "188KB"
info Disk size with transitive dependencies: "344KB"
info Number of shared dependencies: 4
✨  Done in 0.80s.

Now I refresh the lock-file multiple times. Take the Stackblitz - I refresh the lockfile there, and it works, but then I copy that lockfile locally and the issue persists there, while I refresh locally (and small chances it doesn't help) and copy to Stackblitz, then the container fails.
Additional context
No response
Logs
No response

The issue here seems to be caused by your package manager. See the following logs from the stackblitz:

The actual version of string-width installed by yarn is v5 which seems to be incompatible with wide-align.
I'm afraid this isn't a Nuxt issue we can resolve.

@danielroe, any ideas on how to ensure we can use an older version of string-width? I tried yarn clear cache, deleting all node_modules, lockfiles and manually setting version "^4.2.3" of string-width as a dependency, but all of this seems to fail unfortunately

You can use yarn resolutions.

I can confirm that adding the following to package.json will resolve the issue:
"resolutions": {
    "string-width": "4.2.3"
 }

I have the same error. For me yarn resolutions not working :/
Without resolutions:
$ yarn
yarn install v1.22.19
[1/4] Resolving packages...
warning Lockfile has incorrect entry for<EMAIL_ADDRESS>Ignoring it.
warning Lockfile has incorrect entry for<EMAIL_ADDRESS>Ignoring it.
warning Lockfile has incorrect entry for<EMAIL_ADDRESS>Ignoring it.

When I have "string-with": "2.2.3":
$ yarn
yarn install v1.22.19
[1/4] Resolving packages...
warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>
When I have "string-with": "2.2.3":
$ yarn
yarn install v1.22.19
[1/4] Resolving packages...
warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>|| 2 || 3 || 4"
warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>warning Resolution field<EMAIL_ADDRESS>is incompatible with requested version<EMAIL_ADDRESS>
I still have this error and can't start my project 😥

Is this an actual ischia? Is there a solution to the problems? This applies not only with nuxt, unfortunately. And also nest js, with the nest-modules/mailer library.😥

Is this an actual issues? Is there a solution to the problems? This applies not only with nuxt, unfortunately. And also nest js, with the nest-modules/mailer library.😥
I solved it by removing yarn-lock file and node modules firstly but later i got the same issue during deployment then
I solved the issue by changing my package manager to npm from yarn .now i am able to deploy my site without any issue. I hope this works for you too.

+1 for struggling with this error

+1, still happening, although using the resolution, removing the yarn.lock and node_modules folder, it worked, even though it warned against an incompatibility between requested versions.
wide-align, which is used by npmlog, which is used by vite, eventually, forces the use of string-width<5, which from what I understand, was a dependency that yarn failed to comply with, causing the error.
from wide-align package.json:
"//": "But not version 5 of string-width, as that's ESM only",
  "dependencies": {
    "string-width": "^1.0.2 || 2 || 3 || 4"

Again, using the resolutions seems to be working, as long as you don't have a breaking dependency with the string-width ^5, it should be fine, but it can be really annoying. Wide-align has been inactive for over 2 years now, I doubt we will have a fix from them anytime soon. I might make  a PR later to fix it

1.Add this code inside package.json:
"resolutions": {
    "jackspeak": "2.1.1"
 }

Remove node_modules folder and yarn.lock package.lock files.
Run npm/yarn install.

Worked for me :)

Still an issue for us

rm -rf node_modules
rm -rf yarn.lock
yarn
yarn dev

I have clean new install of nuxt.. added testing setup by following installation from docs here. Hit the error right away.
tried solution:
"resolutions": {
    "string-width": "4.2.3"
 }

but it hits next module... and I don't like the solution I would expect basic setup to work without hacks :/
Reproduced here: https://stackblitz.com/edit/nuxt-examples-g9ej3w?file=package.json
Thnks for any further hints 👍

Any fix yet? This has killed multiple projects of mine when trying to deploy to azure static web apps. Can use locally but deploying is the problem!!

If you're still encountering this, you should be aware that this is a bug in yarn. See https://github.com/search?q=strip-ansi+string-width&type=issues.
This comment explains the issue and provides a workaround.

I also had the same issue with nuxt.js I suggest to change the package manager from yarn to npm. Remove node_modules and yarn-lock then npm install . It worked for me.

If it helps anyone encountering a similar error, when attempting to reproduce this issue, I was seeing a very odd error in code sandbox. When setting up a nuxt repo from scratch locally, everything worked fine for me (nuxt v3.10.0, @nuxt/image v1.3.0 at time of writing this).

The solution is to change the yarn version.
corepack enable
yarn set version berry
yarn install

Deleting node_modules and reinstalling worked for me.

After deleting node_modules and yarn.lock and then running yarn again to download node_modules, the error was gone. It worked very well 🎉.

In my case instead of yarn install override with pnpm install on vercel's deployment made it work.
Using<EMAIL_ADDRESS>

I deleted node_modules and yarn-lock, then installed everything again with npm.
In Vercel, I override the command for install to npm i
This solved my problem

I came to confirm here. The below steps can resolve the issue.
Add this to package.json.
"resolutions": {
    "string-width": "4.2.3"
 }

And then run these commands.
rm -rf node_modules
rm -rf yarn.lock
yarn cache clean
yarn install

Problem solved 💕.

How many of the people recommending the deletion of yarn.lock actually work with production application? 🤣 🤣

If you're still encountering this, you should be aware that this is a bug in yarn. See https://github.com/search?q=strip-ansi+string-width&type=issues.
This comment explains the issue and provides a workaround.

@danielroe The root issue is fixed in current version of Yarn. Perhaps it'll be helpful for folks if the first comment in this thread directs them to the Yarn update instructions here: https://yarnpkg.com/getting-started/install#updating-yarn
yarn set version stable
yarn install

While the "resolutions" shim is a reasonable temporary fix, if you can update your version of Yarn that is the proper fix.

Still facing this issue :\

I had the same issue on docker and came across this solution:
remove the yarn.lock from copy list and let the yarn use original package.json the issue resolved.

@navidshad This is not a solution, that is terrible advice.

To be clear, this is a yarn bug with a workaround. And the bug has been fixed in a newer version of yarn.
See https://github.com/nuxt/nuxt/issues/21231#issuecomment-2067519752


Running container icon should remain green

Would be nice if icon would turn green if you have a selected container that is running - it turns white - whether running or not - if you select the container.

Once you select a container the right panel shows a couple of status along with the play/pause button.
Additionally the icon type is different when the container is running and when it's not.


Make ShaderDescription and related types public

ShaderDescription is used as a return parameter in one of the public functions of RenderingDeviceDriver, so it makes little sense that such structs were protected, hidden from the same scope that can call the mentioned function if directly dealing with the driver.

Thanks!


How to use init_commands to install python packages from a local directory?

Since packages are downloaded and installed after every restart, to make it more robust, I think it's better to install packages from a local directory instead.
However I'm not familiar with docker so I couldn't figure out how to do this. I figure the command should be something like:
system_packages: []
python_packages: []
init_commands:
  - pip install -e /path/to/package

But I'm not able to figure out how to refer to an outside directory inside the addon docker.

This is not by design of this add-on and is definitely not an issue/bug.
If you want to work around things, that is fine, but you are on your own in that case.


Seperate values in same cell

Is it possible to separate values within the same cell? I want to validate for for duplicates in one particular column, but it only finds duplicates if the two values are alone in their cell in the column. Commas, semicolons, nothing works.
I'm still a beginner at VBA, but i have a userform to fill in rows and i had a part where it would check the whole column and let the user know if there is already that same value for that cell in that column, but again it only works if there is only the value and nothing else.
What can i do to have excel know there are multiple values in a cell? Is it possible?

If your cells are:
red,green,blue
blue,green,red
orange,brown

Excel will never never treat this as duplicates even those the first two rows "have the same values" in them.
You can either 1) loop through the cells and parse them yourself, or 2) use the Find method (acts just like CTRL-F does). If the area to search is very large, use 2. If the area to search is very small, 1 is much easier to write in VBA.
If you need more pointers, you'll probably want to ask this again in an Excel VBA forum and be sure to attach an example over there.


No Intellisense for globally installed JavaScript modules

Intellisense and suggestions do not work for modules that are installed globally using npm install -g.
It only works if the module is listed in the package.json file at the root of the project folder.

Duplicate of https://github.com/Microsoft/TypeScript/issues/20401 which is a duplicate of https://github.com/Microsoft/TypeScript/issues/8760
The recommendation is to always have dependencies listed in the local package.json


bug: Kubernetes spelled wrong

Describe the bug

In this above image, under the subsection "Size considerations" the second instance of Kubernetes is incorrectly spelled.
Steps To Reproduce
https://docs.kubestellar.io/release-0.23.0/direct/best-practices/
this is the website with the incorrect spelling
Expected Behavior
Kuberentes should be spelled Kubernetes
Additional Context
No response

@rchen-devv can you open a PR with a fix for this? If you click on the "Edit this page" icon on the top of the page https://docs.kubestellar.io/release-0.23.0/direct/best-practices/ a page will open in GitHub that allows you to edit the content, correct the spelling mistake, and then 'propose' a fix.

Issue is fixed with a PR and the new site is updated. Closing this issue with this comment.


Dashboard: Sites map responding unpredictably to Country Dashboard and Filter by Program menus

Problem: Sites map behaves unpredicta
To reproduce:

Make sure you have access to more than one country's data in profile settings.
Go to the TolaActivity dashboard (home page).
Select a country from the Country Dashboard menu, i.e. "Nigeria Dashboard"

Now pick a program, i.e. "Educating Nigerian Girls..." The map shows the correct program sites, but note that the Country Dashboard has reverted to its default state. You no longer are on the Nigeria Dashboard, and the Filter by Program menu contains all programs from all countries.

Now pick "All" from the Program menu. Note that the map is still showing the program data. It has ignored your request.

Now choose a different country, i.e. United States.
Now pick a program from the United States such as Tola Rollout.
Oy! Check out that map! Wrong country!

Again, note that both Country Dashboard and Filter by Program menus have reverted to the default "all".

This "show sites related to one program" feature no longer exists in our updated Country/Home page.


Run the initialize functions within the default frame

At the moment initialize functions are not run within a frame, so any entity created via createEntity is marked as invalid, and cannot be interacted with further. This first surfaced in 0.8.2 with the new entity validity checking.
A minimal case:
await World.create({
  defs: [TestComponent, class extends System {
    initialize() {
      output = this.createEntity(TestComponent).hold();
    }
  }]
});

An example error:
entity.ts:199 Uncaught Error: Entity handle no longer valid
    at EntityImpl.__checkValid (entity.ts:199)
    at EntityImpl.hold (entity.ts:173)
    at eval (eval at return (registry.ts:49), <anonymous>:17:29)
    at EntityPool.return (registry.ts:49)
    at EntityPool.returnTemporaryBorrows (registry.ts:39)
    at Registry.flush (registry.ts:124)
    at Dispatcher.flush (dispatcher.ts:276)
    at Dispatcher.createEntity (dispatcher.ts:284)

I went ahead and created a test + PR for this, hope that's ok; happy to discuss the approach further :)

Thanks for reporting this!  It was actually a symptom of bigger problems with System.initialize -- I forgot to keep it up to date as the rest of the project evolved.  I  borrowed your test (thanks!) and patched things up a bit in v0.8.4 (commit).  System initialization will now enforce r/w masks from query declarations, but will no longer run initializations in parallel until I can do so safely, respecting scheduling constraints.


Home Card Text Hover Effect, Login Button, and Card Color Combination Improvements

Description:
The home page of the website requires some improvements to enhance the user experience and visual appeal. The following issues have been identified:

Home Card Text Hover Effect and Shadow:
The text hover effect on the home cards is not visually engaging or intuitive. It needs improvement to provide a clear indication of interactivity. Additionally, the shadow applied to the cards should be adjusted to achieve a better visual effect.

Login Button:
The current design of the login button is perceived as irritating or distracting. It needs to be improved to provide a more pleasant and user-friendly experience. Consider using a different color, style, or placement to make it more visually appealing and less intrusive.

Card Color Combination:
The color combination used for the cards on the home page could be enhanced to create a better visual harmony and improve readability. Consider selecting colors that complement each other and ensure sufficient contrast between the background and text.

Proposed Solution:
To address these issues and improve the home page:

Enhance the text hover effect on the home cards to make it more visually engaging and intuitive. Adjust the shadow applied to the cards to achieve a better visual effect.

Improve the design of the login button by using a different color, style, or placement to make it more visually appealing and less distracting.

Revise the color combination of the cards to create a better visual harmony. Select colors that complement each other and ensure sufficient contrast between the background and text.

Please assign this issue to me

Please read readme.md and mention the issue no while raising the pr.

Please read readme.md and mention the issue no while raising the pr.

Ok

@AKD-01 Please add gssoc tag 😄

I'd like to work upon this issue if this hasn't been done yet.Pls assign it to me


Sitemaps : more robust parsing of XML elements

This patch simplifies the logic of extracting textual values from elements such as loc. At the moment it throws a NPE if the first child element does not have a value as in the example below :
[http://jobs.optistaffing.com/sitemap.xml]
<url>
<loc>
<url>
<![CDATA[
http://jobs.optistaffing.com/EXPERIENCED-DISPATCHER-NEEDED-NOW----Jobs-in-Vancouver-WA/2333221
]]>
</url>
</loc>
<lastmod>2015-04-28</lastmod>
<changefreq>daily</changefreq>
</url>

at least we should handle this more gracefully and check that children.item(0)).getNodeValue() is not null.
This PR uses a more generic approach for extracting the textual content of a node which also has the added benefit of extracting correctly from the cases above where the content is slightly incorrect e.g. additional url element within the loc.

@crawler-commons/owners - any objections to committing this?

Hi Julien,
If we're trying to protect against bad data, then shouldn't getElementValue() check if getElementsByTagName() returns a non-null list with at least one element before continuing?
In general the code in SiteMapParser seems to assume the resulting DOM will contain well-formed data, e.g. line 536 is iterating over what could be a null result if the RSS text isn't valid. From my experience in Tika, consumers of parse results would rather have logging & no NPEs versus having to catch errors, especially since one bit of malformed text in a large sitemap would then render the entire map useless.
So wondering if we should have a separate issue for bullet-proofing the code.

Thank Ken. Definitely! No need for a separate issue, let's do that in this one.

Committed in [master 20861ba] Issue 75: [Sitemaps] more robust parsing of XML elements (jnioche, kkrugler)

new issue for this #79


Regression: New resource system no longer supports nested directories

Describe the bug
My application has hundreds of images, all organized into a directory tree depending on their type (icon / illustration) and by feature that uses them. The old resource system supported this. With the new resource system, I am forced to flatten them all into a single directory and lose all organisation.
Affected platforms

Desktop

Versions

Compose Multiplatform version: 1.6.0

Expected behavior
The generated Res class should include resources from nested directories.
For example:
composeResources/drawable/icons/check.png should be accessible under Res.drawable.icons.check, or Res.drawable.icons_check (the second option risks conflicts though).

there is no regression because before you had to load images by file paths. the same you can do for the files directory: https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-images-resources.html#raw-files
If you ask about subdirs + generated accessors then there is another issue: https://github.com/JetBrains/compose-multiplatform/issues/4196

Previously I was able to do:
painterResource("icons/windows/close_button.png")
I can no longer do that.
files is not an alternative. readBytes returns a ByteArray, not a DrawableResource, and more importantly it's suspending, so it can't be simply called like above.


Fix compilation on Clang 12 with -std=c++17

Argument deduction for a class type (like ctll::fixed_string) in a non-type template is
not supported until C++20 (201911L).
Fixes #234.

Fixed in latest main a bit differently.


Q: How to best organize queues?

Hi,
I'm using prisma-queue in my current project to great delight. Thanks for sharing this! 🚀
I was wondering how to best organize my queues. Since the handler is typed to a certain type of Job, it would seem that I have to either create a separate queue for each job type or create a generic job type that handles different tasks.
Say, for instance, you want to have a priority queue for sending emails and another one for all other jobs. How would you set this up?

Sorry for the late comment, I think both options are possible and valid and ends up being a trade-off between simplicity and flexibility.
One single queue with a job type field should work for most cases, but you have a single configuration and share the concurrency between all job types.
Multiple queues let you more cleanly separate job types and have flexible per-queue configuration, but you now have multiple queues running concurrently that you might want to move to their own process to guarantee isolation which can lead to a more complex setup.


Set correct path for Firefox on linux

When running canopy on linux (Ubuntu 18.04) i get the following error message:
1541168288570 mozrunner::runner INFO Running command: "/usr/lib/firefox-2.0" "-marionette" "-foreground" "-no-remote" "-profile" "/tmp/rust_mozprofile.5HkpmFMeb2U6"

Unhandled Exception: System.InvalidOperationException: Failed to start browser /usr/lib/firefox-2.0: no such file or directory (SessionNotCreated)

Don't know what firefox-2.0 is actually, but /usr/lib/firefox/firefox is the correct path :)

In the meantime, you can do
configuration.firefoxDir <- "your\desired\path"

before starting the browser and it should work.

Ok, thanks 😊
On Fri, 2 Nov 2018, 15:52 Chris Holt<EMAIL_ADDRESS>wrote:

In the meantime, you can do
configuration.firefoxDir <- "your\desired\path"
before starting the browser and it should work.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lefthandedgoat/canopy/pull/456#issuecomment-435405838,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMLsQGLs_976I7BcqqOxSC5DDQlmeb1qks5urFxEgaJpZM4YLxXe
.


Fix markdown formatting for # on GitHub

When GitHub displays markdown, a "#" preceded by
whitespace or beginning-of-line followed by a digit
turns into a link to the issue or pull request.
That is not what we want!
So this converts such number signs into # so that
the markdown generates correctly on GitHub.
Signed-off-by: David A. Wheeler<EMAIL_ADDRESS>

Nope, that also fails.