Build OpenSSL on ubuntu, compile failed in x86_32(providers/legacy.so)

Get the latest OpenSSL code of master branch, "./config; make; make install_sw;". compile it on ubuntu. find that the builds on x86-64,aarch32,aarch64 are success but fails on x86-32.  But strangely, once we remove the option "

no-deprecated

", it can compile successfully.
Is it one issue or just leave it there compile failure?

What is that "linux32"?

What is that "linux32"?

This option "linux32" to make the code detect the arch of 32 bit. Before, we simply try -m32, but found many errors during compile, the linux32 can make it compile successfully.

Could you please do this, so I can see what the actual configuration is, in terms I understand?
Short version:
./configdata.pm -c

Long version:
./configdata.pm -d

Could you please do this, so I can see what the actual configuration is, in terms I understand?
Short version:
./configdata.pm -c

---Short version result as below:

`root@cdd56c00a8ca:/home/ent-user/work/ci-scripts/openssl# ./configdata.pm -c

Command line (with current working directory = .):
/usr/bin/perl ./Configure linux-x86 -g3 -Werror no-deprecated --prefix=/home/ent-user/work/ci-scripts/openssl-install

Perl information:
/usr/bin/perl
5.26.1 for i686-linux-gnu-thread-multi-64int

`

Long version:
./configdata.pm -d

Long version result as below:

`Command line (with current working directory = .):

/usr/bin/perl ./Configure linux-x86 -g3 -Werror no-deprecated --prefix=/home/ent-user/work/ci-scripts/openssl-install

Perl information:
/usr/bin/perl
5.26.1 for i686-linux-gnu-thread-multi-64int

Enabled features:
afalgeng
aria
asm
async
autoalginit
autoerrinit
autoload-config
bf
blake2
camellia
capieng
cast
chacha
cmac
cmp
cms
comp
ct
des
dgram
dh
dsa
dso
dtls
dynamic-engine
ec
ec2m
ecdh
ecdsa
engine
err
filenames
fips
gost
idea
legacy
makedepend
md4
mdc2
module
multiblock
nextprotoneg
pinshared
ocb
ocsp
pic
poly1305
posix-io
psk
rc2
rc4
rdrand
rfc3779
rmd160
scrypt
seed
shared
siphash
siv
sm2
sm3
sm4
sock
srp
srtp
sse2
ssl
static-engine
stdio
tests
threads
tls
ts
ui-console
whirlpool
tls1
tls1-method
tls1_1
tls1_1-method
tls1_2
tls1_2-method
tls1_3
dtls1
dtls1-method
dtls1_2
dtls1_2-method

Disabled features:
asan                [default]        OPENSSL_NO_ASAN
buildtest-c++       [default]
crypto-mdebug       [default]        OPENSSL_NO_CRYPTO_MDEBUG
deprecated          [option]         OPENSSL_NO_DEPRECATED
devcryptoeng        [default]        OPENSSL_NO_DEVCRYPTOENG
ec_nistp_64_gcc_128 [default]        OPENSSL_NO_EC_NISTP_64_GCC_128
egd                 [default]        OPENSSL_NO_EGD
external-tests      [default]        OPENSSL_NO_EXTERNAL_TESTS
fuzz-libfuzzer      [default]        OPENSSL_NO_FUZZ_LIBFUZZER
fuzz-afl            [default]        OPENSSL_NO_FUZZ_AFL
ktls                [default]        OPENSSL_NO_KTLS
md2                 [default]        OPENSSL_NO_MD2 (skip crypto/md2)
msan                [default]        OPENSSL_NO_MSAN
padlockeng          [cascade]        OPENSSL_NO_PADLOCKENG
rc5                 [default]        OPENSSL_NO_RC5 (skip crypto/rc5)
sctp                [default]        OPENSSL_NO_SCTP
ssl-trace           [default]        OPENSSL_NO_SSL_TRACE
trace               [default]        OPENSSL_NO_TRACE
ubsan               [default]        OPENSSL_NO_UBSAN
unit-test           [default]        OPENSSL_NO_UNIT_TEST
uplink              [no uplink_arch] OPENSSL_NO_UPLINK
weak-ssl-ciphers    [default]        OPENSSL_NO_WEAK_SSL_CIPHERS
zlib                [default]
zlib-dynamic        [default]
ssl3                [default]        OPENSSL_NO_SSL3
ssl3-method         [default]        OPENSSL_NO_SSL3_METHOD

Config target attributes:
AR => "ar",
ARFLAGS => "r",
CC => "gcc",
CFLAGS => "-Wall -O3 -fomit-frame-pointer",
CXX => "g++",
CXXFLAGS => "-Wall -O3",
HASHBANGPERL => "/usr/bin/env perl",
RANLIB => "ranlib",
RC => "windres",
asm_arch => "x86",
bn_ops => "BN_LLONG",
build_file => "Makefile",
build_scheme => [ "unified", "unix" ],
cflags => "-pthread -m32",
cppflags => "",
cxxflags => "-std=c++11 -pthread -m32",
defines => [  ],
disable => [  ],
dso_ldflags => "-z defs",
dso_scheme => "dlfcn",
enable => [ "afalgeng" ],
ex_libs => "-ldl -pthread",
includes => [  ],
lflags => "",
lib_cflags => "",
lib_cppflags => "-DOPENSSL_USE_NODELETE -DL_ENDIAN",
lib_defines => [ "OPENSSL_BUILDING_OPENSSL" ],
module_cflags => "-fPIC",
module_cxxflags => undef,
module_ldflags => "-Wl,-znodelete -shared -Wl,-Bsymbolic",
perl_platform => "Unix",
perlasm_scheme => "elf",
shared_cflag => "-fPIC",
shared_defflag => "-Wl,--version-script=",
shared_defines => [  ],
shared_ldflag => "-Wl,-znodelete -shared -Wl,-Bsymbolic",
shared_rcflag => "",
shared_sonameflag => "-Wl,-soname=",
shared_target => "linux-shared",
thread_defines => [  ],
thread_scheme => "pthreads",
unistd => "<unistd.h>",

Recorded environment:
AR =
BUILDFILE =
CC =
CFLAGS =
CPPFLAGS =
CROSS_COMPILE =
CXX =
CXXFLAGS =
HASHBANGPERL =
LDFLAGS =
LDLIBS =
OPENSSL_LOCAL_CONFIG_DIR =
PERL =
RANLIB =
RC =
RCFLAGS =
WINDRES =
__CNF_CFLAGS =
__CNF_CPPDEFINES =
__CNF_CPPFLAGS =
__CNF_CPPINCLUDES =
__CNF_CXXFLAGS =
__CNF_LDFLAGS =
__CNF_LDLIBS =

Makevars:
AR              = ar
ARFLAGS         = r
CC              = gcc
CFLAGS          = -Wall -O3 -fomit-frame-pointer -g3 -Werror
CPPDEFINES      =
CPPFLAGS        =
CPPINCLUDES     =
CXX             = g++
CXXFLAGS        = -Wall -O3 -g3 -Werror
HASHBANGPERL    = /usr/bin/env perl
LDFLAGS         =
LDLIBS          =
PERL            = /usr/bin/perl
RANLIB          = ranlib
RC              = windres
RCFLAGS         =

NOTE: These variables only represent the configuration view.  The build file
template may have processed these variables further, please have a look at the
build file for more exact data:
Makefile
build file:
Makefile

build file templates:
Configurations/common0.tmpl
Configurations/unix-Makefile.tmpl
Configurations/common.tmpl

`

