WIP: external_deps/build.sh improvements

Some WIP improvements for external_deps/build.sh:

fallback on wget if curl fails (macOS curl fails to download ogg tarball from Xiph, same with Homebrew curl and own build curl);
fix jpeg build on macOS by using own-build nasm instead of system one;
basic introspection (each platform declares itself, each package declares for which platform it is enabled by default, etc.);
make possible to build defaults which build all required packages for the given platform (introspection);
detect and report properly unsupported platform and unsupported packages (introspection);
autodocumented built-in help (introspection).

Note: macOS users require a file system with locking supported. This is required for mounting sdl2 .dmg files and to build geoip (job compilation control and temporary file creation done by geoip build system relies on locking). When building over NFS, if locking does not work, one may mount with -o locallocks to emulate the required file system feature.
Unfortunately the introspection feature (both used for the defaults feature, troubleshooting and built-in help) makes use associative array feature from bash, which is believed to be shipped in bash starting with bash 4 but macOS only ship bash 3. Homebrew ships bash 5 anyway.

This:
	sed -e 's/\\t/\t/g' <<-EOF
	Usage: $(basename "${0}") <platform> <package[s]…|command[s]…>

	Script to build dependencies for platforms which do not provide them.

	Platforms:
	$(print_platforms)

	Packages:
	$(print_packages)

	Packages required for each platform:
	$(print_packages_per_platform)

	Meta-package (build all required packages for the given platform):
	\tdefaults

	Commands:
	$(print_commands)
	EOF

Produces this:
Usage: build.sh <platform> <package[s]…|command[s]…>

Script to build dependencies for platforms which do not provide them.

Platforms:
	linux64: Linux amd64 native compilation
	macosx64: macOS amd64 native compilation
	mingw32: Windows i686 cross-compilation from Linux
	mingw64: Windows amd64 cross-compilation from Linux
	msvc32: Windows i686 native compilation
	msvc64: Windows amd64 native compilation

Packages:
	nasm zlib gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis speex opus opusfile lua ncurses wasisdk wasmtime naclsdk naclports gendef

Packages required for each platform:
	linux64: zlib naclsdk naclports
	msvc32: nasm zlib gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis speex opus opusfile lua naclsdk naclports
	mingw64: nasm zlib gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis speex opus opusfile lua naclsdk naclports
	msvc64: nasm zlib gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis speex opus opusfile lua naclsdk naclports
	mingw32: nasm zlib gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis speex opus opusfile lua naclsdk naclports
	macosx64: nasm gmp nettle sdl2 glew png jpeg webp freetype openal ogg vorbis speex opus opusfile lua naclsdk naclports
	unused: ncurses wasisdk wasmtime gendef

Meta-package (build all required packages for the given platform):
	defaults

Commands:
	clean: Remove products of build process, excepting download cache. Must be last.
	package: Create a zip/tarball of the dependencies so they can be distributed.
	install: Create a stripped down version of the built packages that CMake can use.

It even detects packages that are not enabled by any known platform.

So, I'm now able to fully build macOS deps myself (something I never achieved before).
And I'm also able to fully build Unvanquished (something I never achieved before) using the built deps, that means building and run both engine, dll game, and nexe game.
@slipher do you think it's OK to require macOS users to upgrade their bash with Homebrew or should we find a way to workaround this, even if that means going super ugly like emulating associative arrays with temporary files?
One thing is that I didn't managed to run any of my own engine build in repository build directory using prebuilt deps files (but it works if I move the built engine binary to where the updater installed the game). So maybe I'm missing some instructions to make me able to run  in repository build directory my own engine build with deps built by something else, but maybe macOS coders may want to build their own deps as well.

I remember @cu-kai had trouble to build s/cgame as nexe on macOS, I was able to build and run some by compiling against deps built using that modifed script. I don't know if I fixed something, or if the deps files were actually outdated. For example the current macOS macosx64-5.tar.bz2 deps archive provide libOpenAL 1.18.2 but the script builds libOpenAL 1.21.1. So maybe NaCl was also outdated?

I think you can do the 'defaults' feature with a simple implementation instead.
Like
macosx64_defaults='foo bar'
mingw32_defaults='foo bar baz'
def build_defaults() {
  for p in ${PLATFORM}_defaults
    build_${p}
  done
}

One thing is that I didn't managed to run any of my own engine build in repository build directory using prebuilt deps files (but it works if I move the built engine binary to where the updater installed the game). So maybe I'm missing some instructions to make me able to run in repository build directory my own engine build with deps built by something else, but maybe macOS coders may want to build their own deps as well.

Run the build.sh macosx64 install command, which will organize the deps into ${PWD}/macosx64-5. Then configure CMake with -DEXTERNAL_DEPS_DIR=${PWD} where PWD is the current directory when you built the deps.

I think you can do the 'defaults' feature with a simple implementation instead.
Like […]

Yeah, I know about that, but then you have to hardcode any platform in a variable, and then you have to maintain a package list per platform instead of enabling/disabling a platform per package. This looks more prone to errors and mistake to me, that's why I went the associative array way at first.

Run the […]

Hmm, there is misinterpretation. I successfully built and run my own dæmon/unvanquished build with my own deps. What does not work is running a build done using autodownloaded deps. It builds, but it doesn't run. I'm probably facing some issues about the deps being self-signed by @DolceTriade's computer or something like that, and I don't know how to disable the security for the build folder (if it's possible).

I'm probably facing some issues about the deps being self-signed by @DolceTriade's computer or something like that, and I don't know how to disable the security for the build folder (if it's possible).

I think that stuff only happens for stuff downloaded in a browser, not with e.g. curl. But if you are having that stuff somehow, it is related to some file attributes on the directory. You have to list the extended file attributes and check if there is one like com.apple.something and remove that.
Note that the caution about CMake cache variables still applies. If you used your own deps in a build at first and then switched to prepackaged ones, then old paths will be stored in the cache and you need to wipe your build dir.

Yeah, I know about that, but then you have to hardcode any platform in a variable, and then you have to maintain a package list per platform instead of enabling/disabling a platform per package.

OK but this minor point of taste is not worth adding a new dependency over. Note that the per-platform lists are "hard-coded" into the help string, so if you use the variables in the help string then you have no more such lists than before :)

(my latest push was just some bikeshedding)

Note that the per-platform lists are "hard-coded" into the help string.

Not anymore, all the lists in the help message are now fully generated.

I was able to avoid the usage of associative arrays by doing eval magic to create the equivalent of your suggested macosx64_defaults variables on the fly. So the script now works with macOS old GPLv2 bash 3.2.57.

This kind of stuff is awfully unreadable:

register_command() {
 local command_name="${1}"
 local command_string="${2}"

 if ! echo "${command_list_string}" \
 	| to_list \
 	| egrep -q "^${command_name}"
 then
 	if ! [ -z "${command_list_string}" ]
 	then
 		command_list_string+=' '
 	fi

 	command_list_string+="${command_name}"
 	eval "command_${command_name}_string='${command_string}'"
 fi
}

It's really not worth adding hundreds of lines of code to avoid writing required dependencies in a single list. It's just over-engineering.

It looks like using strings allows to write much simpler code… After all unix shell is all about strings. For example there are many situations where I don't need to convert arrays to string again, since they are strings built properly from the beginning. So I simplified a lot the code. The sum of all registration functions are now 32 lines long.

avoid writing required dependencies

@slipher the purpose is not to avoid writing dependencies, the purpose is to have the code checks for mistakes by itself, and prevent list rotting. Also there are less platforms than packages, so it's more safe to list platforms per packages than packages per platforms: it means more lists but those lists are less long to read and those lists are local to the package they're about.
Even if we were listing packages per platform, I would reuse the same functions to validate the lists properly (they would just read lists the other way).

Personally I'm not a fan of register_command or register_package; I'd rather have the script be smaller and simpler. Let's get a third opinion?
Supposing we went forward with register_package, I'd want to see a distinction between a package being unavailable on a given platform, and available but not part of the default build. I'd find it confusing that a package may be implemented for other platforms than the ones listed in the register_package line.

I ran the build recently on macOS Monterey (x86_64) and was able to produce working binaries, not sure if this helps now?

Supposing we went forward with register_package, I'd want to see a distinction between a package being unavailable on a given platform, and available but not part of the default build. I'd find it confusing that a package may be implemented for other platforms than the ones listed in the register_package line.

With latest commit you can build required, optional or all.
Note that “available but not required” was not fully documented, I tried to guess.

This looks ready to me.

I guess we're still waiting for that third opinion on registration stuff.

To be honest, I couldn't easily grasp what this register_package was about. i think it could at least use a comment in the source code.

@necessarily-equal I added comments explaining what the register_* commands do.

Question:
	linux64: Linux amd64 native compilation
	macosx64: macOS amd64 native compilation
	mingw32: Windows i686 cross-compilation from Linux
	mingw64: Windows amd64 cross-compilation from Linux
	msvc32: Windows i686 native compilation
	msvc64: Windows amd64 native compilation

When building on Windows without MSVC, for example with MSYS2/MingW, is it mingw that is used?

When building on Windows without MSVC, for example with MSYS2/MingW, is it mingw32/mingw64 package that is used?

Yes. So your quoted text is inaccurate.

The initial text was “Linux to Windows cross-compile”, I'll fix that.

With following changes this PR is supposed to fail until we rebuild new packages (we may also investigate rebuilding the packages instead of downloading them when the package build script is modified).
I propose renaming package using triplets and using _ as version separator. The triplet I suggest is <system>-<architecture>-<compiler>, where system can be linux, windows or macos, where architecture can be amd64 or i686, and where compiler can be msvc or mingw on Windows, default on other systems.
I also removed speex building as it seems to not be used anymore, removed theora references as it is not used anymore, and removed geoip building and made it disabled by default (but code to use it is still there, nuking it is outside of the scope of this PR).
./build.sh -h
Usage: build.sh [PLATFORM] [SELECTION]… [PACKAGE]… [COMMAND]…

Script to build dependencies for platforms which do not provide them.

Platforms:
	linux-amd64-default: Linux amd64 native compilation
	macos-amd64-default: macOS amd64 native compilation
	windows-amd64-mingw: Windows amd64 MingW compilation or cross-compilation from Linux
	windows-amd64-msvc: Windows amd64 native compilation
	windows-i686-mingw: Windows i686 MingW compilation or cross-compilation from Linux
	windows-i686-msvc: Windows i686 native compilation

Selections:
	required  (build required packages for the given platform)
	optional  (build optional packages for the given platform)
	all       (build all available packages for the given platform)