Ok, thanks.  From my testing, it seems that no-deprecated is what causes the issue, which is this, btw (why wasn't that included in your error report, @xkqian?):
gcc -fPIC -pthread -m32 -Wa,--noexecstack -Wall -O0 -g -DDEBUG_UNUSED -DPEDANTIC -pedantic -Wno-long-long -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wswitch -Wsign-compare -Wshadow -Wformat -Wtype-limits -Wundef -Werror -Wmissing-prototypes -Wstrict-prototypes -L. -z defs -Wl,-znodelete -shared -Wl,-Bsymbolic   \
	-o providers/legacy.so -Wl,--version-script=providers/legacy.ld \
	providers/legacy-dso-legacyprov.o \
	providers/liblegacy.a providers/libcommon.a providers/libnonfips.a -lcrypto -ldl -pthread
/usr/bin/ld: providers/liblegacy.a(liblegacy-lib-wp_block.o): in function `whirlpool_block':
/home/levitte/gitwrk/openssl.net/official/_build-32/../master/crypto/whrlpool/wp_block.c:495: undefined reference to `OPENSSL_ia32cap_P'
collect2: error: ld returned 1 exit status

BUG_

Maybe I compiled it with multi threads, the log be flooded...

If I build it with simple command "make", I can get the same error report with you.@levitte

No need at this point, I'm doing the same build and can confirm your report

Having looked and compared a build with and without no-deprecated, I haven't the foggiest idea why that option matters.  To make things worse, I can't understand how a providers/legacy.so linked with libcrypto.so can access OPENSSL_ia32cap_P in any case, considering it's never exported!

I'll try and adjust crypto/build.info to make this work the way it should

Please try with #11311, and see if that makes things work a bit better.  It does on my machine...

With PR  #11311, it also works on my local, thanks for the fix.

#11311 hasn't been merged yet, and when I try a fresh master now, it looks like this issue has disappeared.
@xkqian, can you confirm?

#11311 hasn't been merged yet, and when I try a fresh master now, it looks like this issue has disappeared.
@xkqian, can you confirm?

#11311 hasn't been merged yet, and when I try a fresh master now, it looks like this issue has disappeared.
@xkqian, can you confirm?

I verified it locally with the openssl master branch commit: daa86f9e6bfeb83a5db976c6351f7a568a8d6dcb. Seems the issue has been gone.
(BTY: with the latest commit code, ./config; make -j64; run successfully, but it will fail in when make install_sw, reported the error about 'install_dev')

#11311 hasn't been merged yet, and when I try a fresh master now, it looks like this issue has disappeared.
@xkqian, can you confirm?

I verified it locally with the openssl master branch commit: daa86f9e6bfeb83a5db976c6351f7a568a8d6dcb. Seems the issue has been gone.
(BTY: with the latest commit code, ./config; make -j64; run successfully, but it will fail in when make install_sw, reported the error about 'install_dev')

(BTY: with the latest commit code, the command ./config; make -j64; run successfully, but it will fail  when make install_sw, reported the error about 'install_dev')

The install targets don't lend themselves well for parallelism.  This is known, and yet unresolved.  Different issue, though.

(BTY: with the latest commit code, the command ./config; make -j64; run successfully, but it will fail  when make install_sw, reported the error about 'install_dev')

The install targets don't lend themselves well for parallelism.  This is known, and yet unresolved.  Different issue, though.

I verified it locally with the openssl master branch commit: daa86f9. Seems the issue has been gone.

Thanks.  Closing

I verified it locally with the openssl master branch commit: daa86f9. Seems the issue has been gone.

Thanks.  Closing


Does pgbulkinsert support postgis types?

hello！How to set up mapping between Java String and Postgis Geometry?

Reading through my libraries code again, I would say it does not fully support them. I do support Geometric types, as shown in the README, but I am not sure they are PostGIS equivalents. Half a decade ago I had implemented a PostGIS handler here:

https://github.com/bytefish/PostGisBulkInsert

You should be able to copy and paste the few lines into your project. The README shows how to use it. And it should still work, given the APIs didn't change a lot for the dependencies.

I have added update PostGisBulkInsert to the latest dependencies, so it should work with PgBulkInsert.

Here is the

https://github.com/bytefish/PostGisBulkInsert/blob/master/PostGisBulkInsert/src/test/de/bytefish/postgisbulkinsert/integration/PostgisExtensionStringTest.java

It shows how you would insert from a String, which is given as WKT. It uses sf-wkt for reading the data, and PostGisBulkInsert uses sf-wkb for writing the data.


Patch

Fixes #6.
Fixes #7.

Codecov Report

Merging #8 (e3f1dc5) into master (9e57bb4) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #8   +/-   ##
=======================================
  Coverage   50.00%   50.00%
=======================================
  Files           1        1
  Lines           2        2
=======================================
  Hits            1        1
  Misses          1        1

Continue to review full report at Codecov.

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


Cannot login with email and pwd

I downloaded android version and installed.  Then I used email and pwd for both option login and login with Microsoft.  But both are not working.  Is it expected way ? 😁😄

Our login process changed. Can you reinstall the app and try to login with any email or password? It should work now. Thank you!


Menu mapping doesnt respect custom keymap

I use https://github.com/eoli3n/void-config/blob/master/scripts/install/02-install.sh#L148 to configure azerty keymap for zfsbootmenu, which works, as keymap is azerty when i type my passphrase.
# Config keymap as https://github.com/zbm-dev/zfsbootmenu/issues/96#issuecomment-745627427
mkdir -p /mnt/etc/cmdline.d
echo 'rd.vconsole.keymap=fr' > /mnt/etc/cmdline.d/keymap.conf
echo 'install_optional_items+=" /etc/cmdline.d/keymap.conf "' > /mnt/etc/zfsbootmenu/dracut.conf.d/keymap.conf

Except, you told me to use an undocumented [ALT+W] combo to mount RW.
It didn't work, but [ALT+Z] did.
Menu alt combos doesnt respect keymap.

If i run the following in recovery shell, it triggers the problem. Alt-w does nothing, alt-z stop it
printf "%s\n" a b c d e f g | fzf --expect alt-w

generate-zbm with hostonly="yes" didn't solve it.

After quite a bit of testing and debugging this issue, @ahesford, @ericonr and I have tracked this down to specifically the alt key handling under the fr keymap. (ctrl-<key> works correctly under fr) Can you try changing the keymap to azerty in /etc/cmdline.d/keymap.conf, re-run generate-zbm and try again?
@ahesford and I are working on a more permanent solution, but it will take a bit of time to implement it cleanly.

When i change in /etc/cmdline.d/keymap.conf
rd.vconsole.keymap=fr

to
rd.vconsole.keymap=azerty

My keyboard fallback in qwerty as typing my passphrase on my azerty keyboard doesnt work.


issue with Xcode project

I'm not more able to compile thought the Xcode project.
Some one can update the project?
thanks in advance.

What's the actual error? I don't have own a Mac device, but knowing the exact problem would help.

For me it's:
error: Build input file cannot be found: '/Users/jad/Documents/Programming/GameDev/Vulkan/xcode/macOS/Prefix.pch' (in target 'examples-macos' from project 'examples')

same of 0xNotNeo
moreover there are a lot of file that Xcode is not able to find.
stb_rect_pack.h
stb_textedit.h
stb_truetype.h
VulkanBuffer.hpp
and so on

The Xcode port was handled by the people at MoltenVK. I don't own a Mac myself, so I can't test or fix this. If possible, a PR would be appreciated.

The Xcode port was handled by the people at MoltenVK. I don't own a Mac myself, so I can't test or fix this. If possible, a PR would be appreciated.


Running as root is not recommended Issue

Hi,
followed the install tutorial on my pi but when executing jupyter it stops with the error message about root issues.
[I 11:55:37.449 NotebookApp] Writing notebook server cookie secret to /root/.local/share/jupyter/runtime/notebook_cookie_secret [W 11:55:37.525 NotebookApp] WARNING: The notebook server is listening on all IP addresses and not using encryption. This is not recommended. [C 11:55:37.558 NotebookApp] Running as root is not recommended. Use --allow-root to bypass.
any idea what I am doing wrong?

You're not doing anything wrong. Running an unprotected Jupiter notebook on
a network is generally not a good idea, hence the warnings, but running one
on a Pi inside a docker container is likely to be safe enough.
On 17 Jun 2017 14:01, "othreed"<EMAIL_ADDRESS>wrote:

Hi,
followed the install tutorial on my pi but when executing jupyter it stops
with the error message about root issues.
[I 11:55:37.449 NotebookApp] Writing notebook server cookie secret to
/root/.local/share/jupyter/runtime/notebook_cookie_secret [W 11:55:37.525
NotebookApp] WARNING: The notebook server is listening on all IP addresses
and not using encryption. This is not recommended. [C 11:55:37.558
NotebookApp] Running as root is not recommended. Use --allow-root to bypass.
any idea what I am doing wrong?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/romilly/rpi-docker-tensorflow/issues/2, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAJHPoVfZeeFKZsMS7pNR3quRNB8Etu4ks5sE8FZgaJpZM4N9NUq
.

somehow it goes back to the shell after putting out the error about:
Running as root is not recommended. Use --allow-root to bypass.
I cannot access the URL via webbrowser. This is why I thought it is mandatory to run it not as root... but I cannot get it to work

I'll spin up a pi tomorrow and investigate.
On 17 Jun 2017 17:58, "othreed"<EMAIL_ADDRESS>wrote:

somehow it goes back to the shell after putting out the error about:
Running as root is not recommended. Use --allow-root to bypass.
I cannot access the URL via webbrowser. This is why I thought it is
mandatory to run it not as root... but I cannot get it to work
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/romilly/rpi-docker-tensorflow/issues/2#issuecomment-309226958,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJHPvcid7zFM0swL74rTrrdGxhZ8WTaks5sFAXTgaJpZM4N9NUq
.

I've pushed an (untested) fix to github. If you have a chance to test it
before I do, please let me know if it works :)
On 17 June 2017 at 18:19, Romilly Cocking<EMAIL_ADDRESS>wrote:

I'll spin up a pi tomorrow and investigate.
On 17 Jun 2017 17:58, "othreed"<EMAIL_ADDRESS>wrote:

somehow it goes back to the shell after putting out the error about:
Running as root is not recommended. Use --allow-root to bypass.
I cannot access the URL via webbrowser. This is why I thought it is
mandatory to run it not as root... but I cannot get it to work
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/romilly/rpi-docker-tensorflow/issues/2#issuecomment-309226958,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJHPvcid7zFM0swL74rTrrdGxhZ8WTaks5sFAXTgaJpZM4N9NUq
.

--
personal:@romillyc work:@rareblog skype:romilly.cocking web:
http://blog.rareschool.com/

Thank you for the quick fix. It works
WOW


SteamInfo.SteamInstalled is true but steam is not installed anymore

Desktop-Application consuming the library fails on a computer that has no steam installed. Steam was installed on the computer a few months ago so maybe the code still finds some registry keys left behind from the uninstallation.
Error:

Code:

https://github.com/JohannesDrexler/SteamClientWrapper/blob/d604e935cc6bd7f0ed9a897049b5d1f4f0d94e9b/Src/SteamClientWrapper/SteamInfo.cs#L63
It seems the registry key is still there and the code doesn't check if the directory exists (or better directory + 'steam.exe')


Failure to parse syntax correctly when function name and open-paren are separated by a newline

With C Improved, the function name bad does not appear in Go To Symbol (Cmd+R).  Here's a minimal case:
void good() {
}
void
bad
()
{}
void good2(){}

This ends up breaking the indexing, so that "Go to definition" does not work for functions whose signatures are formatted this way.
You can see in the screenshot that bad() doesn't show up, when using C Improved syntax.

Using the default C syntax, everything works as expected:

@zachriggle Unfortunately, I do not maintain this plugin anymore, sorry for that.


Update for new retry state machine JNI APIs

This depends on https://github.com/NVIDIA/spark-rapids-jni/pull/1543.  https://github.com/NVIDIA/spark-rapids-jni/pull/1543 is also a breaking change so both of these need to go in at about the same time.
This mostly just updates the existing code to use the new APIs that are equivalent to what we used before. A separate PR will come later to add in support for CPU allocation/retry along with optional configs to try and limit the CPU memory usage.

build


Rename XHPHelpers traits/interfaces, deprecate transferattributes

rename XHPBaseHTMLHelpers to XHPHTMLHelpers as there's no sub-thing
rename XHPHelpers to XHPAttributeClobbering_DEPRECATED as
transferAttributes is now all it adds over the base one
merge XHPHasTransferAttributes with
HasXHPAttributeClobbering_DEPRECATED

fixes #230
fixes #134

Naming also matches FB


Update npm package

New version is awesome! Thanks all for great work.
Please update npm package.

Paging @kevinsimper :)

:+1:  Also could there be a link to the npm page in the README?

It's done, https://www.npmjs.com/package/craftyjs
Is there anyone I can add to that repository? The deployment is basicly just npm publish, so it is very easy once you have access :+1:

Great, thanks! @starwed do you have an account there, so kevin can add you there? If you want to add me, I use the same nick there.

@mucaho You have been added :+1:

@kevinsimper Thanks! :+1:


[cairo] Update to 1.18.2

Fixes android. CI baseline fail moved downstream.

All features are tested successfully in the following triplet:

x86-windows
x64-windows
x64-windows-static


Error: Plugin 'commonmarker' not found.

I have a v3 json file and trying to use --legacy.
Any ideas?
autorest --input-file=c:\b2i\swagger.json --v3 --csharp --output-folder=C:\Api_WithCreds --namespace=A.B.C --add-credentials --legacy

I have been struggling with the same message, I do have it working now by specifying
autorest readme.md --use<EMAIL_ADDRESS>hopefully i can move that into the readme.md too.

Thanks for the quick response but unfortunately it didn't work:

I have given this a try on a different project of mine and here is the minimum for a successful execution.
readme.md

Make AutoRest3 output C# like AutoRest2
A small sample to remind myself.
# specify the version of Autorest to use
version: 2.0.4413 # This doesn't seem to be useful
input-file: swagger.yaml
csharp:
  output-folder: ./out/
  namespace: UnOffSiSenseDotNet.V0

Run the command
autorest readme.md --use<EMAIL_ADDRESS>The output

PS C:\Temp\autorest> autorest readme.md --use<EMAIL_ADDRESS>AutoRest code generation utility [cli version: 3.3.2; node: v12.13.0]
(C) 2018 Microsoft Corporation.
https://aka.ms/autorest
NOTE: AutoRest core version selected from configuration: ~2.0.4413.
There is a new version of AutoRest available (3.4.0).

You can install the newer version with with npm install -g autorest@latest

Loading AutoRest core      'C:\Users\anon.autorest@microsoft.azure_autorest-core<EMAIL_ADDRESS>(2.0.4421)
Loading AutoRest extension<EMAIL_ADDRESS>(2.3.82->2.3.82)
Loading AutoRest extension<EMAIL_ADDRESS>(2.3.55->2.3.55)
PS C:\Temp\autorest> autorest readme.md --use<EMAIL_ADDRESS>AutoRest code generation utility [cli version: 3.3.2; node: v12.13.0]
(C) 2018 Microsoft Corporation.
https://aka.ms/autorest
NOTE: AutoRest core version selected from configuration: ~2.0.4413.
There is a new version of AutoRest available (3.4.0).

You can install the newer version with with npm install -g autorest@latest

Loading AutoRest core      'C:\Users\anon.autorest@microsoft.azure_autorest-core<EMAIL_ADDRESS>(2.0.4421)
Loading AutoRest extension<EMAIL_ADDRESS>(2.3.82->2.3.82)
Loading AutoRest extension<EMAIL_ADDRESS>(2.3.55->2.3.55)

I think the important bit to look out for there is
NOTE: AutoRest core version selected from configuration: ~2.0.4413.
I get output like this

So while I have the output I want it doesn't seem to match the docs which says to use --legacy.
I also had success with PS C:\Temp\autorest> autorest readme.md --v2

@MarkZither
--legacy is for when you are using --v3 input
You seem to be using --v2 which is offtopic?

We have updated the default generator used by autorest --csharp to the new version V3, which uses @autorest/csharp package. If you still want to generate code based on V2 version, you can add --legacy flag or specify a version --use<EMAIL_ADDRESS>to the command line to get the previous behavior.
For more information please refer these docs.

Same issue, I'll describe in detail this comment.
Our team has an OpenAPI_v3 yaml spec. Originally, we used autorest cli version: 3.1.5; node: v14.16.1 to create http client/SDK.
A new team member made some changes to v3 spec. When new team member tried using autorest to update client code, using their local (newer) autorest version [cli version: 3.6.1; node: v16.13.2] they receive error:
info    |    Loading AutoRest core      'C:\Users\xxx\.autorest\@autorestcore@3.8.3\nodemodules\@autorest\core\dist' (3.8.3)
info    |    Loading AutoRest extension<EMAIL_ADDRESS>(~2.3.79->2.3.82)
info    |    Loading AutoRest extension<EMAIL_ADDRESS>(2.3.55->2.3.55)
fatal   | Process() cancelled due to failure
error   |   Error: Plugin 'commonmarker' not found.
error   | Autorest completed with an error. If you think the error message is unclear, or is a bug, please declare an issues at https://github.com/Azure/autorest/issues with the error message you are seeing.

We are both using the same source controlled README file as input: autorest readme.md
input-file: swagger.yaml
csharp: true
output-folder: ../Sdk/HttpClient
namespace: NameOf.HttpClient
legacy: true
override-client-name: NameOfHttpClient

When person 1 runs autorest readme.md using legacy autorest verion:  [cli version: 3.1.5; node: v14.16.1] no error, clean output/update to client code.
When person 2 runs autorest readme.md using new autorest verion:  [cli version: 3.6.1; node: v16.13.2] receive error.

Per the above @ShivangiReja :

Can we incorporate this flag: --use<EMAIL_ADDRESS>in the above README file somehow instead of running from command line?

What is the newest possible version of autorest we can run that does not break on Error: Plugin 'commonmarker' not found. and returns desired behavior using readme.md?

Looking at these docs:

It will generate code based on the .NET SDK guidelines, which will be totally different than the code generated by V2 version.

We don't want this behavior, we want the existing code format, not the totally new format. If we remove legacy flag from readme, it allows person 2 to generate code, but totally different code.

The dotnet core runtime 3.1+ is required.

We're still on .NET Framework, due to dependencies.

If you still want to generate code based on V2 version, you can add --legacy flag to the command line to get the previous behavior.

We did this, see readme.

If person 1 runs using legacy version of autorest [cli version: 3.1.5; node: v14.16.1], fine.
If person 2 runs using updated autorest version: error.

We are seeking a best-practice workaraound for this scenario. We looked at back-converting our v3 spec to swagger v2, but this comes with separate hurdles.

Hi, the only solution I found was to do force the whole thing to be v2.
In my apis, Startup.cs file, Configure() I added the following to get Swagger to output v2 and not v3
            app.UseSwagger(p => p.SerializeAsV2 = true);

and in ConfigureServices() I have:
            services.AddSwaggerGen(options =>
            {
                options.CustomOperationIds(e => $"{e.ActionDescriptor.RouteValues["controller"]}_{e.HttpMethod}");
                options.CustomSchemaIds(type => type.ToString());
            });

And finally for AutoRest I do this to force v2 also:
            autorest --input-file=c:\temp\swagger.json --v2 --csharp

I hope that helps.

I came up with the error.  the solution was to screw autorest and do it myself.
10000% more maintainable this way and I dont have to spend a day with each new person to explain this crap.

I have try down grade the node.js from v16.14.1 to v14.16.1.
Then run autorest readme.md using legacy no error, clean output/update to client code.
It takes looooooooooong time. You have to patient for it.


Is the default page a page without any CSS style ?

The home page in my local shows quite ugly without any styles inside, is this the expected one or there is something wrong with my local environment ?
Screenshot as below

That's correct. Starter kits are usually provided as minimal versions (without any useless styles and functions).
If you need version with shiny styles you can always use material2 branch.


Why medusa-2 train heads with llama2 with no such great improvement?

In the given examples  axoltol exmaples/medusa,
I follow the vicuna_7b_qlora_stage1.yml and vicuna_7b_qlora_stage2.yml to write my llama2 trainning config.
Howerver I did't get such greate performance improvement, below is my test results with different tokens generation in A100

Then I use official vicuna-7b medusa2 weigths, it does work.

So here I want to know what's the difference ?  Is my training config fault.

@ctlllll

same, I couldn't reproduce medusa-1 as well. Not sure if you have solved the issue. My guess is the training dataset was not cleaned (or simply not the one used by Vicuna model).


Broken links on story: "Create an admin user in UAA using the uaac CLI"

The link: https://docs.cloudfoundry.org/adminguide/uaa-user-management.html leads to "page not found". The link is referenced in both the "How?" and "Resources" sections.

Hey Lisa, this link appears to be working now, something must have just been off that day. Thanks for reporting it though!


ARROW-5010: [Release] Fix source release docker

Gandiva was migrated to llvm-7, the source release script Dockerfile did
not follow.

Codecov Report

Merging #4031 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4031      +/-   ##
==========================================
- Coverage   87.85%   87.84%   -0.02%
==========================================
  Files         736      736
  Lines       90597    90597
  Branches     1252     1252
==========================================
- Hits        79596    79582      -14
- Misses      10884    10894      +10
- Partials      117      121       +4

Impacted Files
Coverage Δ

go/arrow/math/int64_avx2_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/memory/memory_avx2_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/math/float64_avx2_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/math/uint64_avx2_amd64.go
0% <0%> (-100%)
:arrow_down:

go/arrow/memory/memory_amd64.go
28.57% <0%> (-14.29%)
:arrow_down:

go/arrow/math/math_amd64.go
31.57% <0%> (-5.27%)
:arrow_down:

js/src/ipc/metadata/json.ts
92.39% <0%> (-4.35%)
:arrow_down:

go/arrow/math/float64_amd64.go
33.33% <0%> (ø)
:arrow_up:

go/arrow/math/int64_amd64.go
33.33% <0%> (ø)
:arrow_up:

go/arrow/math/uint64_amd64.go
33.33% <0%> (ø)
:arrow_up:

... and 4 more

Continue to review full report at Codecov.

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


OpenSSL 3.1 versus 3.0 LTS

Hello everyone,
As stated in the newslog on 14-Mar-2023, the "Final version of OpenSSL 3.1.0 is now available: please download and upgrade!"
I understand that:

3.0 and 3.1 (or major.minor in general) are "stable releases" as described in the release policy.
The release strategy clearly states that while you basically follow the semantic versioning scheme, you will designate certain "bands" as LTS releases.

However, three questions arise in the context of providing Windows installers for the binary distributions we provide.:

Does the imperative "please upgrade" only refer to the 3.1.x release (i.e. upgrade from alpha+beta versions), or are users/programmers encouraged to upgrade from 3.0.x as well?
The release strategy is somewhat contradictory in the sense that a minor update doesn't break the ABI/API, but in this case 3.0.x outlives 3.1.x.
Should an OpenSSL 3.1 installer replace an OpenSSL 3.0 installation, or should they co-exist?

Thanks for your clarification.

I think the answer to your questions depends on your specific circumstances.

3.1 is unlikely to be supported for as long as 3.0 due to the latter being an LTS release.
We generally recommend using the most recent supported release (i.e. 3.1).
3.1 includes a number of performance fixes and enhancements over 3.0.
We do not yet have a plan for supporting the 3.1 FIPS provider once it is validated.  I expect it will receive support until it is sunsetted but that's not decided at this point.
Both 3.0 and 3.1 should be able to co-exist.

marking as inactive, will be closed at the completion of 3.4 dev without further input

Incidentally, the same question also arises in connection with all other interim versions, of which there are now 3.1, 3.2, 3.3 and probably soon 3.4.
If only API/ABI-compatible features are included in a new minor releases (as generally expected - or to put it the other way round: “No API or ABI breaking changes are allowed in a minor or patch release”), why should several minor releases exist at the same time?

Because not all changes are reasonably backportable.  3.3 contains feature enhancements that may not be reasonably backported to 3.2/3.1/3.0.

Understandably... However, I am not talking about backporting.
I'm talking about “fast-forwarding” to the next available minor version. All the features of the earlier minor versions are included in the minor versions.
For someone using 3.1.a, it should make no difference whether they update to 3.1.b or 3.3.c.
The effort to maintain such intermediate versions is certainly not without effort and complexity on OpenSSL's part, in addition to people like me having to ask questions and think about this particular release policy.
By the time 3.1 reaches the end of its life, there will probably be 2-3 more minor releases if you keep up the pace of good work...

The main reason is stability. Minor versions add new features (sometimes quite big ones such as the QUIC support). That adds of course a risk of introducing regressions.


Plans for future development

Are you planning to add other minecraftish features, like char models, ui and all other stuff?

Hello Aun, long time no see!
Sucle will allow anyone to create and mod the world of their dreams.

Yeah, well, but will you implement this yourself here?)
I see some other minecraft clones popping up.
https://www.minetest.net/

If you don't want to use Common Lisp, you don't have to, you have free will after all

Nono, didn't mean that. I'm absolutely sticking to CL now and then, just wondering if you plan to do this specific thing.
And the link is there just because those guys are open sourced too, so I thought you might be interested.

:) Well thank you for sharing! I'll check out minetest, pretty cool that its open source.
Right now sucle is in the middle of a huge rewrite, so new features won't be added soon. In fact, I'm trying to remove old features that are no longer necessary.


Unable to assign object literal to generically typed field

I am unable to assign an object literal to an extended generic type without a cast, and when the type has optional fields not even a cast will compile.
I've tested the below using 1.5.0-beta
interface Foo {
	x?: string;
	y?: number;
}

interface Goo {
	x: string;
	y: number;
}