Packages:
	pkgconfig nasm zlib gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis opus opusfile lua ncurses wasisdk wasmtime naclsdk naclports gendef

Required packages per platform:
	linux-amd64-default: zlib naclsdk naclports
	macos-amd64-default: pkgconfig nasm gmp nettle sdl2 glew png jpeg webp freetype openal ogg vorbis opus opusfile lua naclsdk naclports
	windows-amd64-mingw: nasm zlib gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis opus opusfile lua naclsdk naclports
	windows-amd64-msvc: pkgconfig nasm zlib gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis opus opusfile lua naclsdk naclports
	windows-i686-mingw: nasm zlib gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis opus opusfile lua naclsdk naclports
	windows-i686-msvc: pkgconfig nasm zlib gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis opus opusfile lua naclsdk naclports

Optional packages per platform:
	linux-amd64-default: pkgconfig gmp nettle curl sdl2 glew png jpeg webp freetype openal ogg vorbis opus opusfile lua ncurses wasisdk wasmtime
	macos-amd64-default: zlib curl ncurses wasisdk wasmtime
	windows-amd64-mingw: pkgconfig ncurses wasisdk wasmtime
	windows-amd64-msvc: ncurses wasisdk wasmtime gendef
	windows-i686-mingw: pkgconfig ncurses wasisdk wasmtime
	windows-i686-msvc: ncurses wasisdk wasmtime gendef

Unused packages:
	ncurses wasisdk wasmtime gendef

Commands:
	install: Create a stripped down version of the built packages that CMake can use.
	package: Create a zip/tarball of the dependencies so they can be distributed.
	clean: Remove products of build process, excepting download cache. Must be last.

Example:
	build.sh linux-amd64-default required ncurses wasisdk wasmtime install package clean

The geoip library should not be deleted from build.sh before it is removed from the engine.

Is it a problem to not ship GeoIP if building against it is disabled by default?
Anyway it's better to remove GeoIP in another PR. If we prefer to keep it, I can drop the commit here in all case.

I removed the commit to not build and package geoip for now.

One of the changes I may have forget to list there is that the linux package will use xz instead of bzip2 to compress the archive.

Good to know: 7z (which compresses zip better than zip) adds symlinks to zip without dereferencing them, which seems to make CMake fail on Windows:
-- Downloading dependencies from 'https://dl.unvanquished.net/deps/windows-amd64-msvc_6.zip'
[…]
-- [download 100% complete]
-- Download completed successfully
CMake Error: Problem with archive_read_next_header(): Unsupported ZIP compression method during decompression of link entry (8: deflation)
CMake Error: Problem extracting tar: C:/projects/daemon/build/CMakeFiles/windows-amd64-msvc_6.zip
CMake Error at CMakeLists.txt:450 (message):
Could not extract windows-amd64-msvc_6.zip
-- Configuring incomplete, errors occurred!
See also "C:/projects/daemon/build/CMakeFiles/CMakeOutput.log".
See also "C:/projects/daemon/build/CMakeFiles/CMakeError.log".
Command exited with code 1

It looks like 7z doesn't have option to dereference symlinks, but symlinks can be dereferenced at install time anyway.

Now on Windows I get a Zlib that is both seen and unseen at the same time: “Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11")”.
Example:
-- Downloading dependencies from 'https://dl.unvanquished.net/deps/windows-amd64-msvc_6.zip'
[…]
-- [download 100% complete]
-- Download completed successfully
-- Found OpenGL: opengl32
CMake Error at C:/Program Files/CMake/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11")
Call Stack (most recent call first):
  C:/Program Files/CMake/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  C:/Program Files/CMake/share/cmake-3.23/Modules/FindZLIB.cmake:120 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:547 (find_package)
-- Configuring incomplete, errors occurred!
See also "C:/projects/daemon/build/CMakeFiles/CMakeOutput.log".
See also "C:/projects/daemon/build/CMakeFiles/CMakeError.log".
Command exited with code 1

It looks like when I build msvc stuff on Linux it produces .a files instead of .lib files and then they get removied at install time.

In fact I also get this behavior with old build.sh from before this PR, this is not a bug I introduced. 🤔

It looks like the only .lib files I get are the ones from SDL2 because the script downloads a prebuilt SDL2 for Windows. Every lib I build myself is producing .a files instead.

@slipher do you know how to build the windows-msvc archives? Is it even possible on Linux or it is required to do it on Windows, and if Windows is required, can it be done with mingw or msvc is required?

@slipher do you know how to build the windows-msvc archives? Is it even possible on Linux or it is required to do it on Windows, and if Windows is required, can it be done with mingw or msvc is required?

It's required to do it on Linux, except there's this one little part that you have to do on Windows IIRC.

It's required to do it on Linux, except there's this one little part that you have to do on Windows IIRC.

Do you have more information about that one little part. I have a Windows vm and if I can do it that would be nice (also I would just like to know about it anyway).

I continue there the thread started here https://github.com/DaemonEngine/Daemon/pull/629#issuecomment-1138270937 because this thread talks about the present PR:

@illwieckz:
I'm gonna merge https://github.com/DaemonEngine/Daemon/pull/561 in all cases, so cherry-picking instead of rebasing makes everyone's life harder with the only benefit of increasing the risk of introducing mistakes.

@slipher
Why? AFAIK no one else said they liked the package registration stuff.

@illwieckz
No one else expressed any opinion against it as well.
And it fulfills my need of a script that acts consistently with the documentation by design because the documentation is produced by the same code that does the actions.

@slipher
Usually we consider that a pull request should have a favorable review before being merged. More people should be for the change than against it.

It looks like no one cared about this script before I took it for a ride. I'm unhappy that bash doesn't make it easy to make it clean and more unhappy that macos distributes a very obsolete bash making things more hackish, but that drawback is worth the reliability acquired. Also this is really appreciable to be able to build required, optional or all. I don't like the bash wizardry involved but that's a cost I cannot avoid.
So basically there is ~60 lines of complex code working around bash (and obsolete macos bash) limitations to implement kind of associative arrays, and then we just add nice annotations for every platform and packages at the exact same place they are defined, and then the script becomes aware of what is for what, being able to check for platform mistakes, package mistakes, select per-platform packages required or not, list platforms and packages, etc.
Note: I would not be against porting this to another language like python in the future to get rid of the bash wizardry.

OK, so we can write down a list of optional packages, and make required and optional pseudo-packages. And this will take, say, 10 lines of simple code to give the desired functionality of register_package.
AFAICT register_command and register_platform don't give us any functionality we don't already have.
Seeing the package name gendef, I recall that it is related to the bit that has to run on Windows, but I don't recall exactly how it works.

The hardcoded list solution, while looking simple at first glance, carry many issues:

it breaks the principle of locality, the way things are used are not defined where they exist (that was the very first problem that makes me deciding to investigate this, as I had no way to trust the lists).
there is no validation of what's in them.
the build order has to be replicated as much as there are platforms, with the big drawback each platform doesn't have the same package list so adding or removing one package requires a very different edit (that's the thing that is calling for trouble the most).

For the last point, the build order may be important (for example we build nasm, and we may need nasm to build other things), with his implementation to change the build order of a package we would just move up or down the related package block, same for inserting a new package in the build order, just insert it once after the one it needs and/or before the one that needs it, and forget everything about platforms, and optional, all, required lists…
If we hardcode all, optional and required lists, those problems skyrocket, we would litterally add levels of complexity the human mind have to process when editing the lists, like adding a package or changing the build order, or make some optional. That ugly bash code exists to delegate this tasks from human's mind responsibility to an automaton and prevent the human to do mistakes by solving multi-level complexity problem (basically an equation with several unknowns). Doing the lists by hand is like considering every package is an unknown, and every (all, optional, required) set per platform is an equation line, and solving that equation by hand.

register_package doesn't do anything at all to solve the dependency problem! It does not declare any dependencies between packages and just works the same way as the current hard-coded list in the help - just listing packages in the order they are defined in the file. The only difference being the user has to wade through a soup of inscrutable Bash nonsense to tell what order the packages will be built in. And maintaining a topological sort of the packages (i.e. a sequence respecting dependencies) is better how it is now - you edit a list at a single place in the file, while with register_package it would apparently involve looking at the whole file and copy-pasting around the entire build_xxx functions (assuming you wanted to keep them next to their register_package statements).
The all list can absolutely be the concatenation of required and optional, because a required package obviously shouldn't depend on an optional package. (The 'optional' concept doesn't even exist for platforms other than Linux, by the way. Unless you count WASM which simply isn't used for anything.)