class Bar<P, T>{
	someVar:T;
	otherVar:P;
}

/* this works */
class SimpleBar extends Bar<Foo,Goo>{

	constructor(){
		super();

		this.otherVar = {
			x: 'def',
			y: 42
		}

		this.someVar = {
			x: 'abc',
			y: 76
		}
	}
}

/* this doesn't */
class TypedBar<S extends Foo, Q extends Goo> extends Bar<Q, S>{

	constructor(){
		super();
		// requires cast to compile, even though the literal is a valid Goo
		this.otherVar = <Q>{
			x: 'def',
			y: 42
		}
		// even a cast doesn't work here (compiler error)
		this.someVar = <S>{
			x: 'abc',
			y: 56
		}
	}
}

Since the object literals meet the requirements of the generic interface I should be able to assign them to the field, but the compiler does not allow this.

Consider this:
interface Baz extends Foo {
    additionalValue;
}

var typedBar: TypedBar<Baz, Baz>;
typedBar.someVar.otherValue; // This is valid

in your example, we know that T is at least a Foo, so
var t: T;
var f: Foo;

f = t; // OK nothing wrong here
t = f; // Error. t can be more than just a foo


Autosize inputs broken

Hi! When renaming files with long path or name there is a bug with input size:

Issue with height property for atom-text-editor[mini]: https://github.com/silvestreh/atom-material-ui/blob/master/styles/editor.less#L12

I don't see whats wrong. Can you elaborate a little more? Seems fine for me.

Yes sure.

But atom by default do auto resize inputs for long text.

When i set height to auto it's look like this:

Welp… I can't seem to reproduce this. Care to share which packages you got installed? Run apm list --installed --bare in a terminal and copy the output.

OOOOK… I managed to reproduce this. You have "soft wrap" enabled in Atom settings. I'll push a fix shortly!

Yes i do :). Thanks!


Request: A quick and easy way to change the font colour and the background colour

Configuration: Windows 10, Lute v. 3.6.0 installed via pip
Hello. I use Lute every day, and I do a lot of reading with it. To ensure that the reading experience always remains as exciting as possible, I like changing the font colour and the background colour often (for example, yesterday I used a navy background with a white font, and today I have a dark grey background with a light yellow font). I do that with the very useful CSS text box in the "Settings" screen, but, since I do that once a day, I started thinking that maybe there can be an easier way to do this. It would be handy if there could be a quick, easy, and constantly accessible way to change the font colour and the background colour. At the moment, it seems to me that an easy and fast way to implement this would be to include two HTML colour pickers in the hamburger menu of the reading screen, one colour picker for the font colour and one colour picker for the background colour. It seems that this would enhance the user experience because the user would then have easy access to two customisation tools which would have great impact on the reading experience. This feature could also appeal to people who have little or no knowledge of coding.
But what happens when the user closes Lute or clears the browser's cache? The font colour and background colour choices will most likely be reset, and some users may dislike having to pick their chosen colour again, every time they restart Lute or clear the browser's cache. It may be useful to save the user's font colour and background colour choices somewhere, perhaps using their hex codes, so that Lute can constantly retrieve them when necessary.
What do you think? I am saying all this as somebody who has a lot of contact with Lute, so I am trying to think of how the user experience could be improved for everybody.
Thank you very much for your hard work. I think that your software is very beneficial.

Hi @Inquisitor-Ignotorum - thanks for the issue and details :-)
I agree that some users would probably prefer this way of setting colors.  You could include font styles in that list of basic settings too.  I'm not sure how these would interact with the themes -- perhaps they'd only override the themes if set.
When set, they'd be stored in user preferences.
I'm unlikely to work on this issue myself soon (too much other stuff to do!) but it's a decent idea and maybe someone will be able to take a look at it.
Work involved:

find a flask color picker extension (perhaps) e.g. https://github.com/mrf345/flask_colorpicker or figure out how to get a js extension for it
user settings to save the colors, checkmarks to override themes
render the css into the base template, after the themes loaded


Update roadmap for 0.5+ release cycle

If it's possible I would like to know which are the short, mid and long term features you guys have planned to include in dex.
By the way is there any blocker features that made impossible to finally cut a stable and production-ready release?
Thanks!

We're currently working on some POCs to resolve some long standing architectural issues. The two binary deployments, storage interface complexity, etc, and hope to open source that work some time next week to accompany a demo in the Kubernetes weekly community meeting.  Those are the main blockers for us committing to a stable, long term release.

Cool, thanks! :)
On Sunday, 7 August 2016, Eric Chiang<EMAIL_ADDRESS>wrote:

We're currently working on some POCs to resolve some long standing
architectural issues. The two binary deployments, storage interface
complexity, etc, and hope to open source that work some time next week to
accompany a demo in the Kubernetes weekly community meeting
https://github.com/kubernetes/community/blob/master/community/README.md.
Those are the main blockers for us committing to a stable, long term
release.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/coreos/dex/issues/539#issuecomment-238102843, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACIPlnCnLekAQ9OYREgoNyL2tZvVO5OXks5qdjFlgaJpZM4JePXD
.

We've now moved to milestones.


Declare pagination module without try-catch

Prevent "Duplicate Reference" error in angular by declaring module outside of try-catch

Looks like you already implemented my suggested changes -- looks great -- thanks!

Yes, it came up in another issue and it became clear that it was not a good pattern. Thanks for your input too.


feat(Bornology): add 2 lemmas

Add Bornology.eventually_ne_cobounded
and Filter.Tendsto.eventually_ne_cobounded.

Thanks!
bors r+


refactor(react-query-devtools): use superjson to display values

Fixes #1552

Codecov Report

Merging #4085 (8d98084) into main (eab6e2c) will increase coverage by 0.42%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #4085      +/-   ##
==========================================
+ Coverage   96.36%   96.78%   +0.42%
==========================================
  Files          45       57      +12
  Lines        2281     2672     +391
  Branches      640      784     +144
==========================================
+ Hits         2198     2586     +388
- Misses         80       84       +4
+ Partials        3        2       -1

Impacted Files
Coverage Δ

src/core/query.ts

src/react/QueryClientProvider.tsx

src/devtools/useLocalStorage.ts

src/core/infiniteQueryObserver.ts

src/core/focusManager.ts

src/devtools/utils.ts

...rc/createWebStoragePersistor-experimental/index.ts

src/react/tests/utils.tsx

src/react/useMutation.ts

src/react/utils.ts

... and 92 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

not sure that there should be so many changes in package-lock.json, also, builds are failing. I would suggest reverting the changes to packge-lock (restoring what we have in main), then running npm install again.

I tried and it produces similar result. Which version of npm should I use? Currently I have to npm i --legacy-peer-deps on 8.18.0.

our .nvmrc uses node v16.14.2, so please use that

sorry, I wanted to wait until we merged our beta branch with bundling changes. If you fix the merge conflicts, I'll merge this PR

yeah, we fixed it immediately. sorry 🙈


Attachment rehosting and dealing with low disk space

its due to diskspace being full from older attachments of tickets closed so it possible when a ticket is created with attachment and a moderator delete the ticket, have the script delete the the old attachment files from /attachments folder

Tickets cannot be deleted at the moment, they just get closed/archived. Deleting attachments from closed tickets would make their logs half useless, so I'd rather look into an option to disable logging entirely (which would then also clean up attachments once the thread is closed).

at least consider adding an option for us to enable/disable it on config.json as some use platform hosting with limited disc space usage or options where it reuploads to imgur whenever you close tickets. with imgur api it should be possible but im not sure how much work it would require though

Alternative hosting solutions for attachments and logs is something I'd definitely like to offer - imgur of course would only support images, but other possible options would be e.g. Google Drive or Dropbox.
I'll look into adding an option to clear old attachments, or to only use Discord's own attachments (i.e. no rehosting at all)!

thanks, i look forward to your next features

would you fancy a donation as an incentive to implement these feature sooner?
currently using your modmail and we receive like 80 tickets per day and we have 3-4 ppl who ended up deleting attachement every 5 hours otherwise bot dies due to disk space :/ it litterally became a chore for us

Hey! The latest update, 2.19.0, added a new attachmentStorage option which can be used to host attachments on discord instead of on the server. If you're still using the bot, give it a try!

thanks for the update but im using different modmail long time ago due to constant daily chore of deleting files, im sure other people will like this though.


use Multiprocessing instead of Threading?

The current implementation use Python Threading. I just wonder if this can be switched using Multiprocessing?
Multiprocessing performs much better on multi-core CPUs than Threading in Python.
Is this possible? did I miss something?

It doesn't matter on single machine since most computations are produced in tensorflow, which don't suffer from GIL. But it could be really nice to investigate the ability to get a distributed async agent learning implementation somehow.

Nowadays even a single machine have multiple cores, but python Threading only use 1, for many application (e.g. in my case) I want to use the extra core to speed up data-generating / loading.

＠mingwugmail python threading does not just use 1 core.
Although it just very often use fewer cores than similar code written in multiprocessing. In the case of A3C I've tried both and multiprocessing is indeed faster.


Use github service account's access token to push charts to Helm repo

https://docs.github.com/en/actions/reference/authentication-in-a-workflow
The GITHUB_TOKEN does not have write access to other repos. Hence we have a personal access token stored as CI_GITHUB_TOKEN that has public_repo perms.
This is a developer's token. We have a service account that should generate a token and we should use that.

all done


Add cache support for FileSystemBackend

Right now the backend doesn’t cache the translations loaded, so on every navigation you could load again a translation you already loaded.
The FileSystemBackend should have a way to pass a cache, with an in-memory default cache, so you can pass them.
In development the cache should be avoided so you can update your JSON files, navigate or reload and get the new translations.

In development the cache should be avoided so you can update your JSON files, navigate or reload and get the new translations.

This doesn't seem to work? Anything that you have to do in particular to make that work?

Custom backends were removed long time ago, current version of remix-i18next uses normal i18next backends so any caching should happen there and outside remix-i18next scope.


Update path dependency constraints to ^1.9.0

Getting conflict with flutter_test dependency hence need to update this constraint. I tried to do it myself and raise a PR but I do not have permission to push the branch.

PR raised - https://github.com/dsc-uob/subtitle/pull/15

Plus one on this, please approve this dudes pr :)


[2.0-preview] setScrollDirection missing from legacy element API

Elements in 1.x had a setScrollDirection method that no longer exists. To work around, call Polymer.Gestures.setTouchAction instead, using a value from this map.

Closing as this now exists (https://github.com/Polymer/polymer/blob/2.0-preview/src/legacy/legacy-element-mixin.html#L276).


Code optimization: manage chakra UI custom themes

Checklist

[ ] understand how extendTheme in chakraUI works
[ ] learn how to customize color themes within chakraUI

See: da0e093ec32af5659510e9b1f5e3f6d221c59883
I de-duped your theme-ing code by moving it up to the root Chakra provider. There was actually already an existing <ChakraProvider> in _app.js
This wraps the whole page, meaning we only need to modify this provider and attach the theme there to set the theme for the entire project.


github-action: use container image for provenance

What does this pull request do?
See https://github.com/elastic/apm-agent-python/pull/2014#discussion_r1576556806
Thanks @trentm
Test
I created a test feature branch:

https://github.com/elastic/apm-agent-python/actions/runs/8813326799

https://github.com/elastic/apm-agent-python/attestations/748017

run docs-build


chore: Remove Standard Honk

Standard Honk was a stepping stone in our development process and has no role in the final architecture of aztec.
Note: Many of the earlier Honk tests were hard coded for Standard. In most cases I've updated those tests to use Ultra. Some tests that I deemed redundant or unhelpful I have removed altogether. (One Sumcheck test that was redundant with the one that followed it, plus two in SumcheckRound that were redundant with relation correctness/consistency + Sumcheck tests)
Checklist:
Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

[ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
[ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
[ ] Every change is related to the PR description.
[ ] I have linked this pull request to relevant issues (if any exist).

I assume stuff like honk_tests now all refers to ultrahonk?

See a few references left to standard_honk_bench

Notice these:
barretenberg/cpp/src/barretenberg/honk/composer/eccvm_composer.test.cpp:namespace test_standard_honk_composer {
barretenberg/cpp/src/barretenberg/honk/composer/eccvm_composer.test.cpp:} // namespace test_standard_honk_composer
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.hpp: * @brief Compute standard honk id polynomials and put them into cache
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.hpp:void compute_standard_honk_id_polynomials(auto proving_key) // TODO(Cody): proving_key* and shared_ptr<proving_key>
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.hpp: * @brief Compute sigma permutations for standard honk and put them into polynomial cache
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.hpp:void compute_standard_honk_sigma_permutations(const typename Flavor::CircuitBuilder& circuit_constructor,
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.test.cpp:    compute_standard_honk_id_polynomials<Flavor>(proving_key);
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.test.cpp:    compute_standard_honk_sigma_permutations<Flavor>(circuit_constructor, proving_key.get());

Notice these:
barretenberg/cpp/src/barretenberg/honk/composer/eccvm_composer.test.cpp:namespace test_standard_honk_composer {
barretenberg/cpp/src/barretenberg/honk/composer/eccvm_composer.test.cpp:} // namespace test_standard_honk_composer
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.hpp: * @brief Compute standard honk id polynomials and put them into cache
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.hpp:void compute_standard_honk_id_polynomials(auto proving_key) // TODO(Cody): proving_key* and shared_ptr<proving_key>
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.hpp: * @brief Compute sigma permutations for standard honk and put them into polynomial cache
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.hpp:void compute_standard_honk_sigma_permutations(const typename Flavor::CircuitBuilder& circuit_constructor,
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.test.cpp:    compute_standard_honk_id_polynomials<Flavor>(proving_key);
barretenberg/cpp/src/barretenberg/proof_system/composer/permutation_lib.test.cpp:    compute_standard_honk_sigma_permutations<Flavor>(circuit_constructor, proving_key.get());

Thanks for taking a look! This PR (and other similar ones) still need a final pass


Fix process_frame to make the last clip satisfy the min_scene_len

Problem
When splitting a video, even though the min_scene_len was set, a video with a shorter length than that was generated.
This problem is related to #150. (I believe that this is a problem that could not be solved with #105.)
Cause
This is because the length of the last clip is not compared to min_scene_len.
Solution
Fixed to pass the length of the entire video (total_frames) to process_frame() and compare the length of the last clip to min_scene_len.

Added some changes for splitting the video starting in the middle.

Thanks for the PR.  Unfortunately this is a breaking API change, so it cannot be merged as-is (v0.5.x is closed for breaking changes now).  Coincidentally I just addressed this case in the v1.0 refactor, so this is already in place for that (short scenes will be merged with their predecessors or successors):
https://github.com/Breakthrough/PySceneDetect/blob/d654c831f7bbb1f0f03b04e27f7f67e479fd84b7/scenedetect/scene_manager.py#L559
However, I think we could achieve the same thing in v0.5 but as a post-processing stage, since the actual # of frames processed may exceed the reported video length.  This could probably be done pretty quickly here:
https://github.com/Breakthrough/PySceneDetect/blob/master/scenedetect/cli/context.py#L326
Then this logic could also be done purely within the command-line and not break the API.  I will mark this as a known issue on the v0.5 API as well.
If you wish to refactor it accordingly let me know, otherwise I can submit a patch to fix it.  Thanks for the PR.

Thank you for your kind reply. I encountered this bug while using the Python API (not using the command line).
I used ContentDetector with threshold set to 7 and min_scene_len set to 180, but a 0.02sec clip was generated for a 50fps video. This bug occurred in several videos, and the common feature was that only the length of the last clip was shorter than min_scene_len. As you wrote, I think it is safer to deal with it in the post-process stage. v1.0 will solve this problem, and I think the Python API support is less important and only the command line should be dealt with in the way you suggested. I'd like to get involved, as it's a rare opportunity, but I can't make time next week, so it'll be in about 10 days, if that's okay with you? If there is no problem, I will create the issue. Finally, I'm very excited about the next v1.0.

Not a problem at all, we're glad to have people like you that are willing to get involved and help out!  I know how difficult it can be to find time to work on open source projects, so no rush.  We really appreciate your help!
One other option that came to mind was, we could add a new argument to get_scene_list() in SceneManager to also set the minimum scene length, and perform this processing stage there (along with drop_short_scenes).  So long as there are default values provided for both of those arguments, then that will not be a breaking change.  The benefit there is that would also fix the Python API while still maintaining backwards compatibility.
I am ok with either approach, and more than willing to consider any other alternatives you might think of or want to explore.  Many thanks for your interest and help with the project!

Closing as a fix for #266 is now in the v0.6 branch which has a new --merge-last-scene option to enable this behaviour.


cassandraCreateSchema job not support specify node to schedule

Requirement - what kind of business use case are you trying to solve?
I hope can set the affinity for cassandraCreateSchema job just like other jaeger components.

Would you be willing to send a pull request?

If there is still value in this I could take it on.

Sorry for the late reply...
@chasekiefer Appreciate it. Hope it been merged soon.


Unable to send anything from my pixel

I am able to discover the macbook but not able to send anything. Getting failed error each time. No errors in MBP console also.

@siddharthalodha  I just tested and works great! I was able to send an image! Pixel 7 pro -> Big Sur

@siddharthalodha, please check if notifications of the app on your MacBook are enabled, that seems to be a common failure point

Hi I tried it just now, Now i am getting the notifications, I click on accept. It creates the file also but it is always 0kb.
The phone shows that it has sent the file but it disappears in few seconds on the system.

I'm also having this issue with my Pixel 7 Pro. I can discover the Macbook Air fine, I'm on the latest Ventura 13.3.1, but when I click the notification to accept the link I'm sending I get the following message:  "Failed to receive files from phone. This operation couldn't be completed. (SwiftProtobuf.BinaryDecodingError Error 3."
Also, is there a way to auto accept?

Doesn't work on pixel 6a either: I don't see the notification and after some time I see a timeout error on the pixel.
Yes: I have enabled notfmification support.

Doesn't work on pixel 6a either: I don't see the notification and after some time I see a timeout error on the pixel.
Yes: I have enabled notfmification support.

It's works fine in my Pixel 6a though. I have used it several times without issue. I'm using it on MacBook Pro M1 Pro with macOS Ventura

Doesn't work on my Pixel 7 either. I'm not able to receive anything on my MacBook Pro M1 Pro with macOS Sonoma (14.0).


Getting mixs-source submodule from tubomam org

My fork removes some of the comments (Occurrence, slot used in packages) as those don't seem helpful in the DataHarmonizer Guidance.
see https://github.com/turbomam/mixs-source/commit/78d1fe9663386332351f5dd08f68844b8ca1adf0
see also #2

Having trouble adding those discarded comments as annotations

the turboman branch should be folded in the GSC org. See https://github.com/turbomam/mixs-source/issues/4

I believe this issue is about doing development in this fork. Closing in preparation of archiving it. Use the main DataHarmonizer repo for development.


Add support kotlin-dsl : build.gradle.kts

Gradle scripts can now be written in kotlin, which provides better IDE support
Reproducing steps
git clone https://github.com/gradle/kotlin-dsl
cd kotlin-dsl/samples/hello-kotlin
$ gw hello
Unable to find a gradle build file named build.gradle

=> the script should also be looking for file build.gradle.kts

This was released in 0.2.0: https://github.com/dougborg/gdub/releases/tag/v0.2.0


feat(schematics): ng update for TuiMapper and TuiMatcher

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Refactoring
[ ] Build or CI related changes
[ ] Tests related changes
[ ] Documentation content changes

What is the current behaviour?
There are an extra type for both TuiMapper and TuiMatcher (TuiTypedMapper and TuiTypedMatcher).
Closes #5560
What is the new behaviour?
This PR wants to erase the need of the TuiTyped* types with the help of Ng Update schematics.

@splincode Sorry, shouldn't we wait with the merge until v4.0 release or will the Ng-Update schematic run even it's in the v4 folder?


Upgrade Package Format to Swift 5.5

Upgrade from the 5.1 manifest to the 5.5 manifest now that Xcode 13
is required for Swift development. This enables better Docc integration
in the package by default.

@swift-ci test


Filter out the default interface from the list passed to the ZoneManager

This PR removes the TODs from the main and controller files and actually creates and updates the zone manager.
It also filters out the default interface from the list passed to the ZoneManager
Note: unit tests to interface_filter.go will be added on a following PR.

Does it know to handle sriov with / without mac ?
(without mac, the name won't exists so we can't create a FQDN for it)

Does it know to handle sriov with / without mac ? (without mac, the name won't exists so we can't create a FQDN for it)

Good point, it doesn't. Let's open a ticket to think how to handle it. Maybe if the status doesn't contain name we should use the interfaceName from the status.

Does it know to handle sriov with / without mac ? (without mac, the name won't exists so we can't create a FQDN for it)

Good point, it doesn't. Let's open a ticket to think how to handle it. Maybe if the status doesn't contain name we should use the interfaceName from the status.

It might conflict between vms even on the same cluster
I think we should just ignore them, and have a note in the readme that mac is needed etc
after all even the name is not supported if mac isnt

Does it know to handle sriov with / without mac ? (without mac, the name won't exists so we can't create a FQDN for it)

Good point, it doesn't. Let's open a ticket to think how to handle it. Maybe if the status doesn't contain name we should use the interfaceName from the status.

ok about the ticket
It might conflict between vms even on the same cluster I think we should just ignore them, and have a note in the readme that mac is needed etc after all even the name is not supported if mac isnt once guest agent provides a solution we can adapt as well imo

I agree, it is written on the ticket.

we need the 3rd commit as it blocks other PRs
zonemgr/zone_manager.go:26:14: Error return value of `zoneMgr.init` is not checked (errcheck)
	zoneMgr.init()
	            ^


handle defaultConsent properly

There are two potential issues with current version in github

it is either documentation was changed again or the defaultConsent handling is broken. If defaultConsent == 0, the vendor is not allowed despite being present in the range. Possible fix to use ^ instead of && here
the single entries are not found in ranges

here are tests for addressed issues
@Test
	public void testRangeDefault0() throws ParseException {
		String consentString = "BONRP7YONRP7YAAABAENAACQAAAAqACAAFAAUACA"; // range: [2, (5,8)]

		ConsentStringParser consent = new ConsentStringParser(consentString);

		assertTrue(consent.isVendorAllowed(2));
		assertTrue(consent.isVendorAllowed(6));

		assertFalse(consent.isVendorAllowed(9));
	}

	@Test
	public void testRangeDefault1() throws ParseException {
		String consentString = "BONRP7YONRP7YAAABAENAACQAAAArACAAFAAUACA"; // range: [2, (5,8)]

		ConsentStringParser consent = new ConsentStringParser(consentString);

		assertFalse(consent.isVendorAllowed(2));
		assertFalse(consent.isVendorAllowed(6));

		assertTrue(consent.isVendorAllowed(9));
	}

	@Test
	public void findSingleEntryInRange() throws ParseException {
		String consentString = "BONRP7YONRP7YAAABAENAACQAAAAqABAAEA"; // DefaultConsent: 0, range: [2]

		ConsentStringParser consent = new ConsentStringParser(consentString);

		assertFalse(consent.isVendorAllowed(2));
	}

Is this resolved by
https://github.com/InteractiveAdvertisingBureau/Consent-String-SDK-Java/commit/81928a53b829217682296ab2ff06243ef12cb142
and
https://github.com/InteractiveAdvertisingBureau/Consent-String-SDK-Java/commit/eb8df16caea32cc0c463d03dffe14a62ed057451

hi. tnx for Maven btw.
the tests attached in the issue description pass with applied fixes 👌. If assume that encoded consent string was swapped with proper encode for defaultValue then old range tests also pass 👌.
the issue is resolved and could be closed. thanks


0.144.4

What this PR does
Bump Iris to 0.144.4

Hey @nathanbrud! Updating the minor dependencies can be added back to the flow now! Feel free bump the minors dependencies here by running pnpm update-deps and subsequently running pnpm install.

@juliewongbandue updated deps


GOG Libray: Update to GOG Galaxy 2.0 Icon

I don't know about this. Because that icon is only for Galaxy client. GOG as a service still uses the old logo and you technically don't need Galaxy client for integration to work.
So I would prefer plugin icon to stay the same and new icon to be used only for that "open client" menu.

You are right, I agree. Changes done


Improve entrypoint and package setup

This pull request is currently for discussion purposes
This is the start of rewriting the scripts/bp cli interface and having it packaged into the bibliopixel package.
It is meant to clean up entry points to make packaging easier, as well as new future development, testing, and continuous integration easier.
There are comments inside each commit with more details if you're interested.
Future discussion/improvement:

Changelog generation should be done using keep-a-changelog
A Git branching model should be adopted such as GitHub-Flow to help track development efforts and push to master regularly
The current code is already formatted for Pep8. It would be good to have developers read a Python style guide revolving around Pep8, such as the Google Python Styleguide.

Further reading for changes in this pull request:

Module metadata variables
Setup.py metadata
Module level dunder names
Importing * from a package
__main__ Entrypoint

Heya!  I unfortunately won't be able to get to this till tomorrow, but I
should be done then before you wake up.  :-)
On Sun, May 13, 2018 at 6:55 PM, Cosmo Borsky<EMAIL_ADDRESS>wrote:

This pull request is currently for discussion purposes
This is the start of rewriting the scripts/bp cli interface and having it
packaged into the bibliopixel package.
It is meant to clean up entry points to make packaging easier, as well as
new future development, testing, and continuous integration easier.
There are comments inside each commit with more details if you're
interested.
Future discussion/improvement:

Changelog generation should be done using keep-a-changelog
https://keepachangelog.com/en/1.0.0/
A Git branching model should be adopted such as GitHub-Flow
https://help.github.com/articles/github-flow/ to help track
development efforts and push to master regularly
The current code is already formatted for Pep8. It would be good to
have developers read a Python style guide revolving around Pep8, such as
the Google Python Styleguide
https://google.github.io/styleguide/pyguide.html.

Further reading for changes in this pull request:

Module metadata variables
http://epydoc.sourceforge.net/manual-fields.html#module-metadata-variables
Setup.py metadata
https://www.python.org/dev/peps/pep-0345/#platform-multiple-use
Module level dunder names
https://www.python.org/dev/peps/pep-0008/#module-level-dunder-names
Importing * from a package
https://docs.python.org/3.5/tutorial/modules.html#importing-from-a-package
main Entrypoint https://docs.python.org/3/library/__main__.html

You can view, comment on, or merge this pull request online at:
https://github.com/ManiacalLabs/BiblioPixel/pull/799
Commit Summary

init.py changes, migrating to a new CLI setup
new_version changes for regex
Start setup.py entrypoint, cleanup, init.py

File Changes

D bibliopixel/VERSION
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-0
(1)
M bibliopixel/init.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-1
(22)
A bibliopixel/main.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-2
(43)
A bibliopixel/cli/command.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-3
(71)
A bibliopixel/cli/init.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-4
(8)
A bibliopixel/cli/version.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-5
(18)
M scripts/new_version
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-6
(25)
M setup.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-7
(108)

Patch Links:

https://github.com/ManiacalLabs/BiblioPixel/pull/799.patch
https://github.com/ManiacalLabs/BiblioPixel/pull/799.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/pull/799, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPdsrly9M7ZqekwoGcF_Kh-X7UuH95kks5tyGWBgaJpZM4T8390
.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com

I too will take a look tomorrow. Long day of travel.
On Sun, May 13, 2018 at 3:37 PM Tom Swirly<EMAIL_ADDRESS>wrote:

Heya! I unfortunately won't be able to get to this till tomorrow, but I
should be done then before you wake up. :-)
On Sun, May 13, 2018 at 6:55 PM, Cosmo Borsky<EMAIL_ADDRESS>wrote:

This pull request is currently for discussion purposes
This is the start of rewriting the scripts/bp cli interface and having it
packaged into the bibliopixel package.
It is meant to clean up entry points to make packaging easier, as well as
new future development, testing, and continuous integration easier.
There are comments inside each commit with more details if you're
interested.
Future discussion/improvement:

Changelog generation should be done using keep-a-changelog
https://keepachangelog.com/en/1.0.0/
A Git branching model should be adopted such as GitHub-Flow
https://help.github.com/articles/github-flow/ to help track
development efforts and push to master regularly
The current code is already formatted for Pep8. It would be good to
have developers read a Python style guide revolving around Pep8, such as
the Google Python Styleguide
https://google.github.io/styleguide/pyguide.html.

Further reading for changes in this pull request:

Module metadata variables
<
http://epydoc.sourceforge.net/manual-fields.html#module-metadata-variables

Setup.py metadata
https://www.python.org/dev/peps/pep-0345/#platform-multiple-use

Module level dunder names
https://www.python.org/dev/peps/pep-0008/#module-level-dunder-names

Importing * from a package
<
https://docs.python.org/3.5/tutorial/modules.html#importing-from-a-package

main Entrypoint https://docs.python.org/3/library/__main__.html

You can view, comment on, or merge this pull request online at:
https://github.com/ManiacalLabs/BiblioPixel/pull/799
Commit Summary

init.py changes, migrating to a new CLI setup
new_version changes for regex
Start setup.py entrypoint, cleanup, init.py

File Changes

D bibliopixel/VERSION
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-0
(1)
M bibliopixel/init.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-1
(22)
A bibliopixel/main.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-2
(43)
A bibliopixel/cli/command.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-3
(71)
A bibliopixel/cli/init.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-4
(8)
A bibliopixel/cli/version.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-5
(18)
M scripts/new_version
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-6
(25)
M setup.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799/files#diff-7
(108)

Patch Links:

https://github.com/ManiacalLabs/BiblioPixel/pull/799.patch
https://github.com/ManiacalLabs/BiblioPixel/pull/799.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/pull/799, or mute the
thread
<
https://github.com/notifications/unsubscribe-auth/AAPdsrly9M7ZqekwoGcF_Kh-X7UuH95kks5tyGWBgaJpZM4T8390
.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/pull/799#issuecomment-388650681,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6p7WDhCAGNLNSJu9dIsq1ECx9BdAks5tyIt2gaJpZM4T8390
.

No rush on this, I'm just putting this PR here so you guys can see some progress on entrypoint/setup/packaging stuff.
Right now it needs more work migrating from the bibliopixel/menu to bibliopixel/cli, since I'm using an object for commands to help clean up the cli/menu code. Here's an example for printing the version info using the object class method.
I've also moved some metadata to __init__.py to clean up other scripts pulling VERSION.

Ah, and Travis fails, finding with flake8 some of the same issues I did, and others I didn't.  :-)

Urg, sorry.  For some reason I did not see the initial statement of the
review, and I missed a lot of the references that would have allowed me to
understand better!
I'm still not getting what substantive new features or reliability
improvements I'm getting from this... :-)

Ah, I'm going to lecture for a bit.  Forgive me, I'm working on a book
too... :-D  This isn't required reading!
About the regexps: after years of bitter experience with my regexps and
those of my colleagues, I decided that most of the time it was an accident
waiting to happen.
We today have these three regexps in the code altogether:
project/aliases.py:6:      SEPARATORS = re.compile(r'([./#]|[^./#]+)')
util/colors/names.py:102:  find = re.compile(r'[A-Z][a-z0-9]+').finditer
util/duration.py:49:       PART_MATCH =
re.compile(r'([0-9.]+)([a-zA-Z]+)').fullmatch
Now, I wrote all of these so I'm not totally against regexps clearly, but I
feel each of these is simple enough that any decent engineer can
immediately understand them.
Regular expressions have a one-to-one correspondence with finite state
automata https://en.wikipedia.org/wiki/Finite-state_machine.  The number
of states in the finite state machine for a regex is actually a really good
measure of the complexity of the regex.
Each of these regexes appear to have exactly four states (which is news to
me).
Still, there are fairly complete unit tests covering them, because I don't
fully trust myself, and because I really want to see that it works.
When I see a line like:
r"version\s*=\s*\'"\['"]"
I can piece together a theory of what it's doing, but am I sure there
aren't edge cases - even possible cases in future! - that don't break it?
If I look at the number of states there, if I count version as one
state, I believe there are 12 states there.  I'm not actually sure I'm
right.
More, such grabs my eye each time I'm scanning through the code looking for
unrelated problems.  And there's no test!
The issue comes because you're trying to parse data out of your Python
code.  Surely much sweeter to store data in data files, and then read it in
in Python code?

I used Jira for years so I know it well.  But consider the situation with
issue tracking.
We can't get rid of the Git issue tracker because that's where people
naturally report issues.  If we announced that we were going to some other
issue tracker, my guess is that 90% of people would still go to Git
issues.  (I have already gone through this in another project...)
The git issue tracker has been working for us.  Browsing by bugs
https://github.com/ManiacalLabs/BiblioPixel/issues?q=is%3Aissue+is%3Aopen+label%3Abug
or
enhancements
https://github.com/ManiacalLabs/BiblioPixel/issues?q=is%3Aissue+is%3Aopen+label%3Aenhancement
is
fairly clear.  More, github allows us the equivalent of Kanban boards for
finer-grained organization, and we haven't even used those much yet.
Recently we've been reporting a lot more than we've been fixing, which is
undesirable, but always happens at some point in a project - but more than
that, moving to another issue tracker isn't going to make us fix issues any
faster.

Ah, I'm not sure that I covered everything.  :-/  I got a bit lost here...
On Tue, May 15, 2018 at 4:58 AM, Cosmo Borsky<EMAIL_ADDRESS>wrote:

@MyNameIsCosmo commented on this pull request.
In setup.py
https://github.com/ManiacalLabs/BiblioPixel/pull/799#discussion_r188153456
:

 },

include_package_data=True,
scripts=['scripts/bp', 'scripts/bibliopixel'],
install_requires=REQUIRED
-)

'include_package_data': True,

'scripts': ['scripts/bp', 'scripts/bibliopixel'],

'entry_points': {

   'console_scripts': ['bibliopixel = bibliopixel.__main__:main', 'bp = bibliopixel.__main__:main']

},
'install_requires': REQUIRED
+}

+setup(**setup_kwargs)
Personal preference, and can be reverted.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/pull/799#discussion_r188153456,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPdsn87JJouIWfTiYWF-sEx-fphb663ks5tykRvgaJpZM4T8390
.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com

Closing this for now as I'm still working on the changes.
I'm going to split this PR into 2 separate branches, one for entrypoint setup (`bibliopixel/__main__.py) and one for CLI improvements.
Here's some main notes for the reasoning behind this PR:
Why?
Besides being able to call python -m bibliopixel from the root of the project folder while in development, it will also help clean up the code.
Installing BiblioPixel also installs the following scripts:
/home/user/Werk/bibliopixel/.env/lib/python3.5/site-packages/scripts/bibliopixel
/home/user/Werk/bibliopixel/.env/lib/python3.5/site-packages/scripts/bp
/home/user/Werk/bibliopixel/.env/lib/python3.5/site-packages/scripts/developer_install
/home/user/Werk/bibliopixel/.env/lib/python3.5/site-packages/scripts/make_bp_help_documentation
/home/user/Werk/bibliopixel/.env/lib/python3.5/site-packages/scripts/make_documentation
/home/user/Werk/bibliopixel/.env/lib/python3.5/site-packages/scripts/make_documentation_live
/home/user/Werk/bibliopixel/.env/lib/python3.5/site-packages/scripts/new_version
/home/user/Werk/bibliopixel/.env/lib/python3.5/site-packages/scripts/send_artnet

This is no good, as it may overwrite other project's scripts, and is typically not a good practice to create folders outside of your package.
Making entrypoints from setup.py to whatever script you need, but keep it packed inside bibliopixel (or bibliopixel_tests) would be preferred. Development scripts should stay inside the repo/source folder, and should not be installed with bibliopixel, unless some developer flag is triggered.
Also, the new CLI entrypoints should improve the speed of command feedback (especially on platforms such as the Raspberry Pi), make it easier to optimize and edit existing commands, make it easy to add commands, and give the potential to implement lazy loading for commands in order to vastly improve the speed of the CLI.
Currently, I'm getting 3 seconds to run bibliopixel --help on my laptop, and 8 seconds on a Raspberry Pi 3 (using ptrace for timing)


Hi, it's me again, the dude that wanted to fix the font

Hey thanks for the help back then, appreciate it a lot. Only a tiny problem now:
The custom CSS import URL is broken: https://crearts-community.github.io/CreArts-Discord/theme.css
Returns a 404 error. Mind taking a look?~

Fixed it, went and used the old link, checked out your folder structure & what changed, and the link turned out to be:
https://crearts-community.github.io/CreArts-Discord/clients/crearts.theme.css
Issue solved~


Dynamically Update GeoJSON Options e.g. Color

I would like to be able to set the color of the geometries inside a GeoJSON layer from a callback
I have tried doing this by setting the output of a callback to be the options property on the layer but it doesn't update
Minimal reproducible example below, trying to change the colour of a triangle via radio buttons:
import dash
import dash_html_components as html
import dash_leaflet as dl
from dash.dependencies import Output, Input
from dash_bootstrap_components import RadioItems

triangle = dict(type='Polygon',
                coordinates=(((-104, 39),
                              (-104, 45),
                              (-90, 39),
                              (-104, 39)),))
geojson_layer = dl.GeoJSON(id='geojson_layer', data=dict(type='FeatureCollection', features=[triangle]))
map = dl.Map([dl.TileLayer(), geojson_layer], center=[39, -98], zoom=4, style=dict(height='50vh'), id="map")

geojson_colours = [dict(label='Green', value='#32a852'),
                   dict(label='Blue', value='#3268a8'),
                   dict(label='Red', value='#cf241b')]
colour_radio = RadioItems(id='colour-radio',
                          options=geojson_colours,
                          value=geojson_colours[0]['value'],
                          className='custom-radio')

app = dash.Dash()
app.layout = html.Div([map, colour_radio])

@app.callback(Output(geojson_layer.id, 'options'), [Input(colour_radio.id, 'value')])
def geojson_colour(colour):
    return dict(color=colour)

if __name__ == '__main__':
    app.run_server()

Ah, yes, that's actually a bug. Thanks for the great example - it made it easy to find the issue. This build should fix the issue,
https://pypi.org/project/dash-leaflet/0.1.2rc4/

Thanks @emilhe!
I have this working now, but I did run into an other hurdle
My actual use case is to update both the data and change the colour based on a single item of user input
This doesn't work from a single callback
Here's the above callback adapted to reproduce this:
@app.callback([Output(geojson_layer.id, 'data'), Output(geojson_layer.id, 'options')],
              [Input(colour_radio.id, 'value')])
def geojson_colour(colour):
    return dict(type='FeatureCollection', features=[triangle]), dict(color=colour)

But I can functionally get what I need by chaining two callbacks together
@app.callback(Output(geojson_layer.id, 'data'), [Input(colour_radio.id, 'value')])
def geojson_data(colour):
    return dict(type='FeatureCollection', features=[triangle])

@app.callback(Output(geojson_layer.id, 'options'),
              [Input(colour_radio.id, 'value'), Input(geojson_layer.id, 'data')])
def geojson_colour(colour, geojson):
    return dict(color=colour)

Ah, yes, i see. I just made a few more tweaks to support that usecase. It should work in the latest build,
https://pypi.org/project/dash-leaflet/0.1.2rc5/
\emher

Great thank-you! That's working now :)

Great! I have now released a version 0.1.3 which should work :)


Bump nyxx + add acronym to guild

Description
Resolves #6
Connected issues & potential other potential problems
-/-
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] Ran dart analyze or make analyze and fixed all issues
[x] Ran dart format --set-exit-if-changed -l 160 ./lib or make format and fixed all issues
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ x I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked my changes haven't lowered code coverage