Since I was asked to comment on this PR... let's go.
For a start, I think this PR could easily be split. The improved feedback, the removal of geoip and speex, the use of $(...) instead of the backticks (`), the comments...
Those changes are not subject to any questioning I think.
As  for the  stuff subject to questions, I'm not sure which problem exactly this script is meant to solve so I'm hardly able to express any useful opinion.
From what I read from comments, it's about implementing features which are missing in Apple's OSes (apple, again giving troubles...).
Would it not be easier to just install a non-outdated bash on those instead?
A diff shows 3 big blocks of added code. Reading bash code is not really my fun, but I certainly find code like this:
register_command() {
  if ! to_lines "${commands:-}" | egrep -q "^${1}"; then
    commands+="${commands:+ }${1}"
    eval "command_${1}='${2}'"
  fi
}

Not readable. The reason is probably that I can't decipher what to_lines does. No, I'm not able to understand what echo "${@// /$'\n'}"; does easily. I only know it's some kind of substitution...
Most of the times, the pattern is ! to_lines $something | egrep -q "$pattern".
The other times, it's: to_lines $something | sort -u.
To me, those should be 2 different functions, which would make things much more readable.
I could even push the idea further, as register_command() and register_platform() contains the exact same lines, only some values in there change.
A notable fact is, there's example of how to use register_package, but examples are not good documentation. Why some stuff are prefixed with ':'?
Basically, the only thing I can say about the additional code is that, if it's useful, then it could probably be more generic, to reduce code duplication.
Again, I do not understand which problem this thing is supposed to solved.

register_package doesn't do anything at all to solve the dependency problem!

It removes the need to solve it by simply ordering the per-package function in the source code, then the calling of register_package the closest possible to those function is solving the problem. This is solving problems by design.

The only difference being the user has to wade through a soup of inscrutable Bash nonsense

You are aware that some other people would be able to say such words for some other code of the project you write in some other language you have much more experience than others, let's say c++? (I know this discussion happened). If we don't want bash we can change the language, but this is probably the less intrusive way to implement it with bash.

to tell what order the packages will be built in.

The user doesn't have to read any code to tell what order the package will be built in, part of the motivation for this code to be written is to tell the user the order without requiring from him to read code. That is in fact one of the argument I listed in my previous comment : the code tells the user the build order without having to read code. And for the one wanting to read code, the build order is defined by the order of the calling of the register commands, which are by design meant to be called the closest possible to the function building a package (this was designed for this).
This code was precisely written to solve the problem you use to argument against that code.

The all list can absolutely be the concatenation of required and optional, because a required package obviously shouldn't depend on an optional package.

This may be true for our current packages, I don't know and I don't want to look at this as this would only lead us to make assumptions about a situation that will be forgotten and to make this code relying on an omission justified by an untold reason. But Linux distributions are full of required packages that can be built differently given this or that optional package. The “all package list cannot be the concatenation of required and optional lists” is just one of the major rules that must be considered when dealing with packages, especially when building packages. For example Gentoo is fully based on this principle (this is in fact one of reason why it exists), and even binary distros like Debian allows to rebuild a required package with an optional package. A real-life example is to rebuild Squid proxy with OpenSSL (on Debian you have to install OpenSSL then rebuild the Squid package using the Debian tools as OpenSSL is an optional dependency to Squid), so if you require a Squid with OpenSSL, your required Squid actually depends on an optional package. Here we need nasm on macOS to build Jpeg, we probably assume it is already provided by the system on Linux, but we may still want to make possible to optionally build nasm on Linux to build Jpeg if we need to require to build a specific version of Jpeg one day. Such assumption is just wrong, it only works by luck.

@freem:

For a start, I think this PR could easily be split.

There is multiple commits, but some changes are done after others changes, and you know how that can be painful to extract or reorder them.
About this:
if ! to_lines "${commands:-}" | egrep -q "^${1}"

The to_lines function turns a space-separated list into a line-separated list, then the egrep call tells if an argument exists as a line or not, so this is equivalent to:
if ! echo "${commands:-}" | tr ' ' '\n' | egrep -q "^${1}"

Which is equivalent to (in Python):
if arg1 not in commands:

when commands is a list.

Why some stuff are prefixed with ':'?

This is described in the example but you're right I can add a line to say it explicitly. This is an arbitrary prefix to mark packages as optional for the named platform. I may also do opt: or something else, like this:
register_package pkgconfig opt:linux-amd64-default opt:windows-i686-mingw opt:windows-amd64-mingw windows-i686-msvc windows-amd64-msvc macos-amd64-default

I could even push the idea further, as register_command() and register_platform() contains the exact same lines, only some values in there change.

Basically, the only thing I can say about the additional code is that, if it's useful, then it could probably be more generic, to reduce code duplication.

Making things more generic would require to fully implement ordered associative arrays in bash, this will require much more code than just duplicating those. Here is an example of associative arrays implementation (I haven't tried it):

https://github.com/dmitrinove/associative_arrays/blob/master/hash.sh

I can't believe you're claiming that it's a good thing that to change the build order of the packages, you'd have to move the build_xxx functions around. This is a a much worse developer experience than editing a one-line list. Just to ascertain the order of the packages, you have to scroll through hundreds of lines. And to edit it you have to awkwardly copy and paste big blocks.

The only difference being the user has to wade through a soup of inscrutable Bash nonsense

You are aware that some other people would be able to say such words for some other code of the project you write in some other language you have much more experience than others, let's say c++?

Sure, I'm thinking relative to a typical Unvanquished code contributor. To do anything here the basic requirement is C++ knowledge; it's to some degree unfortunate when something else is required (e.g. Python + YAML for CBSE).

This code was precisely written to solve the problem you use to argument against that code.

What?

The all list can absolutely be the concatenation of required and optional, because a required package obviously shouldn't depend on an optional package.

This may be true for our current packages, I don't know and I don't want to look at this as this would only lead us to make assumptions about a situation that will be forgotten and to make this code relying on an omission justified by an untold reason. But Linux distributions are full of required packages that can be built differently given this or that optional package. The “all package list cannot be the concatenation of required and optional lists” is just one of the major rules that must be considered when dealing with packages, especially when building packages. For example Gentoo is fully based on this principle (this is in fact one of reason why it exists), and even binary distros like Debian allows to rebuild a required package with an optional package. A real-life example is to rebuild Squid proxy with OpenSSL (on Debian you have to install OpenSSL then rebuild the Squid package using the Debian tools as OpenSSL is an optional dependency to Squid), so if you require a Squid with OpenSSL, your required Squid actually depends on an optional package. Here we need nasm on macOS to build Jpeg, we probably assume it is already provided by the system on Linux, but we may still want to make possible to optionally build nasm on Linux to build Jpeg if we need to require to build a specific version of Jpeg one day. Such assumption is just wrong, it only works by luck.

I'm aware of this kind of optional dependency. For example, when creating the Unvanquished release Docker script I included a lot of audio and video libraries so that the SDL build would enable a lot of optional backends. But I consider it unlikely that such an optional dependency will be relevant for our build script. I know that JPEG will build when NASM is missing despite our having explicitly having a path, but I consider this a bug. I'd set an option to make it error in the absence of NASM if there were one.

Out of topic, but allow me:

it's to some degree unfortunate when something else is required (e.g. Python + YAML for CBSE).

Do that means that replacing this with something not requiring another lang would be a good idea?
Also, I think you should try to keep the heat for temp medium like IRC, which feels way more adapted to that kind of contents/tones to me.

@bmorel I managed to remove to_lines by simply using \n as separator from the start.

On the root topic of improving the deps building whatever our opinions on the way the script is written, I wonder if the gendef stuff required to run on Windows can be done on Wine.

For a start, I think this PR could easily be split.

There is multiple commits, but some changes are done after others changes, and you know how that can be painful to extract or reorder them.
I do know. But it's how things are done in unvanquished, rebasing all the time to reduce number of commits and make things easier to review by others. To be honest, in some rare occasions, those rebases also helps the writer, as long as there's no other branch depending on it (which happens to me almost all the time sadly).
In the end I've found it's sometimes easier to checkout a different branch, to keep things safe, soft-reset on master and do the commits as if they were fresh.
I have the feeling that, as long as this PR is not merged since there's some stuff related to geoip there, there will be no unvanquished release, though, and this annoys me a lot.
I really do not imagine this discussion to be solved quickly (considering the tone in some messages), and blocking 0.53 longer means no work on GUI stuff (because nobody wants to do cherry picking of three repos)  which is imo a rather critical thing: chat system, vote system (including for next map), selection of mod in solo games, making /devmap accessible to people without too much console knowledge, updating rmlui to the last version...
At a first glance, most of the changes in #629, except eb83b58 seems compatible with this PR.
@illwieckz actually, it looks like if @slipher did the split job, and if the conflicting part could be removed it would allow to simplify this PR and refocus on those, and only those. Won't solve any problem, ofc, but let's try to move what can be moved.

Some things were implemented in #629.
Other changes would get other PRs if we want them.


Why minsdk is 17?

I wonder if there are reasons which need to use sdk over 17?

Hi, yes. Is for WebView compatibility. I've found many problems while testing on older versions of Android. API 17 isn't ideal though, there may be problems on some KitKat devices. API 21 is probably the right one, because from there the WebView is updated separately from the OS.
That said, you can try to lower the min sdk, it may or may not work on some devices :)
Anyways I'll probably release an update and increase it to 19 soon. In most cases support for devices from KitKat and above is more than enough.

Thanks for fast reply. I understand about your concern. I will close this.


Signature pad not working in nz-drawer

I am using angular2-signaturepad, it's creating  images as expected, but when i try to clear the canvas, it is not working. The isEmpty() method returns true but canvas is not cleared.

Not an issue, actually it was problem with signature-pad.


after the new v1.77 update the webview does not work

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.77.0
OS Version: windows 10

Steps to Reproduce:

updates vscode to v1.77
open any webview be it extensions readme, extensions using it, the release notes etc

keep getting:
Error loading webview: Error: Could not register service worker: InvalidStateError: Failed to register a ServiceWorker: The document is in an invalid state..

I'm getting the same issue.

However, some combination of restarting VSCode a dozen times, checking for updates twice, and silently contemplating evicting it from the Applications folder seems to have fixed it.

Duplicate of #125993


Minor typo and formatting fixes

Please join Gov4Git so I can credit you!

I've looked into Gov4Git.

It's an app that I have to run on my machine. That's quite an alarm sign. None of the tools at virustotal.com flagged the app as malicious though, so I grudgingly tried.
When the app starts, it requests read/write access to my entire GitHub account. Seriously?

There must be an easier way... Feel free to donate my credits to charity :-P


Need attachments in all the view pages

like lead view, account view, contact view

like lead view, account view, contact view

what did you mean with "attachments" ?

We should be able to upload documents in the specified view pages


Is there a way to update the template to get new functionality?

Hey just seen the added search and new post type with cover image.
Was wondering if there is a way to update the template without causing breaking changes given I customized it a little bit.

Hi @kirso, yes there is but as mentioned before, here and here, it depends on how you set up your local repo.
You also may find this helpful as well.
Hope that helps


WIP: Add EC_FLAG_EXT_PKEY

RSA has the RSA_FLAG_EXT_PKEY and RSA_METHOD_FLAG_NO_CHECK that
are used to indicate whether a key should be checked because it
is stored externally. These flags are somewhat redundant in the
case of RSA, but are missing documentation, and are missing from
the EC code. So, add EC_FLAG_EXT_PKEY to allow an ENGINE
implementation of EC to store private EC keys external to OpenSSL.
This also adds some missing RSA functionality (i.e. flag retreival).

Checklist

[X] documentation is added or updated
[ ] tests are added or updated
[X] CLA is signed

Description of change

There is already RSA_test_flags() which can be used instead of RSA_get_flags().
However for better regularity of the API I believe either this call or EC_KEY_test_flags() call should be added.

There shouldn't be any need for this if the public key components are included in the private key. Some functionality requires it (for example generating a certificate request) so having an EVP_PKEY which does not contain public key component will cause at least some things to misbehave.
If the intention of this flag is to cover the case where its is not possible to include public key components in an EVP_PKEY then (with the above caveats) this could work. However I think that should be done in an algorithm neutral way and not hard coding algorithm specific behaviour in EVP_PKEY functions.

There is already RSA_test_flags() which can be used instead of RSA_get_flags().
However for better regularity of the API I believe either this call or EC_KEY_test_flags() call should be added.
I am not a fan of overloading the use of RSA_test_flags() (or any other test-type-function) to get flags, since it requires a magic value to be used to get all the flags. In addition, there is a big comment about how RSA_flags() gets the RSA-method flags not the RSA-object flags, so having an RSA_get_flags() function that gets the RSA-object flags is used to balance that.

There shouldn't be any need for this if the public key components are included in the private key. Some functionality requires it (for example generating a certificate request) so having an EVP_PKEY which does not contain public key component will cause at least some things to misbehave.

I completely agree with you on that, and in fact my PR #1130, takes full advantage of that behavior.

If the intention of this flag is to cover the case where its is not possible to include public key components in an EVP_PKEY then (with the above caveats) this could work. However I think that should be done in an algorithm neutral way and not hard coding algorithm specific behaviour in EVP_PKEY functions.

Understood, this was intended to match the behavior of RSA_FLAG_EXT_KEY and RSA_METHOD_FLAG_NO_CHECK for EC_KEYs.

What is reason to add new function that return if key is external?
Implementation of key method (RSA,DSA,ECDSA,EC) that manage operations with externally stored  keys does not require flags to be set. For instance you could check code of CAPI engine - private key material is external and engines does not set flags.

Closing this PR, it's not that useful.

I found this PR when attempting to do something similar (add EC_KEY_EXT_PKEY). The use-case I have is to set a "dummy" private key - whether RSA or EC - in an SSL_CTX; this is required when you want to keep the private key external to the program handling the TLS handshake and still want the SSL_CTX_use_PrivateKey to succeed. (Note - I do not want the overhead of calling out to the engine/system that holds the private key until an actual handshake happens.)
I'm able to do this for RSA keys using RSA_FLAG_EXT_PKEY and RSA_METHOD_FLAG_NO_CHECK, but the EC key verification fails without a patch like this.
@tmshort @snhenson would this be reasonable to reopen?

@openssl or @tmshort - any comments / can i re-open + re-submit a similar patch?

This could be implemented as a simple addition on an EC-specific flag and a repeat of the two call usages as per the RSA content rather than adding new functions etc - i.e. the addition of the new functions was unnecessary in my view for this specific context (they are not used widely enough in the code).

Yes, that sounds fine as well. I will submit another PR. Thanks!

Where this originally came from, I believe we decided upon an alternative mechanism to do this. However, I'd be interested in reviewing it.

Sorry for the delay; opened #4850.


update xgboost 171 to 176

Signed-off-by: liyuan<EMAIL_ADDRESS>update xgboost version from 171 to 176 due to https://github.com/dmlc/xgboost/issues/9374

@jayadeep-jayaraman @cjac could you help build?
FYI @viadea

Hi @cjac could you help check why the build failed?

/gcbrun

you might find better results in the long term if you change that a100 to a t4

The MIG Test needs specific A100 or A30 GPUs, and A30 is not supported according to this doc, seems we can only attach A100.
Is it possible to add more A100?

I think if we add more, they will be consumed.  The demand is super high.  I know we have done queue software for TPUs, but nothing for NVIDIA hardware yet.  I'll just keep retrying.

/gcbrun

/gcbrun

/gcbrun

@cjac  @nvliyuan  what is the status of this PR?thx
@SurajAralihalli  FYI

@jayadeep-jayaraman - can you look at this with me next week?

/gcbrun

@jayadeep-jayaraman  @cjac I disabled MIG-related tests due to the lack of A100 GPU temporarily, we can merge the pr first .
CC @viadea @SurajAralihalli

/gcbrun

I am fine.
@SurajAralihalli  FYI

Seems the checks have passed after we disable MIG tests, could you help merge? @cjac

Hi @viadea, could you please help review the pr?

Hi @viadea, could you please help review the pr?

LGTM


Updates to the manifest.

Removed feedback from manifest, which no longer has staticfiles and the entire app of which will be deprecated soon. Added hints to manifest.

Seems pretty straightforward.


Changes for 1.0.0-beta3

👍

@ptankTwilio I would prefer to land the screen capturer example at the same time as beta3.

Closing this PR as this change is taken care by CustomCapturerExample PR.


[core] Fast return if rollback verion equals lastest version

Purpose
If the rollback snapshot version is equal to the lastest snapshot version, we should fast return.

Tests

API and Format

Documentation

A question:
Assuming that when the user executes the rollback procedure with snapshot = 1, the latestSnapshot Id of the Paimon table is 1, and before the rollback procedure ends, the latestSnapshot Id of the Paimon table changes to 2. After you apply this patch, in the end, the rollback procedure fast return so that the result is not snapshot = 1.
Is this the result that the user wants?

A question: Assuming that when the user executes the rollback procedure with snapshot = 1, the latestSnapshot Id of the Paimon table is 1, and before the rollback procedure ends, the latestSnapshot Id of the Paimon table changes to 2. After you apply this patch, in the end, the rollback procedure fast return, so the RollbackHelper#cleanLargerThan will not be called. Is this the result that the user wants?

In this case, the result is not what the user wants. But although there does not fast return, this case may also occur. For example, the rollback snapshot is 1 and the latest snapshot of table is also 1, before rollback ends the lastest snapshot of table changes to 2 or 3, the rollback logic gets the lastest shotshot is diffcult to keep always the newest, this will cause some new snapshots not to be processed.

Hi @askwang , what is this PR aims to? just for performance?

Hi @askwang , what is this PR aims to? just for performance?

yes, juse fast return, no need to execute RollbackHelper#cleanLargerThan.

Do we need to care about the speed of this operation? I think it should be very fast even no optimization.


make affiliation an embedded type

... since it is tightly related to a person and doesn't have a lifecycle on its own

@lzehl I'll take this one then since you took all mine from yesterday :P


Replace the old timeline with the new one

This PR simply includes the new timeline instead of the old one. The
main difference is the scale, the old timeline always include 9 labels
and the new one shows between 2 and 10, depending on the zooming level.
Also, major ticks are a bit longer as in the prototype.
There are several TODOs but they will be addressed soon.
TEST: Load a capture, test general actions, start/stop a capture.
Old Screenshots:
http://screen/4oJLcL6gaoY38Zf
http://screen/3RBQAMbeSmUFopr
New Screenshots:
http://screen/7SBa9jYhW4kVUzy
http://screen/4ynM7TkuwH67Web
Bug: http://b/208444071

LGTM! Is it correct that this needs no changes to AccessibleTimegraph, or did you miss that?

Already included it in a way that can be moved later to AccessibleCaptureViewElement


Meta: Ceramic Ecosystem Alliance (CEA)

cip:
title: Meta: Ceramic Ecosystem Alliance (CEA)
author: Michael Sena (@michaelsena)
discussions-to:
status: Draft
category: Meta
type:
created: 2020-06-14
requires:
replaces:

Simple Summary

The Ceramic Ecosystem Alliance (CEA) allows members to self-organize into working groups to discuss important topics related to Ceramic and produce outputs (normally in the form of CIPs).
Abstract

The CEA IS a grassroots network of Ceramic collaborators. It was created as a way for community members to self-organize into working groups to collaboratively discuss important topics related to Ceramic (such as governance, standards, use cases).
Motivation

CIPs are the method for proposing improvements to Ceramic, but often times community members want to collaborate more closely on those issues. The CEA provides a structure for closer topic-based collaboration to happen.
Specification

Location
The structure for the CEA should exist within the Ceramic Network github organization, in its own repo. http://github.com/ceramicnetwork/CEA
Participant Structure
The CEA has three levels of participant structure:

Role
Description

Members
All participants. Expected to participate in working groups.

Working Groups
Collections of members tackling specific areas of interest, such as Ceramic governance or identity.

Stewards
Members that run run CEA meetings (not working group meetings) and ensure overall integrity of process.

Meetings
All meetings for the CEA and Working Groups will be added to a CEA Calendar. All members of the CEA have access to this calendar and can join any meeting.
CEA Meetings
The entire CEA gathers every two weeks for a meeting (attendance is optional). In this meeting, members:

Share progress from existing working groups
Propose the creation of new working groups

Since CEA meetings are primarily built around sharing progress from working groups, at least 1 member from each active working group is expected to attend.

Working Group Meetings
CEA members self-organize into topic-based initiatives, called working groups. Individual working groups create their own charter, decide their own meeting schedule, and get their own designated channel in the Ceramic discord server. Typically, working groups meet every two weeks so they have something to share out at the next bi-weekly CEA meeting. Notes from working group meetings are helpful to keep the rest of the CEA aligned. Use the CEA meetings notes template to take good meeting notes.
How to join the CEA

Submit a Pull Request to the CEA repository adding yourself to the members table in the README.

Fill out this form.

Once a steward has confirmed you have completed the previous two steps, they will merge your PR and send you a welcome email containing your invitations to the CEA Call Calendar and Discord.
How to form a new working group

Join the CEA.
Create a charter for your working group.
Submit a Pull Request to the CEA repository adding your working group and charter.
Propose your working group at the next CEA meeting. If approved, your PR will be merged, you will get a designated channel in the Ceramic discord, and your working group meeting schedule (specified in the charter) will be added to the CEA calendar.
Recruit participants for your working group.

Documentation Templates
Charter Template
To be added.
Meeting Notes Template
To be added.
Stewards

Michael Sena (@michaelsena)
Joel Torstensson (@oed)
Danny Zuckerman (@dazuck)

Implementation

Once this is live, there will be a link to the CEA repository and a link to join the CEA.
Copyright
Copyright and related rights waived via CC0.

@oed @dazuck Here is a CIP for the creation of the CEA. Need to update some links, but this is the general structure. Thoughts?


Update git-in-here.yml

PR Type: ___
Affiliation: N/A
Ticket: N/A
Checklist:

[X] I've read Contributing Guidelines
[X] I agree to follow the Code of Conduct

Please add the hacktoberfest-accepted label after accepting pull request.
Thanks !

Looks like your YAML is invalid, you're missing - before username.


Nullify dependents when destroying configuration_script_sources/configuration_scripts

Fixing https://bugzilla.redhat.com/show_bug.cgi?id=1437108
Once https://github.com/ManageIQ/manageiq/pull/14432 is in, this similar issue will happen to configuration_scripts and it's children.
@miq-bot add_labels bug, providers/ansible_provider

@miq-bot add_labels providers/ansible_tower

@miq-bot add_label fine/yes

@miq-bot add_label euwe/no

Fine backport details:
$ git log -1
commit 6b6fc31328020bf0182ece02a5708dbf7b6b9a6c
Author: Brandon Dunne<EMAIL_ADDRESS>Date:   Mon Apr 3 14:45:44 2017 -0400

    Merge pull request #14567 from jameswnl/nullify-dependents

    Nullify dependents when destroying configuration_script_sources/configuration_scripts
    (cherry picked from commit 2875c6caf47fae1fce9467e5191862ebc59188b3)

    https://bugzilla.redhat.com/show_bug.cgi?id=1438594


Material Design Color ranges seem more ergonomic as enums rather than arrays

The way we get a color from a Material palette is like this: Colors.grey[500]; however it is not considered a const even the values are pretty much constants.
You get into situations like this:
final TextStyle _labelStyle = new TextStyle(
  fontSize: 14.0,
  color: Colors.grey[500],
);

const TextStyle _inputStyle = const TextStyle(
  fontSize: 16.0,
  color: Colors.black,
);

Where one value cannot be constant because it uses a color palette for retrieving the exact color while another value is an enum.
Another enum benefit would be code completion.
@sethladd

Colors.grey[500] is const. Do you have an example of some code that doesn't work?

Oh, I see, for some reason x[0] isn't considered const even though the Map is const. Huh.

See also https://github.com/flutter/flutter/issues/6706

Somewhat fixed by https://github.com/flutter/flutter/commit/031e042eeeadd518dda4425bd4827f5655ef4fcb
There's a limit to what we can do without language changes because Foo.bar.baz will always be non-const, as far as I can tell.

I tried to convince the Dart team to allow those to be const in https://github.com/dart-lang/sdk/issues/29098 but had no success. :-(
cc @Irhn - this bug is an example of where our customers are getting hung up by the non-const field problem.

/cc @lrhn (as the previous comment hadn't the github id of lrhn linked @lrhn shouldn't have been notified)

I'm going to claim this issue is fixed now that you can write Colors.grey as a const color and Colors.grey.shade300 as an enumerated color value.  Ideally, Colors.grey.shade300 would be const, but that's a separate (language) issue.


⚠ Chatwoot has degraded performance

In c276e26, Chatwoot (https://app.chatwoot.com) experienced degraded performance:

HTTP code: 200
Response time: 3756 ms

Resolved: Chatwoot performance has improved in b67010d.


[Feature] support ModuleWorkers

https://html.spec.whatwg.org/multipage/workers.html#module-worker-example

Yuck, so the readme says to do this, but you actually can't yet?

For now worker-loader doesn't support cross origin files, maybe we can support it by:

using new Worker('https://some.other.origin', {type: 'module'}), or
using JSONP

What do you guys think?

Chrome 80 shipped with support for this: https://www.chromestatus.com/feature/5761300827209728
How about adding an option to enable it? Jason Miller made this gist to check support for module workers.

Done https://github.com/webpack-contrib/worker-loader/pull/255, you can set worker options, docs will be updated in the near future


Incorrect recognition

In this case, the essential part of the article is not recognized from the surrounding context: https://bit.ly/3woC4M2 , https://bit.ly/39ZnenF , https://bit.ly/38r1TTJ

Thanks @Lucabenj, I added the articles to a list of known problems. The first one is really tricky though, the main text is really short compared to the rest.

I closing this since the issue is now mentioned in #4.


feat: analyzer import alias plugin FUI-1528

🤔    What does this PR do?
Implements the initial version of the plugin

Implements the plugin
Updates the readme
Add unit tests and test cases

📑    How should this be tested?
Update test steps to match your PR:
1. Checkout branch
2. `npm run bootstrap`
3. `npm run test`

Other packages are completely tested via tests from `npm run test`. To test the LSP is working correctly in VSCode:
1. `cd packages/showcase/example`
2. `code .` (or manually open VSCode via the UI to the `example` directory on your filesystem).
3. Open a typescript file such as `root.ts`
4. In the Command Palette choose `TypeScript: select typescript version...` and then choose the workspace version
5. The LSP should be enabled. You will need to make a code change after the LSP is enabled before you see any Intellisense.

✅    Checklist

[X] I have added tests for my changes.
[X] I have updated the project documentation.
[X] I have followed the contribution guidelines.

@nick-genesis thanks for the review 👍🏼 yeah this new module is basically just tested via the tests, so sounds like it is all good.


Avalara plugin - Discount and taxes issue

What I'm trying to achieve
Taxes been applied on discounted price and not on the gross price by Avalara plugin.
Steps to reproduce the problem

Purchase a discounted product.
Check on the dashboard in the Orders section whether taxes has been applied on gross price or just on the discount price.

What I expected to happen
We expect to see that the taxes will be applied just on the discounted price, not on the total gross price, incurring in higher taxes.
Screenshots and logs

System information

Saleor version:

[ ] dashboard v3.1.0-dev core vdev
[ ] saleor-sdk v^0.3.0-11 for the checkout

Operating system:

[ ] Windows

The issues related to Avalara Lubin should be fixed in the newest version of Saleor. Feel free to tropem of this is not the case 🙌


Toggle to hide already available media

Is your feature request related to a problem? Please describe.
When browsing recommended media, it is usually overshadowed by all the already available media.
Describe the solution you'd like
It would be handy to have a toggle for each user (perhaps with the default being set by admin) to hide and show available media. That way a user can focus on requesting new items.
Describe alternatives you've considered
As this is a pretty straightforward feature, there's not much other alternatives I can think of. Perhaps in how it gets implemented in a variety of UX ways, like not having a toggle at all and just avoiding showing available media, but I think a toggle is better.
Additional context
This is a feature already available in overseerr and I quite enjoyed it. I stick with petio because of it's boolean logic request filter to servers which is way more handy, and grabbing some great features from other apps will make petio just that much more superior.

This would be great. I constantly get people requesting things that are either already on plex, or are in sonarr/radarr waiting to download. So in addition to knowing what media plex has, it would also be a great extra bonus to know what sonarr/radarr are already watching.

I constantly get people requesting things that are either already on plex,

If something is already on Plex Petio should be finding it. Petio not finding it could be an issue depending on how you name your items.

or are in sonarr/radarr waiting to download. So in addition to knowing what media plex has, it would also be a great extra bonus to know what sonarr/radarr are already watching.

Petio will never retroactively scan Sonarr or Radarr to check what media already existed. Once you request something that's already in either of the *arrs it will start tracking it. There's very little benefit to doing it any other way.

I constantly get people requesting things that are either already on plex,

If something is already on Plex Petio should be finding it. Petio not finding it could be an issue depending on how you name your items.

or are in sonarr/radarr waiting to download. So in addition to knowing what media plex has, it would also be a great extra bonus to know what sonarr/radarr are already watching.

Petio will never retroactively scan Sonarr or Radarr to check what media already existed. Once you request something that's already in either of the *arrs it will start tracking it. There's very little benefit to doing it any other way.

Maybe I wasn't clear, say a movie is already on plex add in radarr manually.
A user is lazy and doesn't look, then they go ask for it petio just takes it instead of saying this item is already present.
Petio does find media on plex added through petio.
If that makes sense.
And I understand the not hooking into the arrs.

Petio should indicate if something is already in Plex. However, I have noticed that sometimes this doesn't show up and it'll need a refresh or going into a movie and back to the list or something like that.

Petio should indicate if something is already in Plex. However, I have noticed that sometimes this doesn't show up and it'll need a refresh or going into a movie and back to the list or something like that.

This is an issue with your setup and not related to this. Please talk to our support team.

Describe the solution you'd like It would be handy to have a toggle for each user (perhaps with the default being set by admin) to hide and show available media. That way a user can focus on requesting new items.

Agreed this would be good and we will add it to the planned list. We will need to generate additional content for each area as to not render no results.


Replace all tabs with 4 spaces + SwiftLint warning for tabs

Description
This introduces a new custom SwiftLint rule that reports warnings when coming across tabs in Swift files. It also fixes all SwiftLint warnings by converting tabs into 4 spaces.
Releated Issue
#291
Checklist (for drafts):

[x] I read and understood the contributing guide as well as the code of conduct
[x] My changes generate no new warnings
[x] My code builds and runs on my machine
[x] Review requested

Screenshots (if appropriate):
Before:

After:

Rebased.


⚠ Prueba_Error_500 has degraded performance

In ece9b8d, Prueba_Error_500 ($URL_ERROR_500) experienced degraded performance:

HTTP code: 200
Response time: 25039 ms

Resolved: Prueba_Error_500 performance has improved in f74c8ec.


 I could choose a smaller model，but Is there any way to optimize it If I want to continue using a larger model?  Thanks
Here is some information,  it's only loading time without downloading.

Macbook Pro ｜ Apple M2 ｜ macOS Sequoia 15.0.1 ｜ 16G
Loaded models for whisper size: large-v3 in 25.66s

iPhone 16 ｜ 18.0
Loaded models for whisper size: large-v3 in 148.82s

Hi @peng2219 , as few questions:

Are you using our TestFlight app?
Could you point to which exact model version you are using from this list?

Hi @peng2219 , a few questions:

Are you using our TestFlight app?
Could you point to which exact model version you are using from this list?

Thanks for your reply @atiorh.
I am using openai_whisper-large-v3-v20240930_turbo_632MB.
I am not using WhisperKit's TestFlight app. Most of the codes to setup whisperkit and load models are from
TranscribeCLI.swift. I have downloaded all model files and tokenizer files,  just load them from local.
Thanks for your support again.

Thanks for the details @peng2219. We will be beta testing a feature that significantly speeds up loading the models in the TestFlight app next week. In the interim, you can use the same models without the "turbo" optimizations that should load faster but are slightly slower to run:

openai_whisper-large-v3-v20240930_626MB
openai_whisper-large-v3-v20240930_547MB

Thanks for the details @peng2219. We will be beta testing a feature that significantly speeds up loading the models in the TestFlight app next week. In the interim, you can use the same models without the "turbo" optimizations that should load faster but are slightly slower to run:

openai_whisper-large-v3-v20240930_626MB
openai_whisper-large-v3-v20240930_547MB

Ok, I'll try. very glad there will be new feature to speed up loading models. Thanks.


Update tutorial_error_prop.py

Render issue

Tagging @trbromley and @astralcai for visibility.
The current version of this demo which has already been merged into the dev branch of the qml repo will fail once the rc branch of pennylane is released and merged into master. This PR fixes the demo, but currently fails the ci because the ci is running against master pennylane instead of the RC branch.

For reference, we had an offline chat and decided to update the pl dependancy branch from master to the RC branch in the Makefile. This change will be reverted next week after the release.


Activity

added index and style file

Submit your pull request correctly and also you specified your submitting your Travel website desktop view but your pull request is showing your HTML AND CSS PROJECT, Please correct it and resubmit again.
Also add readme

Okay
Thank you


Random secret

Hi,
You commented on random secret generation as below:

Interestingly, the easiest way to get truly random key is just to iterate through the base 32 chars picking random

Why do you think that ? You could easily use random_bytes or openssl_random_pseudo_bytes to create crypto secure random strings. If there is no special reason for that, i would suggest an update / pull request, as it could be cleaner and faster to create the key at once.

Because it's getting a random string of base32 characters, not a random string of bytes.


This is useful if you start / stop it as a part of another container if you can on demand start and stop wifi setup inside the container.

That would be useful for multicontainer usage indeed.


Replicating your Production database to development with Airbyte

Main Issue
Often times, users will want to clone their production database so that they can test changes on it or if they want to use real data for in house analytics. This process can be easily done with Airbyte, so we want a recipe that tackles that concept.
We can use Postgres and MySQL for this, and highlight quirks that might occur in either one.

Some points that we should cover:
Why replicate your production database?

Replicating your production data is good practice

Testing on production data gives us a more accurate picture for replicating production bugs

Testing with production data guarantees proper volume for simulating actions

Data volume increases the likelihood of edge cases

Consider other tools? Why use Airbyte?

Draft: https://docs.google.com/document/d/1NbSba8qe9V6YLN-yEYy8MuP7xwO2EXxhH45qgoY2kgU/edit?usp=sharing

Evaluated article for byline contributed article - not appropriate


Do not recommend raising TypeError in validators

Quick fix following https://github.com/pydantic/pydantic/pull/6179

Change Summary

Related issue number

Checklist

[ ] Unit tests for the changes exist
[ ] Tests pass on CI and coverage remains at 100%
[ ] Documentation reflects the changes where applicable
[ ] changes/<pull request or issue id>-<github username>.md file added describing change
(see changes/README.md for details)
[ ] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Please review

Thanks @Viicos 🙏


Use codefund.io for ad render

We are now using codefund.io instead of codefund.app for rendering ethical ads. I also added the new CDN URL that we will be migrating to. Finally, I updated your link to CodeFund to use your referral link.

Weird, @XhmikosR added codefund.io this morning but still not working. I guess it needs cdn.codefund.io?
https://github.com/MaxCDN/bootstrapcdn/pull/1333/files#diff-41812f0e88af3079ba60fefbc57498f8R23

When I tried it, it worked for me yeah.
Anyway, thanks @coderberry, but you guys should stop changing this stuff. :)

@XhmikosR do you know if it's cacheing the old policy? I've tried both Chrome and Safari

This isn't deployed to prod yet.

Should be in prod now.


[UI] Add a field to accept Entity ID for Keycloak

Keycloak provider needs to accept a new field called Entity ID of type string, json tag: entityID
https://github.com/rancher/rancher/issues/29212

Discussed with @westlywright offline that Entity Id is not a required field. So it shouldn't show as required in the UI.

Rancher version: master-head (10/19/2020) e4dc25135
Rancher version: v2.5-head (10/19/2020) 52583ea7a

This was tested and validated as part of #29212
https://github.com/rancher/rancher/issues/29212#issuecomment-712514167


HScript Support.

BRO SO GAY.

looks really cool.  I dont think it worked + you should add it anyway

also an example script would be amazing :)

really cool. Add more variables.

really cool. Add more variables.

I was going to but..really not needed as ever event that can be made in those scripts is unlimited (unless you don't know how to use it)

an event using the script: https://streamable.com/z26vm4

wait so it would be PlayState.dad and it would just work??

wait so it would be PlayState.dad and it would just work??

yea

also another usage of scripts is not only for mid-song events like cam shake or fading or playstate stuff but also stage, notes, and other stuff. like in this example:

now do one for goodNoteHit

I'll keep this pull request open to make changes until it's ready to be merged.

I'll keep this pull request open to make changes until it's ready to be merged.

keep it open for 1 month and let's all see how this works out (after 1 month if it's ready merge!)

now do one for goodNoteHit

sure why not?

stage variables dont work. atleast for me anyway. I tweaked it to be just stepHit btw

stage variables dont work. atleast for me anyway. I tweaked it to be just stepHit btw

but what "bg" are when talking about??????

figured it would be smth like that. alr I'll test later

now make it work with modcore. (from what I'm seeing, it doesnt work. iirc the same happens with lua modcharts and modcore)

Modcore gives too many issues for softcoding. I think I'll remade the mod system with FileSystem as Psych.

Modcore gives too many issues for softcoding. I think I'll remake the mod system with FileSystem as Psych.

try and use hscript instead of focusing on lua. Just use the FileSystem for scanning mods

Modcore gives too many issues for softcoding. I think I'll remake the mod system with FileSystem as Psych.

try and use hscript instead of focusing on lua. Just use the FileSystem for scanning mods

I'll just change the way the game detects the mods, hscript will be still in use.

epic

@glowsoony sync the branch with my latest commit I'm gonna test this pr.

now make a tutorial on how to move the notes (strum and all)

now make a tutorial on how to move the notes (strum and all)

oh nah-

well then how would you make it tween the angle or alpha? doing the createTween or normal tween doesnt do shit

well then how would you make it tween the angle or alpha? doing the createTween or normal tween doesnt do shit

that's why I have extra back up for that like New Var tweens but Bolo won't want to use them that's why I won't add them here.

a I was tryna call the function from playstate without setting the vars
also. How make the note bois move??

a I was tryna call the function from playstate without setting the vars also. How make the note bois move??

a I was tryna call the function from playstate without setting the vars also. How make the note bois move??

FlxEaseByString???

FlxEaseByString???

?

would this work? the notes dont move at all

the variables

a I was tryna call the function from playstate without setting the vars also. How make the note bois move??

That code is wrong, from the //mf altogether [player] to the end

a I was tryna call the function from playstate without setting the vars also. How make the note bois move??

That code is wrong, from the //mf altogether [player] to the end

ah but ofc let me remove that now

Closing until most of 1.5 features are pushed in the repo.


[CLI] Add support for setting time based limit on backlog quota with CLI.

Fixes #9680
This change added tests and can be verified as follows:
Added unit test.
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): no
The public API: no
The schema: no
The default values of configurations: no
The wire protocol: no
The rest endpoints: no
The admin cli options: yes
Anything that affects deployment: no

Documentation

Does this pull request introduce a new feature? yes
If yes, how is the feature documented? docs
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

/pulsarbot run-failure-checks

Does this configuration also take effect at the broker level? I can't find configuration backlogQuotaDefaultLimitSecond in broker.conf

Probably need to pull latest mainline, the broker size change should be merged via this pr: https://github.com/apache/pulsar/pull/10093

Does this configuration also take effect at the broker level? I can't find configuration backlogQuotaDefaultLimitSecond in broker.conf

Probably need to pull latest mainline, the broker side change should be merged via this pr: #10093

In this PR, broker.conf does not include this option as well. Should we add it?


Update kernel.js > fetch host from configuration.

This is directly related to the supercharge pull request below:
https://github.com/superchargejs/supercharge/pull/2
Instead of hard-coding the server host to 'localhost', fetch from the app.js configuration.

@PMojito Thank you!


fix(exec): consistent error message for maxBuffer

This explicitly checks for maxBuffer errors in exec-child.js and
provides a consistent error message. This modifies the test to verify
this.
Although the error message is now explicit, this is not part of our API,
since it's just tacked onto the end of exec's stderr.
Fixes #915

Codecov Report

Merging #919 into master will decrease coverage by 0.13%.
The diff coverage is 91.66%.

@@            Coverage Diff             @@
##           master     #919      +/-   ##
==========================================
- Coverage   97.32%   97.18%   -0.14%
==========================================
  Files          34       34
  Lines        1271     1281      +10
==========================================
+ Hits         1237     1245       +8
- Misses         34       36       +2

Impacted Files
Coverage Δ

src/exec-child.js
94.44% <91.66%> (-5.56%)
:arrow_down:

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 3bb72ed...c892ddf. Read the comment docs.


Requirements.txt and Package Dependencies

PR #22 PR  #21 adds a requirements.txt file to the root project directory. If anyone is using a python package that hasn't been included, feel free to add it in.
Also, here is a brief tutorial on how to make and use requirements.txt.

For future notices, please see #21
Apologies for any inconvenience.

For future notices, please see #21 Apologies for any inconvenience.

thank you for the correction. I just updated the main post.

closing this issue


Fix up storage documentation

Header file is missing doxygen commands and the az_storage_blobs.h file does not show any doc content:

Fixed by https://github.com/Azure/azure-sdk-for-c/pull/734

The storage blob client type defs are missing documentation. Re-opening the issue.
https://github.com/Azure/azure-sdk-for-c/blob/39d9e43c16fd8cea9fafd9c1add053ac21c1d431/sdk/storage/blobs/inc/az_storage_blobs.h#L35-L57
https://djurekdocs.z5.web.core.windows.net/mono/annotated.html


Cuts In Listing Events

The  ListingAvailable event does not currently contain the Cuts array.
This was an explicit design decision:

The Cuts array may be of arbitrary length, which may have gas cost implications in future.
The Cut struct contains a Capability to a Vault.Receiver, which the owner may not want broadcasting.
If we replace the Capability with the Address of the vault, this exposes the address (which is undesirable) and the vault may be moved anyway.
It is simple enough, and more accurate, to query this information with a script.

All of that said, the Storefront workflows that require third parties to scan for events that they then query the Listing for in order to determine if the Listing offers them a cut as payment for selling the token offered by the listing might benefit from having access to some cuts information at this point in Flow development.
I recommend using the Vault.uuid rather than the address if we do not wish to expose the address - this is used in other contracts so it is a pattern. This would require a 'report struct' that the uuid and amount are copied to in order to be placed into an event. The same is true of using addresses.
We could either add the Cuts array to the ListingAvailable, probably as an optional to allow for this information to be omitted if including it would be prohibitive or to reflect the current workflow that omits it.
Or we could optionally emit a specific ListingCuts event immediately after the ListingAvailable event. This would contain the Listing id and the Cuts report struct array:
pub struct CutDetails {
    pub let vaultId: UInt64
    pub let amount: UFix64

    init(vaultId: UInt64, amount: UFix64) {
        self.vaultId = vaultId
        self.amount = amount
    }
}

pub event ListingCuts {
    pub let listingId: UInt64
    pub let cuts: [CutDetails]
}

The Listing creation code then translates the Cuts array into an array of CutDetails and emits a ListingCuts event containing them.
Doing it this way does not affect current workflows that do not expect this information, and allows new workflows that start by checking Cuts.
This code does add gas cost and code complexity to Listing creation, and it may remain preferable to specify that offchain watchers should run a script to check the cuts for a Listing that they may be interested in - this allocates cost to those who benefit from expending it. But should it be desired to add Cut details to Storefront events (and check with Dete before deciding this!), this is a way to do it.

I have mixed feelings about this but if it is ok I would like to mention a tangent here.
Is it somehow possible to document design decisions somehow?
I have some comments on StoreFront but I really don't want to go out of basic design decisions.
One simple example:

why markets don't decide their own cut? I mean user can list without considering market cut, each market can apply their own cut. This can lead to healthier market imo.

But maybe this is already considered but we have no idea as developers.


fix: stuck at 0% issue

Delete peers.dat file during re-index
Add a validation on close for Code 0 (successful close) to not throw an error
Added additional logs on Start

looks good

looks good


⚠ Fortnite has degraded performance

In 49c4273, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1541 ms

Resolved: Fortnite performance has improved in 7e823f2.


Adjust keys API

The results of the API for both the repo ssh keys and the user ssh keys lacks several important features.
This pull request adjusts the API to allow reporting of the key id for the keys reported by  /repos/{owner}/{repo}/keys and the owner, keytype and read_only type for the keys reported by /user/keys.
(Of note /user/keys does not only just return user keys but also deploy keys.)

Blocked till 1.6.0 is released

make lgtm work

make github work 😄


RandomForest: Support fit multiple models in a single pass

This PR overrides fitMultiple for RandomForest to fit multiple models in a single pass.

build

build

build

Hi @eordentlich @leewyang, when you get a chance, please help to review it again. Thx

build


Cirulcar dependency issue

Do you want to request a feature or report a bug?
report bug

What is the current behavior?
cicular dependency doesn't work
If the current behavior is a bug, please provide the steps to reproduce.
I created a sample project, it can be used to demo and reproduce issue
git clone https://github.com/lab4quant/Circular
cd Circular
npm install
npm run build

there 2 js files requires each other: uniformrng.js and seedgenerator.js
the test file rng.js is trying to use uniformrng.js to generate random number

from node console:

Circular>node boundle/rng
webpack:///./dist/seedgenerator.js?:12
        var first = new uniformrng_1.UniformRng(firstSeed);
                    ^

TypeError: uniformrng_1.UniformRng is not a constructor
    at Object.initialize (webpack:///./dist/seedgenerator.js?:12:21)
    at eval (webpack:///./dist/seedgenerator.js?:28:15)
    at Object../dist/seedgenerator.js (Circular\boundle\rn
g.js:82:1)
    at __webpack_require__ (Circular\boundle\rng.js:20:30)

    at eval (webpack:///./dist/uniformrng.js?:3:23)
    at Object../dist/uniformrng.js (Circular\boundle\rng.j
s:106:1)
    at __webpack_require__ (Circular\boundle\rng.js:20:30)

    at eval (webpack:///./dist/test/rng.js?:3:20)
    at Object../dist/test/rng.js (Circular\boundle\rng.js:
94:1)
    at __webpack_require__ (Circular\boundle\rng.js:20:30)

from browser:

just use modern browser like chrome or firefox to open boundle/index.html, you'll see the same error browser console
Uncaught TypeError: uniformrng_1.UniformRng is not a constructor
    at Object.initialize (seedgenerator.js:12)
    at eval (seedgenerator.js:28)
    at Object../dist/seedgenerator.js (rng.js:82)
    at __webpack_require__ (rng.js:20)
    at eval (uniformrng.js:3)
    at Object../dist/uniformrng.js (rng.js:106)
    at __webpack_require__ (rng.js:20)
    at eval (rng.js:3)
    at Object../dist/test/rng.js (rng.js:94)
    at __webpack_require__ (rng.js:20)

What is the expected behavior?
typescript with circular import should work
If this is a feature request, what is motivation or use case for changing the behavior?
Please mention other relevant information such as the browser version, Node.js version, webpack version, and Operating System.
browser: chrome 65.0.3325.181 32-bit, windows 7
node.js: 6.9.4 32-bit windows
webpack: 4.2.0
operating system: windows 7 32 bit

update error detail

This is working as expected. Your code has a circular dependency.
Note that class is not hoisted by spec (only functions are).

@sokra, thanks for the update
I thought webpack 4+ supports circular dependency ...
How can I make my code work?

@sokra , the other day you mentioned class is not hoisted by spec (only functions are).
Does it mean I should use ES5 target?
I tried changing target to ES5, but still got the same error

You can't fix it with configuration changes. Your code is wrong. It doesn't work.
I. e. fix it by calling initialize once in get

@sokra , thanks, looks like i have no choice but to change code to remove circular import

@sokra is it possible to have a build-time error message in case of circular dependency rather than silently put undefined for the imported stuff?


SASS-2214 Update amount and radio pages with explanatory text - Dividends

Description
Update amount and radio pages with explanatory text - Dividends Journey
Add a link to the relevant story in Jira
SASS-2214
Checklist PR Reviewer
Before Reviewing

[ ]  Have you pulled the branch down?
[ ]  Have you assigned yourself to the PR?
[ ]  Have you moved the task to “in review” on JIRA?
[ ]  Have you checked to ensure all dependencies are up to date?
[ ]  Have you checked to ensure its been rebased against the current version of main?

Whilst Reviewing

[ ]  Have you run the tests?
[ ]  Have you run the journey tests?
[ ]  Have you looked at the JIRA story to make sure all Acceptance Criteria has been met?

After Reviewing

[ ]  Have you checked for merge conflicts or any changes in the current main that may affect the current pull request? i.e. does it need another rebase?
[ ]  Have you checked to make sure there are no builds in the pipeline before you merge?
[ ]  Have you moved the task to “in pipeline” on Jira?

[x]  Have you rebased against the current version of main?
[x]  Have you checked code coverage isn’t lower than previously?

After PRs been raised

[ ]  Have you checked the PR Builder passes?

test this please


Thank You

Thank you for creating such a beautiful component. The calendar component is aesthetically pleasing and easy to use. Just found out today about this calendar and I'm already loving it. If you find some spare time, please do create a standalone site with organized documentation. We are willing to spend time on this project if you need any assistance on anything.

Thanks for the comments and suggestion! Would welcome a PR with documentation pushed to gh-pages if you feel like it!


Extend recommendation to protect against cycles draining attacks in t…

Extends the recommendations to protect against cycles draining attacks in the security best practices.

Thanks for the review and approval @tmu0 !

Regarding the 3rd point one could mention that it is also possible to require payment for ingress messages. It is just not supported by the platform and has to be custom designed.

Good point, makes sense. I added an additional bullet describing this. It is very vague but I guess that's what it means that it would need to be designed ;-)

I approved, but I'd like to know how this would work in practice @tmu0?  The only way I see would be a pre-payment since otherwise, you'd always have to make an inter-canister call to check for a payment.

Thanks for the approval and merging @domwoe !


add modified Dining Philosophers example

Inspired by Hillel Wayne's critique of the modeling of the dining philosopher's problem in a Petri net book, probably "Petri Net Theory and the Modeling of Systems" tweet. I think i understand the motivation of the original diagram but agree that it does not capture the spirit of the concurrency problem as originally posed. Just playing around with a model of it here. Starting marking is has tokens at "left fork down" and "right fork down" places.

2 philosophers Aristotle and Bertrand want to eat spaghetti. This is a simplified dining philosophers problem with only 2 philosophers and 2 forks. Thinking is an implicit action that can happen any time the philosopher are not eating.
Places named illustratively to model preconditions. Transitions named to model actions that can occur in the system. The only property we care about in this simple currently is that it does not deadlock when model checked.

No algorithm implementing it but perhaps you could with specification refinement
// handspun diagram. need to manually fix layout
digraph G {
    "left fork down"
    "right fork down"

    // A places
    "A has left fork"
    "A has right fork"
    "A is eating"

    // A transitions
    "A grabs left fork" [shape=rectangle]
    "A grabs right fork" [shape=rectangle]
    "A drops left fork" [shape=rectangle]
    "A drops right fork" [shape=rectangle]
    "A starts eating" [shape=rectangle]
    "A stops eating" [shape=rectangle]

    // A eating arcs
    "left fork down" -> "A grabs left fork"
    "right fork down" -> "A grabs right fork"
    "A grabs left fork" -> "A has left fork"
    "A grabs right fork" -> "A has right fork"
    "A has left fork" -> "A drops left fork"
    "A has right fork" -> "A drops right fork"
    "A drops left fork" -> "left fork down"
    "A drops right fork" -> "right fork down"
    "A has left fork" -> "A starts eating"
    "A has right fork" -> "A starts eating"
    "A starts eating" -> "A is eating"
    "A is eating" -> "A stops eating"
    "A stops eating" -> "left fork down"
    "A stops eating" -> "right fork down"

    // B places
    "B has left fork"
    "B has right fork"
    "B is eating"

    // B transitions
    "B grabs left fork" [shape=rectangle]
    "B grabs right fork" [shape=rectangle]
    "B drops left fork" [shape=rectangle]
    "B drops right fork" [shape=rectangle]
    "B starts eating" [shape=rectangle]
    "B stops eating" [shape=rectangle]

    // B eating arcs
    "left fork down" -> "B grabs left fork"
    "right fork down" -> "B grabs right fork"
    "B grabs left fork" -> "B has left fork"
    "B grabs right fork" -> "B has right fork"
    "B has left fork" -> "B drops left fork"
    "B has right fork" -> "B drops right fork"
    "B drops left fork" -> "left fork down"
    "B drops right fork" -> "right fork down"
    "B has left fork" -> "B starts eating"
    "B has right fork" -> "B starts eating"
    "B starts eating" -> "B is eating"
    "B is eating" -> "B stops eating"
    "B stops eating" -> "left fork down"
    "B stops eating" -> "right fork down"

    rank1 [style=invisible];
    rank2 [style=invisible];
    rank1 -> rank2 [color=white];
    {
        rank = same;
        rank1 -> "left fork down" -> "right fork down" [ style=invis ];
    }
}

\o concatenation of sequences works for strings. should be able to do some simple reuse and make this 5 philosophers pretty cleanly


API 23 framework.jar - Finally (hopefully)

Hi, I randomly looked at my /system/framework folder and guess what I found: A framework.jar! It even contains 2 dex files. I hope that you can do something with it :D
File: http://www.mediafire.com/download/lc34h900a13rb41/framework.jar
Device: SGS3 LTE with BlissPop ROM, Android 6.0.1, Bliss version v6.2

Thanks @wasdennnoch. Also prepare yourself to the new limitation of this library. Android N with API level 24 will be released soon!
I also updated the sample app and library to use API 23.


Apply zoom scale when calculating annotation positions

Fixes #4978

Shouldn't we also fix calculateNodeDimensions which does not give the correct size?

Shouldn't we also fix calculateNodeDimensions which does not give the correct size?

That function has nothing to do with calculating the position of annotations - so is not relevant to this PR.
It returns the dimensions of a node in the 'flow' space. That means the result is expected to be consistent regardless of zoom level. I've just tested that and it is working as expected. I've also just tested all users of that function and they behaviour properly at all zoom levels.


Active Directory Fields on userpage (new feature)

My Setup

My OS name and version: Windows 10
My current app version: 2.5.0

Description

As a user I want to see some active directory fields like phone number, mobile number or position at the user page in the app.

Current Behavior
It's not possible to show aditional Information at the user page.
Expected Behavior

It's possible to select some (existing) active directory fields in the rocket.chat config and these fields are shown at the user page e.g. phone number, mobile number or position.

Reopened in RocketChat/Rocket.Chat#6757 as this is related to the main Rocket.Chat app


Prevented interact with inputs inside slot sidebar

Describe the bug
I added inputs to the right sidebar, so users would have options to simply type dates, yet I just can't set focus on these inputs by clicking. If I add @click="$event.target.focus()", it'll set focused but I still cant move caret with arrow keys.
Options such as keys.month-change-on-arrows="false" and arrow-navigation="false" doesn't make any differences.
A simple example
<template>
  <VueDatePicker
    v-model="date"
    range
    @update:model-value="handleDate">
    <template #right-sidebar>
      <input type="text" v-model="startDate" />
      <input type="text" v-model="endDate" />
    </template>
  </VueDatePicker>
</template>

<script setup>
import VueDatePicker from '@vuepic/vue-datepicker';
import<EMAIL_ADDRESS>import { ref, computed } from 'vue';

const date = ref(null);
const startDate = ref();
const endDate = ref();

function handleDate(e) {
  console.log(e);
  if (!e) {
    return;
  }
  startDate.value = new Date(e[0]).toLocaleString();
  endDate.value = new Date(e[1]).toLocaleString();
}
</script>

Desktop & mobile (please complete the following information):

Browser chrome and safari @ macOs
Library version [e.g. 4.2.2]

@rdmitrievsky Just pass the text-input prop as true


ChipList and Autocomplete does not display programmatically set model

Bug, feature request, or proposal:
Bug
What is the expected behavior?
Programmatically setting the model on a mat-input associated with both a mat-chip-list and mat-autocomplete should display the model value in the input.
What is the current behavior?
The value is not displayed in the input.  Works when only a mat-chip-list or mat-autocomplete is associated with the mat-input but not both.
What are the steps to reproduce?
http://plnkr.co/edit/n0vabloWOJwnGvjyWXAY
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Angular Material Beta 12
Angular 4.4.6

I think I have similar issue. I have 2 mat-form-field with mat-chip,input text and mat-autocomplete in my html.
Now, when i have one field(input text), it is working fine but when i have more than one then it is not working.
Here is the sample for one field emailTo which is working fine but when I add another field emailCC, this is not working. I have also attached the typescript code used by below code.
emailTo :

<mat-chip-list #chipList>
<mat-chip *ngFor="let tag of emailToRec" (remove)="remove(tag)">
{{tag.email}} cancel

<input [matChipInputFor]="chipList"
[matChipInputAddOnBlur]="false"
(matChipInputTokenEnd)="addNew($event)"
[matAutocomplete]="auto"
name="emailTo" [(ngModel)]="model.emailTo" #emailTo="ngModel" ngDefaultControl
#chipInput (keyup)="filter()">

<mat-autocomplete #auto="matAutocomplete" [displayWith]="displayFn" (optionSelected)="add($event)">
<mat-option *ngFor="let tag of filteredAddresses" [value]="tag">
{{ tag.name }}{{ tag.email }}

EmailCC:

<mat-chip-list #chipCCList>
<mat-chip *ngFor="let cctag of emailCCRec" (remove)="removeCC(cctag)">
{{cctag.email}} cancel

<input [matChipInputFor]="chipCCList"
[matChipInputAddOnBlur]="false"
(matChipInputTokenEnd)="addNewCC($event)"
[matAutocomplete]="auto"
name="emailCC" [(ngModel)]="model.emailCC" #emailCC="ngModel" ngDefaultControl
#chipCCInput (keyup)="filterCC()">

<mat-autocomplete #auto="matAutocomplete" [displayWith]="displayFn" (optionSelected)="addCC($event)">
<mat-option *ngFor="let tagcc of filteredCCAddresses" [value]="tagcc">
{{ tagcc.name }}{{ tagcc.email }}

Github_angular _issue.txt

The reason is both mat-chip-list and input are MatFormFieldControl, and when you put mat-chip-list in front of input, mat-chip-list is used in form-field and the input will not get the model value.
A workaround is put input before mat-chip-list in html:
  <p>
    <mat-form-field>
       <input matInput type="text" [matChipInputFor]="chipList1" placeholder="Input with Chip List and Autocomplete" [(ngModel)]="model1" [matAutocomplete]="auto1" />
        <mat-chip-list #chipList1>
            <mat-chip *ngFor="let c of chips">
                {{c.text}}
                <mat-icon matChipRemove>cancel</mat-icon>
            </mat-chip>
        </mat-chip-list>

    </mat-form-field>
    <mat-autocomplete #auto1="matAutocomplete" [displayWith]="displayWith">
        <mat-option *ngFor="let o of options" [value]="o">
            {{o.text}}
        </mat-option>
    </mat-autocomplete>
  </p>

@tinayuangao the problem with that workaround is that the formatting is extremly confusing.
I have taken a bit of a hackish workaround to the problem that is very flawed, but the best solution I could find
I set the _control value in the ngAfterViewInit lifecycle event with the matInput MatFormFieldControl instance:
@ViewChild(MatFormField) formField: MatFormField;
@ViewChildren(MatFormFieldControl) formFieldControl: QueryList<MatFormFieldControl<any>>;

ngAfterViewInit(): void {
     this.formField._control = this.formFieldControl.last;
}

I have found the issue and fixed it. It is working fine now in angular 4 and 5 both.
The issue was in the component where I was referring the same variable for @ViewChild for both the filed.

Autocomplete doesn't require matInput. So if you remove the matInput on <input> there will be only one FormFieldControl inside <mat-form-field>.
 <mat-form-field>

        <mat-chip-list #chipList1>
            <mat-chip *ngFor="let c of chips">
                {{c.text}}
                <mat-icon matChipRemove>cancel</mat-icon>
            </mat-chip>
        </mat-chip-list>
        <input type="text" [matChipInputFor]="chipList1" placeholder="Input with Chip List and Autocomplete" [(ngModel)]="model1" [matAutocomplete]="auto1" />
    </mat-form-field>
    <mat-autocomplete #auto1="matAutocomplete" [displayWith]="displayWith">
        <mat-option *ngFor="let o of options" [value]="o">
            {{o.text}}
        </mat-option>
    </mat-autocomplete>


How to enable Sunday?

Sunday that is [0] is always disabled. Any way to enable it?

Make sure both setting in app.config.js & controllers.js is:
disableWeekdays: []

By default no week day is enabled. You can enable it as per your need.


Research home-urbit wide Internet accessibility

[x] Research wide accessibility issue
[x] Lay out milestones for tackling this

Context:
Home-Urbit should be widely accessible for 2 reasons:

You should be able to access it no matter your location
MinioS3 demands accessibility by all the parties to be able to view the asset that you linked

BalenaCloud offers VPN accessibility that is hardcoded to port 80, doesn't cover requirement 2.
Another VPN service would cover both requirements, but not for everybody, just the users of the VPN. It's great to access your device, but not great for others to access your Minio instance.
Router forwarding is an option, but it's involved and requires the user to use 3rd-party intructions, since it's different for every router.
A universal solution should be found. For example, create a publicly accessible server that sustains reverse ssh tunnels to the home-urbit. It simply pipes all the connections that target a specific port to the home-urbit at another port. It works as a proxy.
Since it's a publicly accessible VM, it solves both requirements. The connection originate from home-urbit itself and it's a tunnel, so there is no need for port forwarding.
Alternative solutions will be researched. The chosen solution will be:

The most reliable
The easiest
The fastest

We will consider the above attributes in that order of importance.
For the upkeep cost, there are a couple of options:

Discuss with Urbit foundation, generalise solution and offer it to all Urbits. Upkeep cost to be covered by UF.
Create a simple SaaS with a very cheap free/paid option
Offer it for free, shoulder cost and use something like Patreon or a similar service.

There are 2 use-cases:

Route Urbit's UDP traffic via a server that is publicly accessible
Expose Urbit's HTTP services to the wider internet (e.g minio, dashboard, etc.)

The service that seems to fit the bill is Wireguard. More specifically, we will use Wireguard to create a tunnel between the Home-Urbit and the anchor server.
Wireguard supports an exit-node functionality, meaning that all traffic that goes out from Home-Urbit, will go through the tunnel and exit from the anchor to the wider internet.
On the anchor, a reverse proxy will make sure that all inbound requests are redirected to the Home-Urbit device inside the wireguard tunnel.

The last question is Urbit specific and has to do with Ames. In order for this to work, for all intents and purposes, the wider Urbit network needs to deal with Anchor's IP as the IP of the planet behind it.
Thus:

Galaxies ( and later stars) have the IP of the anchor on their routing table, not the IP of Home-Urbit
When Home-Urbit sends an ames package, the origin IP must be that of Anchors. This could be done via Urbit or via a service on Anchor that takes the UDP ames package and rewrites the origin part. Thankfully, that part is unencrypted.

For both, input from Tlon engineers is required before proceeding.

Action Items

[ ] Setup wireguard tunnel and reverse-proxy for inbound
[ ] Setup exit node
[ ] Ensure that Urbit's internet IP is that of the Anchor
[ ] Create a container for easy wireguard server setup
[ ] Create Cloudflare workers API for easy subdomain setup

An idea is to use akash for the anchor server