Can you add changelog? since its gonna be single change in this version

Done

You gotta also change version in pubspec


Hardware-accelerated vulkan in WSL2

Version
Microsoft Windows [Version 10.0.22000.348]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>
Distro Version
Ubuntu 21.04
Other Software
GPU: AMD Ryzen 7 5800U IGPU
AMD drivers version: https://www.amd.com/en/support/kb/release-notes/rn-rad-win-wsl-support (recommended for use with WSL)
vulkaninfo --summary
WARNING: lavapipe is not a conformant vulkan implementation, testing use only.
==========
VULKANINFO
==========

Vulkan Instance Version: 1.2.162

Instance Extensions: count = 18
-------------------------------
VK_EXT_acquire_xlib_display            : extension revision 1
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
VK_EXT_direct_mode_display             : extension revision 1
VK_EXT_display_surface_counter         : extension revision 1
VK_KHR_device_group_creation           : extension revision 1
VK_KHR_display                         : extension revision 23
VK_KHR_external_fence_capabilities     : extension revision 1
VK_KHR_external_memory_capabilities    : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2         : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2       : extension revision 1
VK_KHR_surface                         : extension revision 25
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_wayland_surface                 : extension revision 6
VK_KHR_xcb_surface                     : extension revision 6
VK_KHR_xlib_surface                    : extension revision 6

Instance Layers: count = 3
--------------------------
VK_LAYER_KHRONOS_validation Khronos Validation Layer     1.2.162  version 1
VK_LAYER_MESA_device_select Linux device selection layer 1.2.73   version 1
VK_LAYER_MESA_overlay       Mesa Overlay layer           1.1.73   version 1

Devices:
========
GPU0:
        apiVersion         = 4202691 (1.2.195)
        driverVersion      = 1 (0x0001)
        vendorID           = 0x10005
        deviceID           = 0x0000
        deviceType         = PHYSICAL_DEVICE_TYPE_CPU
        deviceName         = llvmpipe (LLVM 13.0.0, 256 bits)
        driverID           = DRIVER_ID_MESA_LLVMPIPE
        driverName         = llvmpipe
        driverInfo         = Mesa 21.3.0 - kisak-mesa PPA (LLVM 13.0.0)
        conformanceVersion = <IP_ADDRESS>

Repro Steps
Run vulkaninfo --summary
Expected Behavior
I expect vulkan to use the actual GPU in WSL2
Actual Behavior
It uses lavapipe software emulation
Diagnostic Logs
No response

Nice try 😄

There don't seem to be any plans to provide Vulkan natively. The link https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12209 may help.

llvmpipe  is CPU..

Anyone attempting WSL2 Vulkan Nvidia?

Problem using WSL2 running Godot4 vulkan using llvmpipe

Problem using WSL2 running Godot4 vulkan

Version
Microsoft Windows [Version 11.0.22000.556
WSL Version

[x] WSL 2
[ ] WSL 1

Distro Version
Ubuntu 20.04
$ vulkaninfo --summary

WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Failed to CreateInstance in ICD 2.  Skipping ICD.
WARNING: lavapipe is not a conformant vulkan implementation, testing use only.
==========
VULKANINFO
==========

Vulkan Instance Version: 1.3.204

Instance Extensions: count = 18
-------------------------------
VK_EXT_acquire_xlib_display            : extension revision 1
VK_EXT_debug_report                    : extension revision 9
VK_EXT_debug_utils                     : extension revision 2
VK_EXT_direct_mode_display             : extension revision 1
VK_EXT_display_surface_counter         : extension revision 1
VK_KHR_device_group_creation           : extension revision 1
VK_KHR_display                         : extension revision 23
VK_KHR_external_fence_capabilities     : extension revision 1
VK_KHR_external_memory_capabilities    : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2         : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 1
VK_KHR_get_surface_capabilities2       : extension revision 1
VK_KHR_surface                         : extension revision 25
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_wayland_surface                 : extension revision 6
VK_KHR_xcb_surface                     : extension revision 6
VK_KHR_xlib_surface                    : extension revision 6

Instance Layers: count = 10
---------------------------
VK_LAYER_KHRONOS_profiles         Khronos Profiles layer                              1.3.204  version 1
VK_LAYER_KHRONOS_synchronization2 Khronos Synchronization2 layer                      1.3.204  version 1
VK_LAYER_KHRONOS_validation       Khronos Validation Layer                            1.3.204  version 1
VK_LAYER_LUNARG_api_dump          LunarG API dump layer                               1.3.204  version 2
VK_LAYER_LUNARG_device_simulation LunarG device simulation layer                      1.3.204  version 1
VK_LAYER_LUNARG_gfxreconstruct    GFXReconstruct Capture Layer Version 0.9.11-unknown 1.3.204  version 36875
VK_LAYER_LUNARG_monitor           Execution Monitoring Layer                          1.3.204  version 1
VK_LAYER_LUNARG_screenshot        LunarG image capture layer                          1.3.204  version 1
VK_LAYER_MESA_device_select       Linux device selection layer                        1.2.73   version 1
VK_LAYER_MESA_overlay             Mesa Overlay layer                                  1.1.73   version 1

Devices:
========
GPU0:
        apiVersion         = 4202691 (1.2.195)
        driverVersion      = 1 (0x0001)
        vendorID           = 0x10005
        deviceID           = 0x0000
        deviceType         = PHYSICAL_DEVICE_TYPE_CPU
        deviceName         = llvmpipe (LLVM 10.0.0, 256 bits)
        driverID           = DRIVER_ID_MESA_LLVMPIPE
        driverName         = llvmpipe
        driverInfo         = Mesa 22.0.0-devel (git-f4c426422b) (LLVM 10.0.0)
        conformanceVersion = <IP_ADDRESS>
        deviceUUID         = 00000000-0000-0000-0000-000000000000
        driverUUID         = 00000000-0000-0000-0000-000000000000

Vulkan through WSLG - Not Yet

@agluszak @procedural @engineer1109
The latest WIP hardware-accelerated Vulkan in WSL2 ( through Dozen over Directx12)

hardware accelerated Vulkan now works in WSL2

https://github.com/microsoft/wslg/issues/40#issuecomment-1685123693

Is there any guide on how to actually install dozen on WSL2 (Ubuntu) ?

https://github.com/microsoft/wslg/issues/40#issuecomment-2037539322

Oh wow, that was surprisingly easy. Thank you!

sudo add-apt-repository ppa:kisak/kisak-mesa
sudo apt update
sudo apt upgrade

microsoft/wslg#40 (comment)

Many thanks! It works! I can finally run the isaamgym in wsl2!!! ❤

sudo add-apt-repository ppa:kisak/kisak-mesa
sudo apt update
sudo apt upgrade

microsoft/wslg#40 (comment)Microsoft/WSLG#40 （注释）

Many thanks! It works! I can finally run the isaamgym in wsl2!!! ❤非常感谢！它有效！我终于可以在 wsl2 中运行 isaamgym!!❤

How to run isaac sim in wsl2? I tryed the same cmd, isaac sim seems to start up but finally crushed with OUT OF MEMORY error
2024-04-28 04:44:41 [29,267ms] [Warning] [omni.particle.system.core.scripts.extension]
            ATTENTION!: omni.particle.system.core is currently undergoing extensive (breaking) changes.
            Please be aware that systems built with the existing extension will need to be rebuilt in
            the USD Composer 2023.2 release.
[29.299s] [ext: omni.kit.sequencer.core-103.4.0] startup
[29.323s] [ext: omni.anim.widget.timeline-0.1.8] startup
[29.363s] [ext: omni.kit.quicksearch.actions-0.8.11] startup
[29.369s] [ext: omni.kit.converter.cad_core-200.1.0-rc.22] startup
LLVM ERROR: out of memory
2024-04-28 04:44:42 [0ms] [Warn] [carb.crashreporter-breakpad.plugin] [crash] A crash has occurred.  If a debugger should be attached, please set the '/crashreporter/debuggerAttachTimeoutMs' setting to a timeout in milliseconds.  This can be used to allow the crash reporter to wait for up to that long for a debugger to attach before processing or sending the crash report.
prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY) failed: 22/Invalid argument
prctl(PR_SET_PTRACER, 0) failed: 22[1]    170596 segmentation fault  ./isaac-sim.sh --reset-user

sudo add-apt-repository ppa:kisak/kisak-mesa
sudo apt update
sudo apt upgrade

microsoft/wslg#40 (comment)

Many thanks! It works! I can finally run the isaamgym in wsl2!!! ❤

Same here. How did you get isaac-gym working in wsl2? I've been trying to get isaac sim working in wsl2 and I keep running into segmentation faults. I tried installing the repository but that didn't do anything.

@GeorgeS2019 many thanks it helped me so quickly, I was following a vk tutorial and when came the moment to render something real, the performances were horrible. Solved it instantly !

sudo add-apt-repository ppa:kisak/kisak-mesa
sudo apt update
sudo apt upgrade

microsoft/wslg#40 (comment)

Totaly works fine! Thanks.

I've been searching all over and this thread looked promising.  I've tried everything here but still can't seem to get my chrome browser to use GPU rendering.  I'm running Ubuntu 24.04 with WSL version: <IP_ADDRESS>, and an RTX 4090 mobile GPU.
I am using a custom XServer with GWSL.
glxinfo -B | grep OpenGL
OpenGL vendor string: Mesa
OpenGL renderer string: llvmpipe (LLVM 17.0.6, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 24.3.1 - kisak-mesa PPA
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.5 (Compatibility Profile) Mesa 24.3.1 - kisak-mesa PPA
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.3.1 - kisak-mesa PPA
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

google-chrome

(google-chrome:2848): Gtk-WARNING **: 22:21:39.691: Failed to parse /home/rbower/.config/gtk-3.0/settings.ini: Key file does not start with a group
WARNING: dzn is not a conformant Vulkan implementation, testing use only.
WARNING: dzn is not a conformant Vulkan implementation, testing use only.
[2885:2885:1218/222143.544706:ERROR:angle_platform_impl.cc(44)] Display.cpp:1062 (initialize): ANGLE Display::initialize error 12289: Invalid visual ID requested.
ERR: Display.cpp:1062 (initialize): ANGLE Display::initialize error 12289: Invalid visual ID requested.
[2885:2885:1218/222143.545418:ERROR:gl_display.cc(497)] EGL Driver message (Critical) eglInitialize: Invalid visual ID requested.
[2885:2885:1218/222143.545513:ERROR:gl_display.cc(767)] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type
[2885:2885:1218/222143.546295:ERROR:angle_platform_impl.cc(44)] Display.cpp:1062 (initialize): ANGLE Display::initialize error 12289: Invalid visual ID requested.

Any ideas?


🪲BUG 🪲

Description
Describe the bug:
The content of the header in the rest of the pages except the home page is not aligned properly.
Expected behavior:
It should be aligned properly.
Reproduction Steps
Steps to reproduce the behavior:

Go to 'https://akshitagupta15june.github.io/Moksh/AR_Meditate/meditation.html'
See error

Screenshots

Additional Information
Device (please complete the following information):

OS: Windows
Browser: Chrome
Version:  22

@akshitagupta15june
Can you Please assign the issue to me?


Add minimum compiler versions to the cmake configuration

This pull request adds minimum version requirements for the GNU gfortran and Intel ifort compilers.
As @bjonkman points out here:
There are some known compiling errors that were documented in the Compiling Instructions for FAST8:

1. The version of gfortran must be at least 4.6.0. NWTC Library uses some quad-precision
variables, which are not supported in earlier versions of gfortran.

Possible workarounds: You might be able to set QuKi to some other supported real kind that is not
4 or 8 (not sure REAL(2) is supported, but you could try); otherwise, you'd have to set QuKi to 4 or
8 and remove the QuKi MODULE PROCEDURE lines from all the INTERFACE blocks at the top of the
NWTC Library source files.

2. Intel Fortran must be version 11 or later. NWTC Library uses the gamma() function, which is not
provided in earlier versions.

Possible workarounds: You can write your own gamma() function in the SysI*.f90 files, or remove
the calls to gamma() (e.g., set nwtc_gamma = 1) and avoid using IceDyn and the wave spreading
features of HydroDyn.

It is recommended to put a minimum version requirement for both gfortran and ifort compilers in
cmake.

This pull request is a fix for issue #88 and regression tests are not required as this does not affect the calculations.

@sayerhs thanks for pointing that out, done.


[PE-D][Tester C] Lack of Date Format Hint in Program and Unclear Error Message for Date Input

When entering dates, users may not be aware of the required format (e.g., DD/MM/YYYY or MM-DD-YYYY), as the program does not display this information. If an incorrect date format is entered, the error message does not clarify the expected format, making it challenging for users to correct their input.

Labels: type.FeatureFlaw severity.Medium
original: iamdiluxedbutcooler/ped#29

Will need to modify user facing text, so cannot fix this

Not an issue, the error message shows "Invalid command format" because you did not include the wedding index to edit, if the wedding index is included then the proper date formatting error is shown.


Please verify that both the operating system and the processor support Intel(R) MOVBE, F16C, FMA, BMI, LZCNT and AVX2 instructions.

Hello,
I got an error " Please verify that both the operating system and the processor support Intel(R) MOVBE, F16C, FMA, BMI, LZCNT and AVX2 instructions." when I run YASK.
Following is the command:
mpirun-n 2 -ppn2 ./stencil-run.sh -arch hsw---nr 1 -nrx 2 -d 1024 -dx 512 -b 64 -bz 96
CPU : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
MIC  : Intel Xeon Phi coprocessors 5110P
Thanks for your help.

The Intel(R) Xeon(R) CPU E5-2670 does not support AVX2. Please try compiling with 'arch=snb' and running with '-arch snb'.

It works. Thank you very much.

You're welcome.


Update derive_last_dose()

[ ] Implement a general function which adds source variables from EX dataset like done within derive_last_dose()
[ ] Implement wrapper functions for last date, last dose, last dose group, ...

@bundfussr, @koegerr , @aehmann-gsk  The first task here - Implement a general function which adds source variables from EX dataset like done within derive_last_dose() .  Is this supposed to reference another function and not the function I am updating?

Hi @bms63 , the general function is a new function. The code should be almost the same as the current code of derive_last_dose().  The difference is that the variables from EX are added without any transformation, e.g., it would add EXENDTC instead of converting it to  a date or datetime variable.
The conversion is done in the updated derive_last_dose() function, which calls the general function to add EXENDTC and then converts the DTC variable to a DT or DTM variable.


Tooltip behavior

If I am at the top of the page, and then I click the first tooltip, it scrolls the page down so the top half of the tooltip is hidden. Also, I should be able to close the tooltip by clicking the tooltip icon a second time (when the tooltip is open).

Hi @astridu I am unable to replicate this error on development with the ld4p:RT:bf2:Monograph:Work:Un-nested template using Firefox. Could you describe what template you are using and what environment you are in? Thanks!

I also cannot replicate on chrome. I tried with different records and resource templates, and still nothing. I will close this one.


Paul/FREYA-746

Add last updated date to dashboard cards
Reorder dashboard cards by most recent update date
Add filter menu to the dashboard index page
Display the three most recently updated dashboards on the homepage

Just to make it clear, I remove the list of dashboards to be displayed in the homepage from the dashboard template.
So initially, all of the dashboards are displayed in the homepage and I added a condition at the end of the function processDashboardCards to only keep the three most recent one.
It's not super elegant, but this is the solution that required the least amount of modifications or special conditions... At the end it falls under the top banner short "flicker", so not more noticeable than that.

Same goes for the topic pages as the same script is used

All done @senthil10, if you want to give it one last final check

Translation for filter labels added.
@LianeHughes I squashed your commit into the latest one for consistency of the git history once merged :)