Fix X3D error messages

Recent changes to the asset loader produce the error message "X3D extension no available" when a model fails to load. This patch now produces that message only if the X3D extension is not available and a message with "FileNotFound" if the file cannot be loaded
GearVRF DCO signed off by: Nola Donato<EMAIL_ADDRESS>

i get a compile error about:
import org.gearvrf.GVRCursorController
not being found.

wait, sorry, that was a bug in my app.  it hadn't been updated since the merge of the API changes this morning.

ok, this looks good.


Add the ability to filter through "receiver" address

Currently, we can search for transactions for a sender/sponsor address but not possible to do it for receiver address.
Need this feature(perhaps via nuklaivm output itself) so we can easily filter transactions via both sender and receiver.

This is now implemented


Nuxt Dev Tools don't work

Environment
Operating System: Manjaro
Node Version: v20.16.0 & v22.7.0
Nuxt Version: 3.13.0
Nitro Version: 2.9.7
Package Manager<EMAIL_ADDRESS>&<EMAIL_ADDRESS>
Reproduction
The provided information is enough to understand the problem.
Describe the bug
Nuxt Dev Tools do not work.
You only see a blank screen when you click on them immediately after creating the project (I haven't installed any other different dependencies yet).

Additional context
No response
Logs
No response

it is also to me. especially this happened after updating the Google Chrome browser to version 129.0.6668.59
Operating System: macOS Sonoma 14.6.1
Node Version: v18.20.4
Nuxt Version: 3.12.4
Package Manager<EMAIL_ADDRESS>

same here.

This is a chrome bug - see https://x.com/antfu7/status/1836846357489012816


Raw locks

Closes #23.

Well,the reason why I don't expose the RawMutex is because parking_lot uses some global state in its implementation of the parking lot.
If you passed an RRawMutex across ffi what would happen is the bug described in this parking_lotissue.
The solution in the parking_lot issue is not compatible with the current API of abi_stable,
which doesn't require you to load a dynamic library for parking_lot wrapped types.
I don't even know whether that solution of having a parking_lot dynamic library works across Rust versions,since it is for dylibs (those only work within a single compiler version).
There is also the problem that changing the mutex::VTableVal definition to take in a RRawMutex instead of an OpaqueMutex is a breaking change,it incompatibly changes the layout of the struct as defined by abi_stable's load-time type checker.

As a side question, why are these fields overaligned over usize? Is it because we don't know the real size of the type ahead of time, but since it is a mutex we know that its size will never exceed a atomic usize?

It is because that's the smallest size I feel comfortable using,this allows parking_lot to go back to using an AtomicUsize without breaking abi_stable's ABI.
If this was a more complex type I would just use an erased pointer to the type instead,it's the simplicity of the RawMutex and RawRWLock types that left me confident in their size/alignment not growing larger than a usize.
Also,the CI failure wasn't because any tests failed,but this PR made me realize that I should add testing that has a dynamic library with the oldest compatible abi_stable version,an executable with the path version of abi_stable,and that then tries loading that dynamic library in the executable to ensure that the ABI isn't broken in pull requests changing pre-existing types.
Feel free to create issues/pull-requests for other API,
Soon(as in this weekend) I'll create those tests,and guidelines on evolving the API of libraries developed with ´abi_stable´,including which changes are considered ABI compatible as defined by ´abi_stable´ itself.


bad clones

becasue perl 6 out of the box has no deep cloning several algorithm create spooky actions

allright bug is under control just have get merged

allright is merged


Rails install failure

When trying to install the perfect laptop, everything goes fine all the way to Rails. I've got the following:
    no such name (https://api.rubygems.org/quick/Marshal.4.8/atomic-1.1.11.gemspec.rz)
failed```

My laptop is a out of the box macbook pro 15" 2.3G.
Any suggestion?

:+1:


feat(datepicker): New option to not show the month name from the days table

Feature Description
Add a new option to not show the month name on the days table and a way to set that as default for all calendars. Currently the current month is displayed two time, on the month-year selection control, and on the table. It looks redundant and the material.io components show the Android example that doesn't show that month, for comparison:

Use Case
Avoid the duplicate month on the datepicker and save space
Note: This was noticed while implementing an adapter for js-joda, that probably will try to contribute if there is interest. Another thing I noticed is that on the adapter the getMonthNames() is only invoked with the 'short' parameter. It is planned for the future, or it is some legacy implementation detail?.

Hello, this is not on our roadmap, and we don't have any plans to implement hiding the month name from the days table.
This is still open for discussion, and with a compeling reason or enough interest, this could become prioritized. I'm converting this issue to a discussion.


icu:x64-windows-static-md build failure

Host Environment

OS: Windows10 Enterprise (Evaluation) VM
Compiler: VS2019

To Reproduce
Steps to reproduce the behavior:
./vcpkg install  icu:x64-windows-static-md
Failure logs
The following packages will be built and installed:
    icu[core]:x64-windows-static-md
    mdnsresponder[core]:x64-windows-static-md
Starting package 1/2: icu:x64-windows-static-md
Building package icu[core]:x64-windows-static-md...
-- Using community triplet x64-windows-static-md. This triplet configuration is not guaranteed to succeed.
-- [COMMUNITY] Loading triplet configuration from: Z:\vcpkg\triplets\community\x64-windows-static-md.cmake
-- Using cached Z:/vcpkg/downloads/icu4c-65_1-src.tgz
-- Extracting source Z:/vcpkg/downloads/icu4c-65_1-src.tgz
-- Applying patch Z:/vcpkg/ports/icu/disable-escapestr-tool.patch
-- Applying patch Z:/vcpkg/ports/icu/remove-MD-from-configure.patch
-- Applying patch Z:/vcpkg/ports/icu/fix_parallel_build_on_windows.patch
-- Applying patch Z:/vcpkg/ports/icu/fix-extra.patch
-- Using source at Z:/vcpkg/buildtrees/icu/src/c-65_1-src-702c9cff96
-- Acquiring MSYS Packages...
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
    Command failed: Z:/vcpkg/downloads/tools/msys2/msys64/usr/bin/bash.exe --noprofile --norc -c "pacman -Sy --noconfirm --needed make automake1.15"
    Working Directory: Z:/vcpkg/downloads/tools/msys2
    Error code: 1
    See logs for more information:
      Z:\vcpkg\buildtrees\icu\msys-pacman-x64-windows-static-md-out.log
      Z:\vcpkg\buildtrees\icu\msys-pacman-x64-windows-static-md-err.log

Call Stack (most recent call first):
  scripts/cmake/vcpkg_acquire_msys.cmake:108 (vcpkg_execute_required_process)
  ports/icu/portfile.cmake:77 (vcpkg_acquire_msys)
  scripts/ports.cmake:90 (include)

Error: Building package icu:x64-windows-static-md failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: icu:x64-windows-static-md
  Vcpkg version: 2020.02.04-nohash-external

Additionally, attach any relevant sections from the log files above.

mysys-pacman-x64-windows-static-md-err.log
warning: Public keyring not found; have you run 'pacman-key --init'?
error: mingw32: key "AD351C50AE085775EB59333B5F92EFC1A47D45A1" is unknown
error: key "AD351C50AE085775EB59333B5F92EFC1A47D45A1" could not be looked up remotely
error: mingw64: key "AD351C50AE085775EB59333B5F92EFC1A47D45A1" is unknown
error: key "AD351C50AE085775EB59333B5F92EFC1A47D45A1" could not be looked up remotely
error: mingw32: key "AD351C50AE085775EB59333B5F92EFC1A47D45A1" is unknown
error: key "AD351C50AE085775EB59333B5F92EFC1A47D45A1" could not be looked up remotely
error: failed to update mingw32 (invalid or corrupted database (PGP signature))
error: mingw64: key "AD351C50AE085775EB59333B5F92EFC1A47D45A1" is unknown
error: key "AD351C50AE085775EB59333B5F92EFC1A47D45A1" could not be looked up remotely
error: failed to update mingw64 (invalid or corrupted database (PGP signature))
error: failed to synchronize all databases

mysys-pacman-x64-windows-static-md-out.log
:: Synchronizing package databases...
downloading mingw32.db...
downloading mingw32.db.sig...
downloading mingw64.db...
downloading mingw64.db.sig...
 msys is up to date

Additional context
#7611 seems to be pretty much the same issue. In there it was suggested to delete the msys folder and try again. I don't have a msys folder on my machine though. ICU was the first package to be installed. I tried completely deleting it to retry but the result was the same.

@emptyVoid Could you please take a look?
Thanks.

I don't see any issue with icu:x64-windows-static-md using a fresh install at 2ac2b5f3da6b46ff2ae900550bd7c44f39c57dcd:
PS D:\Projects\GitHub\vcpkg> ./vcpkg install icu:x64-windows-static-md
Your feedback is important to improve Vcpkg! Please take 3 minutes to complete our survey by running: vcpkg contact --survey
Computing installation plan...
The following packages will be built and installed:
    icu[core]:x64-windows-static-md
A suitable version of powershell-core was not found (required v6.2.1). Downloading portable powershell-core v6.2.1...
Downloading powershell-core...
  https://github.com/PowerShell/PowerShell/releases/download/v6.2.1/PowerShell-6.2.1-win-x86.zip -> D:\Projects\GitHub\vcpkg\downloads\PowerShell-6.2.1-win-x86.zip
Extracting powershell-core...
A suitable version of 7zip was not found (required v18.1.0). Downloading portable 7zip v18.1.0...
Downloading 7zip...
  https://www.nuget.org/api/v2/package/7-Zip.CommandLine/18.1.0 -> D:\Projects\GitHub\vcpkg\downloads\7-zip.commandline.18.1.0.nupkg
Extracting 7zip...
A suitable version of nuget was not found (required v4.8.1). Downloading portable nuget v4.8.1...
Downloading nuget...
  https://dist.nuget.org/win-x86-commandline/v4.8.1/nuget.exe -> D:\Projects\GitHub\vcpkg\downloads\nuget.exe
Starting package 1/1: icu:x64-windows-static-md
Building package icu[core]:x64-windows-static-md...
-- Using community triplet x64-windows-static-md. This triplet configuration is not guaranteed to succeed.
-- [COMMUNITY] Loading triplet configuration from: D:\Projects\GitHub\vcpkg\triplets\community\x64-windows-static-md.cmake
-- Downloading https://github.com/unicode-org/icu/releases/download/release-65-1/icu4c-65_1-src.tgz...
-- Extracting source D:/Projects/GitHub/vcpkg/downloads/icu4c-65_1-src.tgz
-- Applying patch D:/Projects/GitHub/vcpkg/ports/icu/disable-escapestr-tool.patch
-- Applying patch D:/Projects/GitHub/vcpkg/ports/icu/remove-MD-from-configure.patch
-- Applying patch D:/Projects/GitHub/vcpkg/ports/icu/fix_parallel_build_on_windows.patch
-- Applying patch D:/Projects/GitHub/vcpkg/ports/icu/fix-extra.patch
-- Using source at D:/Projects/GitHub/vcpkg/buildtrees/icu/src/c-65_1-src-702c9cff96
-- Downloading https://www.python.org/ftp/python/3.7.3/python-3.7.3-embed-amd64.zip...
-- Acquiring MSYS2...
-- Downloading https://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-base-x86_64-20190524.tar.xz/download...
gpg: /etc/pacman.d/gnupg/trustdb.gpg: trustdb created
gpg: no ultimately trusted keys found
gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from '/etc/pacman.d/gnupg/secring.gpg' to gpg-agent
gpg: migration succeeded
gpg: Generating pacman keyring master key...
gpg: key 37454E453F879950 marked as ultimately trusted
gpg: directory '/etc/pacman.d/gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/etc/pacman.d/gnupg/openpgp-revocs.d/44AFCA0D54B840020D77328337454E453F879950.rev'
gpg: Done
==> Updating trust database...
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
==> Appending keys from msys2.gpg...
==> Locally signing trusted keys in keyring...
  -> Locally signing key D55E7A6D7CE9BA1587C0ACACF40D263ECA25678A...
  -> Locally signing key 123D4D51A1793859C2BE916BBBE514E53E0D0813...
  -> Locally signing key B91BCF3303284BF90CC043CA9F418C233E652008...
  -> Locally signing key 9DD0D4217D75A33B896159E6DA7EF2ABAEEA755C...
==> Importing owner trust values...
gpg: setting ownertrust to 4
gpg: setting ownertrust to 4
gpg: setting ownertrust to 4
gpg: inserting ownertrust of 4
==> Updating trust database...
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   4  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   4  signed:   3  trust: 0-, 0q, 0n, 4m, 0f, 0u
gpg: depth: 2  valid:   3  signed:   0  trust: 3-, 0q, 0n, 0m, 0f, 0u
-- Downloading https://sourceforge.net/projects/msys2/files/REPOS/MSYS2/x86_64/libzstd-1.4.4-2-x86_64.pkg.tar.xz/download...
-- Downloading https://sourceforge.net/projects/msys2/files/REPOS/MSYS2/x86_64/zstd-1.4.4-2-x86_64.pkg.tar.xz/download...
-- Downloading https://sourceforge.net/projects/msys2/files/REPOS/MSYS2/x86_64/pacman-5.2.1-6-x86_64.pkg.tar.xz/download...
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) libzstd-1.4.4-2

Total Installed Size:  0.71 MiB

:: Proceed with installation?
:: Processing package changes...
installing libzstd...
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) zstd-1.4.4-2

Total Installed Size:  3.19 MiB

:: Proceed with installation?
:: Processing package changes...
installing zstd...
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) pacman-5.2.1-6

Total Installed Size:  37.74 MiB
Net Upgrade Size:      -8.86 MiB

:: Proceed with installation?
:: Processing package changes...
upgrading pacman...
:: Synchronizing package databases...
downloading mingw32.db...
downloading mingw32.db.sig...
downloading mingw64.db...
downloading mingw64.db.sig...
downloading msys.db...
downloading msys.db.sig...
:: Starting core system upgrade...
warning: resolving dependencies...
terminate other MSYS2 programs before proceeding
looking for conflicting packages...

Packages (6) bash-4.4.023-2  filesystem-2020.02-2  mintty-1~3.1.6-1  msys2-runtime-3.1.4-3  pacman-5.2.1-8  pacman-mirrors-20200329-1

Total Download Size:   18.74 MiB
Total Installed Size:  62.61 MiB
Net Upgrade Size:       1.75 MiB

:: Proceed with installation?
:: Processing package changes...
upgrading msys2-runtime...
upgrading bash...
upgrading filesystem...
upgrading mintty...
upgrading pacman-mirrors...
upgrading pacman...
warning: terminate MSYS2 without returning to shell and check for updates again
warning: for example close your terminal window instead of calling exit
-- Acquiring MSYS2... OK
-- Acquiring MSYS Packages...
-- Acquiring MSYS Packages... OK
-- Configuring x64-windows-static-md-rel
-- Configuring x64-windows-static-md-rel done
-- Configuring x64-windows-static-md-dbg
-- Configuring x64-windows-static-md-dbg done
-- Package x64-windows-static-md-rel
-- Package x64-windows-static-md-rel done
-- Package x64-windows-static-md-dbg
-- Package x64-windows-static-md-dbg done
-- Installing: D:/Projects/GitHub/vcpkg/packages/icu_x64-windows-static-md/share/icu/copyright
-- Performing post-build validation
-- Performing post-build validation done
Building package icu[core]:x64-windows-static-md... done
Installing package icu[core]:x64-windows-static-md...
Installing package icu[core]:x64-windows-static-md... done
Elapsed time for package icu:x64-windows-static-md: 7.368 min

Total elapsed time: 7.994 min

#7611 seems to be pretty much the same issue. In there it was suggested to delete the msys folder and try again. I don't have a msys folder on my machine though. ICU was the first package to be installed. I tried completely deleting it to retry but the result was the same.

@Krzmbrzl, the suggestion was about the vcpkg's MSYS2 installation -- it's located at <vcpkg directory>\downloads\tools\msys2, and the log you've attached indicate MSYS2 was already acquired, might be during install of some other package or another icu triplet.
Could you try deleting <vcpkg directory>\downloads\tools\msys2 folder and retrying the install?

I just did but the error remains the same (actually in the first run I got an error about it not being able to rename a file and in the second run I got the key error again).
I tried it one more time and again after having deleted the msys2 folder I get the rename error:
CMake Error at scripts/cmake/vcpkg_extract_source_archive_ex.cmake:140 (file):
  file RENAME failed to rename

    Z:/vcpkg/buildtrees/icu/src/TEMP/icu

  to

    Z:/vcpkg/buildtrees/icu/src/c-65_1-src-702c9cff96

  because: No error

Call Stack (most recent call first):
  ports/icu/portfile.cmake:17 (vcpkg_extract_source_archive_ex)
  scripts/ports.cmake:90 (include)

Error: Building package icu:x64-windows-static-md failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: icu:x64-windows-static-md
  Vcpkg version: 2020.02.04-nohash-external```

and if i try it again, I get the error I originally reported. Could it be that the renaming error is related to the second I error I am seeing? Like it fails to properly install msys2 but on the next run sees that the directory exists and assumes that it has installed properly ultimtely leading to the key-error?

@Krzmbrzl Is your vcpkg latest?

@JackBoosY yes. I also just tried deleting the complete vcpkg directory, so the first step was to clone it freshly, but I still got an error.
The error log however looks like this now
error: failed to update mingw32 (unable to lock database)
error: failed to update mingw64 (unable to lock database)
error: failed to update msys (unable to lock database)
error: failed to synchronize all databases

Btw. this was now not done from my VM but from an actual Windows installation (win7).
I am also wondering whether the problem might be that I have my vcpkg directory on a different drive. I'll try it with a directory on the main drive and report back :)

Same error on the main drive as well.

Hold on a sec. I just realized that I'm in fact using a fork of vcpkg :facepalm:

yep this seems to have been the problem. Sorry for not noticing earlier and thanks for the support! :)


RangeError: Source is too large

I tried to add 15 small (max length 5sec) .mp3 files. After that I got following error. How to solve this error?
Crunker.js:38 Uncaught (in promise) RangeError: Source is too large
    at Float32Array.set (<anonymous>)
    at buffers.map.buffer (Crunker.js:38)
    at Array.map (<anonymous>)
    at Crunker.concatAudio (Crunker.js:37)
    at eval (eval at <anonymous> (bundle.min.js:44), <anonymous>:60:30)

Did you manage to resolve this issue?

@jackedgson still not... :( postponed the development.
Do you have a solution?
Actually i need to build something like http://sampulator.com/. everything is done except joining clips together.
Still this is a great plugin 👍 💯

Can you please try a mp3 (try a song) or just find a random audio file. My first thought is the format for the audio file is not correct. This is likely an issue with bytes or malformed mp3 headers.

Same here.
I tested with the following files:
a) http://www.auxteam.com.br/merge-audio/1.mp3
b)http://www.auxteam.com.br/merge-audio/2.mp3
Function "mergeAudio" work great, but concatAudio return this error
RangeError: Source is too large
at Float32Array.set ()
at crunker.js:61
at Array.map ()
at Crunker.concatAudio (crunker.js:56)
at audio.fetchAudio.then.buffers ((index):18)

After hours testing merge and concatenat functions, I found that simple lib. But my output file keep with the same stranger effect. For the simplicity of this lib, I decided to look into the code. Looking this issue, of concatenation, I saw that the output buffer was with 350207 of length for two samples with 190589 of length, what shuld result in a buffer with 381178 of length. Other thing that I observe, is that the sampleRate of my sample was 48k, the rate of the buffer was 44.1k and the length of the buffer is defined by the total duration os the samples multiplied by 44.1k. Changing the 44.1k to 48k, voy a la: worked!
I know that 44.1k is default, but I have more than 200 samples and for me, is more convenient keep the sources and adapt the code.
A possible soluction is use the sampleRate provide from the source (dynamic). But, for now, I can't work in it to make a PR.

Fixed by #6


aliza: 1.48.10 -> 1.98.32

Motivation for this change
Package didn't build anymore, RPM link turned 404.
Just fetched the latest and update the hash.
Not a physician but works as expected AFAICT (opened a MRI scan of mine with it and browsed the scans).
Things done

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

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

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

Thanks!


Fixed Typos

I've fixed all typos and did some improvements in naming without changing the functionality of the app.

Thanks for the PR!


Error: Cannot find module '../package.json' from dist/http_client.js

After upgrading to apify-client v2 (2.2.0 to be specific),
the const { version } = dynamicRequire('../package.json'); broke our Storybook.
At first, I thought it's caused by some sorcery in our Webpack config, but I was able to reproduce it even on fresh Storybook example.
Steps to reproduce
either clone https://github.com/Strajk/demos/tree/master/storybook-webpack-apify-client-v2 , or:
npx sb init
npm i react react-dom
npm i apify-client

// Add `import { ApifyClient } from 'apify-client';` to e.g. Button.jsx
npm run storybook

// Check console for `Error: Cannot find module '../package.json'`

Changing dynamicRequire to basic require in /node_modules/apify-client/dist/http_client.js fixes the issue
const { version } = (0, utils_1.dynamicRequire)('../package.json');
to
const { version } = require('../package.json');

Franta: This might be connected with WebPack that may do a tree-shaking which removes this file

@B4nan @vladfrangu I think this should be an easy fix. Might be worth taking a look at it soon. It could prevent external users from integrating Apify with the client.

Maybe you should be using the browser bundle instead (which has the version number inlined during build time)? But it looks like its not generated in recent versions, last version with it is v2.0.0, so probably broken publishing workflow.
I guess we could change the code to directly require the package.json, @vladfrangu do you remember why you changed it to the dynamic require?
Otherwise webpack can be configured to include externals, but it needs to be explicit.

Main reason I changed it is because otherwise TS would duplicate the package.json, which is not really ideal. We can move it to a require call I suppose, but then browser bundles will include the full package.json. Your call

Can't we have both? Instead of generic dynamicRequire helper, we can have getVersion which will statically require the ../package.json?
function getVersion() {
    if (typeof BROWSER_BUILD !== 'undefined') {
        // eslint-disable-next-line no-undef -- defined by webpack
        return { version: VERSION };
    }

    // eslint-disable-next-line
    return require('../package.json');
}

That should work, since the method is only called for getting the version anyways. We should go with that (but I still also want to check out why npm publishes don't have the browser bundle..)

Side note: In Apify Console we use client in the front-end without a problem so this might be specific to the Storybook setup of Webpack.

Running into this using NextJS 13.

Should be fixed in v2.6.4-beta.13, please let us know if it works.

Super! ⭐  many thanks! 🙏


Adapt frontend calls to contextual me endpoints

Description
The following PR add changes to support new /api/v1/me/datasets and  /api/v1/datasets/:dataset_id/records endpoints
Refs: #2826

This is a duplicate with https://github.com/argilla-io/argilla/pull/2845.


show video and user input

Note: While all requests are welcome, finding available cycles to custom-code a feature we won't use in our production environment is always challenging.

Is your feature request related to a problem? Please describe.
A clear, concise description of the problem. (i.e., I'm frustrated when ...)
Describe the solution you'd like
A clear, concise description of what you want to happen.
Describe alternatives you've considered
A clear, concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
At the moment you have to select the video or user input option with variable 6.
Is it possible to expand that if you show video, the user will still be asked to enter?
For me, the standard configuration for the apps is currently used for the selection video and no entry from the user is possible.
I would like it better if you could choose with variable 6 "userInput", "userInputPlusVideo" or just "false"

Thanks for the Feature Request, @mueller-mario.
Currently …

Organizations which do not need to capture user input during initial setup can now easily display a welcome video
Welcome Video

… and — as I don't see my organization ever using a "welcome video" — this falls under:

Finding available cycles to custom-code a feature we won’t use in our production environment is always challenging.
Feature Requests

Pull Requests are always welcome. Thanks.

Will test this week. As usual thanks for the great work.

Note to future, post-JNUC Dan: swiftDialog Multi Dialog Demo

This would be very useful. We utilize asset tags right now but we also want a introductory video. I'd love to be able to play the video AND request the asset tag number.

Reviewed on 2024-06-07-052210; seems like a good use-case for @bartreardon's swiftDialog Multi Dialog Demo.


Fix VS static analyzer warnings.

Optional and expected were not properly forwarding noexcept for their special member functions, so is_nothrow_move_constructible_v<Expected> was false for all T. (This has bad implications if the expecteds are in a vector)
system.process.cpp uses a 32k stack buffer but it's the "top" of the stack so we don't care.
dependencies.cpp was calling std::move() on a constant variable info_ptr->default_features; I changed the declarations to better show that this was const.
(Drive by) All users of make_optional were actually doing emplacement.

Thanks for fixing this! I noticed an exceptionally high number of copies out of Expected/ Optional in the past but was unable to find the reason for this.

Thanks for fixing this! I noticed an exceptionally high number of copies out of Expected/ Optional in the past but was unable to find the reason for this.

I doubt this is going to change much about that but it's worth a shot


Consider allowing disabling client-side validation of JWT tokens

In SPA apps, the value of validating jwt tokens with the IdP's signing keys seems to be of little value since the browser environment should not be considered to be trusted. Normally the flow is for a SPA to obtain a jwt id_token from an IDP (e.g. AAD or ADFS in this example) and then send it server side as a bearer token for identity. The server side should retrieve the signing keys via parsing out that endpoint from the openid-configuration endpoint. In summary, the server shouldn't trust the client (browser) to say that the jwt is legit.
So, here's the problem: This library, when configured with the openid discovery endpoint, parses it and tries to retrieve the keys data. When it comes to AAD/ADFS, Microsoft only CORS-enable the discovery endpoint, and not the keys endpoint - and frankly, I see their point. Allowing browsers to cache/use the signing keys has little to no value from a security perspective, and I presume Microsoft agree and are forcing the matter.
What are your thoughts here? I think having a flag in metadata for skipJWTValidation would make sense, and allow this otherwise excellent library to be seamless with AAD/ADFS4+.

What are your thoughts here?

The OIDC spec says to validate them, so this library does (as it's also required to be certified). If you don't want that validation, then you don't want OIDC, so just use OAuth2 instead.

Thanks for your reply, @brockallen - I'll have to dig further into the session fixation scenario. I was only really thinking about this from the a server-side perspective.

If your app is server-side, then this is the wrong library for you.

@brockallen It's not server-side only -- it's two-tiered, like most SPA (single-page applications) are. The client (angular app) authenticates to get an id_token, then it sends this token to a REST API that runs on the server side (nodejs). The server needs to authenticate this token also. I think you're looking at this in a very narrow view. There can't be many pure client-side only applications that require an identity from an IDP and don't call into a server-side API with the token.

The client (angular app) authenticates to get an id_token, then it sends this token to a REST API that runs on the server side (nodejs).

That's the wrong design. The id_token, by design, is meant for the client only. The access token, by design, is what you send to the server side API.

@brockallen Sorry, you're quite right in the specifics there. When I say "jwt" I generally mean jwt containing id_token & access_token.


chore: not able to build docker image using docker file

Due to introduction of cloudflare workspace we are not able to use given Dockerfile to build docker image
steps to reproduce
cd path/to/dockerfile
docker build -t tc-server:v1 .

this fails with
#12 [builder 4/7] RUN mkdir .cargo     && cargo vendor > .cargo/config
#12 0.222 error: failed to load manifest for workspace member `/prod/cloudflare`
#12 0.222
#12 0.222 Caused by:
#12 0.222   failed to read `/prod/cloudflare/Cargo.toml`
#12 0.222
#12 0.222 Caused by:
#12 0.222   No such file or directory (os error 2)
#12 ERROR: process "/bin/sh -c mkdir .cargo     && cargo vendor > .cargo/config" did not complete successfully: exit code: 101
------
 > [builder 4/7] RUN mkdir .cargo     && cargo vendor > .cargo/config:
0.222 error: failed to load manifest for workspace member `/prod/cloudflare`
0.222
0.[222](https://github.com/tailcallhq/tailcall/actions/runs/7565934822/job/20602770193#step:5:227) Caused by:
0.222   failed to read `/prod/cloudflare/Cargo.toml`
0.222
0.222 Caused by:
0.222   No such file or directory (os error 2)
------
Dockerfile:9
--------------------
   8 |     # This is the trick to speed up the building process.
   9 | >>> RUN mkdir .cargo \
  10 | >>>     && cargo vendor > .cargo/config
  11 |
--------------------
ERROR: failed to solve: process "/bin/sh -c mkdir .cargo     && cargo vendor > .cargo/config" did not complete successfully: exit code: 101
Error: buildx failed with: ERROR: failed to solve: process "/bin/sh -c mkdir .cargo     && cargo vendor > .cargo/config" did not complete successfully: exit code: 101

/bounty 100


HostedParticleShapes only resolve against context

hostedParticle assignments only work if the Particle is defined in the arc.context (and not simply inline). Until recently we loaded (almost) all recipes into context by default, masking this issue.
For example, given:
import '../List/List.recipes'
import './Playlist.schema'

particle PlaylistItem in 'source/PlaylistItem.js'
  in Playlist playlist
  consume item

recipe PlaylistView
  map #items as items
  create #selected as selected
  ItemMultiplexer
    list = items
    hostedParticle = PlaylistItem
  SelectableItems
    list = items
    selected = selected

The system throws like so:
Error: Cannot find store manifest:https://$artifacts/Music/Playlist.recipe::0:b42c142249cd1b94df045af5493837c93f2fb2c1:PlaylistItem
    at assert (assert-web.js:11)
    at Arc.instantiate (arc.js:442)

If PlaylistItem particle is defined in arc.context then the HostedParticleShape is used from there, and the recipe resolves normally.

I will take a stab at this. Removing others from Assignees.

@sjmiles Can you confirm if this is fixed? The entire mechanism for hosted particle serialization is revamped, so I think this should no longer happen, but do let me know if there are still problems.


Add Rakefile for creation of posts

Would help users to get started without having to manually create files in _posts.

This can now be closed, thanks @claman!


Some extra features

Hi!
I tested graphql-cop and I love it.
I have added some extra features to make testing smoother, to be able to have every request logged into Burp Suite (added the -x/--proxy option), and also the -H/--header to add extra headers (for authenticated GraphQL endpoints)
Thanks for publishing the tool!

awesome, thank you!


[FR]: How to automatically generate SRCS and BUILD_DEPS content? Is there a more detailed solution

What is the current behavior?
No response
Describe the feature
I want to migrate some projects on my computer to bazel, but I found that SRCS and BUILD_DEPS in BUILD correspond to dependencies in the package.json file.  Yes, I did not find the command to automatically generate dependencies from package.json to the BUILD file. I hope you can get help. Thank you very much

You will need to explore aspect-cli and gazelle to do build file generation, which is what I think you are asking

You will need to explore aspect-cli and gazelle to do build file generation, which is what I think you are asking
As far as I know, gazelle seems to have only the golang version, but I can't find it in the js field. Can you help me point out where I am going? Thank you for your reply.

That is not what I was referring to, that's an alternative solution though. I was referring to https://github.com/aspect-build/aspect-cli/tree/main/gazelle/js
If you plan on using the Aspect solutions, probably best to reach out to the team and get help onboarding. Otherwise, you will be left to piece it together a bit.

That is not what I was referring to, that's an alternative solution though. I was referring to https://github.com/aspect-build/aspect-cli/tree/main/gazelle/js
If you plan on using the Aspect solutions, probably best to reach out to the team and get help onboarding. Otherwise, you will be left to piece it together a bit.

Thanks a lot. I looked at the source code of https://github.com/aspect-build/aspect-CLI/tree/main/gazelle/js, which may be impossible for me (both in terms of time cost and implementation difficulty), because I am a beginner, and I really can't. I plan to use sed of shell to replace the dependency with Build for the time being.


Come to Linux

:D

It's a windows experter's level hacking into Sublime & windows. So linux is completely different.

I'm sorry, but I don't know how to set transparency on the different window managers that Linux offer, furthermore, Sublime Text uses its own UI engine.


Question and suggestion

Hi, been testing sparrow and I find it quite good so far.
I've got one question regarding the price fetch from coinbase/gecko. How is it done? Does the wallet requests price for specific amounts of sat every time or for the price of a whole bitcoin every X time and then calculates the price for the specific amount locally when user requests?
Would be great to make clear to user how price is fetched (if it's privacy oriented) and maybe provide an internal calculator tab where user can fetch price of a whole bitcoin from a source or use his own price to calculate their sats related calculations outside of google and straight into the wallet software. To encourage good practices.
Cheers!

Thanks! And thank you for your video tutorial - didn't understand much but picked up a few minor UI issues to work on.
Re exchange rates, this the exact call that is made: https://api.coingecko.com/api/v3/exchange_rates https://github.com/sparrowwallet/sparrow/blob/038069f6e63b4508d83c4e79bcd1cd8102c98054/src/main/java/com/sparrowwallet/sparrow/net/ExchangeSource.java#L85
As you can see there are no specifics passed  - it's just the various prices for 1 BTC. Sparrow then calculates using those rates to show you the actual balance of your wallet.


Issue215

This pull request resolves issue #215

Thanks, I'll take a look.

The colour of the valueblock types is reverted to black-on-white again, because the inverse is horrible, despite being more correct.
I believe subclasses (SliderBlock) should have more direct access to their properties (ValueBlock::StringProperty) than other classes by default. Right now the public getter and setter are simply returning the property as-is, but restrictions may be added in the future that shouldn't affect subclasses.

If the inverse is horrible, why not change it elsewhere, as well? You've now introduced an inconsistency which would have to be explained ('white is in, black is out, except on such-and-such blocks').
As for the protected thing, I'd of course argue the contrary - subclasses should have as little access to anything as possible. In this case, SliderBlock should not depend on the fact that ValueBlock happens to have a property called 'value'. It should instead call ValueBlock's public API, which it seems it already does; ValueBlock should then be free to implement getValue and setValue in any way it sees fit. ref

As for the background of types let's just make them all white for now, and figure out better visuals at a later stage.
I find it unproductive to discuss something minor as private vs protected in package being rewritten.


CAMEL-14934: (Batch 2) Improve Component, Language, Data format, etc.

CAMEL-14934, 2nd batch

Thanks this is really great to get better descriptions


[supply] Update to Google Play Developer API v3 (v2 end of life Dec 2019)

Google Play Developer Developer Publishing API v2 (currently used by supply) will end of life Dec 2019.
https://android-developers.googleblog.com/2019/03/changes-to-google-play-developer-api.html

https://github.com/fastlane/fastlane/blob/a8a602e8ab70fa86b70167965e85d44b49c77cd3/supply/lib/supply/client.rb#L2
Spent a few minutes running through my server code this morning trying to find references to v2 pleased its only here in the supply lib.
Thanks for the awesome lib Team Fastlane!

Ruby client is available for v3: https://developers.google.com/api-client-library/ruby/apis/androidpublisher/v3
A diff of https://developers.google.com/apis-explorer/#p/androidpublisher/v2/ vs https://developers.google.com/apis-explorer/#p/androidpublisher/v3/ shows that some methods seem to be gone:
androidpublisher.edits.apklistings.delete	Deletes the APK-specific localized listing for a specified APK and language code.
androidpublisher.edits.apklistings.deleteall	Deletes all the APK-specific localized listings for a specified APK.
androidpublisher.edits.apklistings.get	Fetches the APK-specific localized listing for a specified APK and language code.
androidpublisher.edits.apklistings.list	Lists all the APK-specific localized listings for a specified APK.
androidpublisher.edits.apklistings.patch	Updates or creates the APK-specific localized listing for a specified APK and language code. This method supports patch semantics.
androidpublisher.edits.apklistings.update	Updates or creates the APK-specific localized listing for a specified APK and language code.

We will have to look into if our code uses any of those.

Here is another blog post from Google that highlights some of the changes in the API: https://android-developers.googleblog.com/2018/06/automating-your-app-releases-with.html

API docs v2: https://developers.google.com/android-publisher/archive/v2/
API docs v3: https://developers.google.com/android-publisher/api-ref/
Comparing this gives a more positive outlook:

apklisting seems to have been the place for release notes, which are now part of the track.
there is a new bundle endpoint collection

So stuff we had still seems to be there in one way or another.

Google Play Developer Developer Publishing API v2 (currently used by supply) will end of life Dec 2019.
https://android-developers.googleblog.com/2019/03/changes-to-google-play-developer-api.html

Any estimations regarding this issue?

What are you asking for @lidorDF?
It will be a problem, we created an issue about it, now someone can do the work and fix it.

This doesn't appear to be resolved, a quick search shows that supply is still using the v2 API

First of all, great work Fastlane team, the product it's fantastic, now, what is the release of the new version that uses V3 of Google Play Developer API as we will have until December 1 of 2019 to finish it

This doesn't appear to be resolved, a quick search shows that supply is still using the v2 API

Also following this thread for update

Hi Fastlane team,
I am also following this thread, to be notified when the update supporting Google API V3 will be ready.
Looking forward to update Fastlane  🚀

The Play Store started showing a warning recently about this issue

We’ve detected that your app is using an old version of the Google Play Developer API. From December 1 2019, versions 1 and 2 of this API will no longer be available. Update to version 3 before this date.

I imagine there are many people who scratched their heads for a minute to figure out what was using the Google Play Developer API, only to realize it's fastlane. I'm just commenting here to help others save time tracking down what's going on. Thanks fastlane team!

Thanks for the update @matthewkrueger, and thanks to Google Play Store actually being so communicative on this.

Started some work. Got the download (supply init) part down. Any contributions are more than welcome!
Branch: https://github.com/scorpion35/fastlane/tree/androidpublisherv3
Tracking doc: https://github.com/scorpion35/fastlane/blob/androidpublisherv3/supply/androidpublisherv3_tracking.md
Next: Migrate supply run stuff.

Following. Thank, all!

Possibly relevant context for you @scorpion35 on how a tool doing similar things solved this: https://github.com/microsoft/google-play-vsts-extension/issues/129

Thanks, @janpio! Didn't know there's competition 😁
Think I got halfway through supply run stuff. Updated the tracking doc with all changes so far. Can you take a look when you get a min, please? Would like early feedback if possible :) Added comments on each commit!
Everything above uploader.rb#L36* is working. Let me know if you have any questions!
*except, bundles stuff. Getting some test bundles to test tomorrow!

Hit a road block. Helpppp :)
https://github.com/fastlane/fastlane/issues/15222

Sorry guys, just to make sure:
There is work being done on upgrading the internal workings of fastlane to go with v3 right now, right?
Or is there a solution already available, that we can use to get fastlane working, without having to relace it with another tool?

Yes, there is work going on, in this case by contributor @scorpion35. But there will also be a directed effort by the fastlane team to get this fixed before EOL in Dec 2019 if need be.

@scorpion35 Hey! Do you mind creating a draft PR for this with the work you have currently done? I would love to contribute to this with you so that we can get this out the door? 😊

@joshdholtz That is awesome! :) Created a PR here - https://github.com/fastlane/fastlane/pull/15269
We are blessed with a baby boy on Aug 31st, bit busy with him now. He's winning so far haha. I wouldn't be able to come online for a month or so, hope you understand!

@scorpion35 No problem at all and congrats!! 🎊🎉👶 I really appreciate all the work you've done on this so far 😊 Enjoy fatherhood!

Ruby client is available for v3: https://developers.google.com/api-client-library/ruby/apis/androidpublisher/v3
Code for that at the expected place: https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google/apis/androidpublisher_v3
A diff of https://developers.google.com/apis-explorer/#p/androidpublisher/v2/ vs https://developers.google.com/apis-explorer/#p/androidpublisher/v3/ shows that some methods seem to be gone:
androidpublisher.edits.apklistings.delete	Deletes the APK-specific localized listing for a specified APK and language code.
androidpublisher.edits.apklistings.deleteall	Deletes all the APK-specific localized listings for a specified APK.
androidpublisher.edits.apklistings.get	Fetches the APK-specific localized listing for a specified APK and language code.
androidpublisher.edits.apklistings.list	Lists all the APK-specific localized listings for a specified APK.
androidpublisher.edits.apklistings.patch	Updates or creates the APK-specific localized listing for a specified APK and language code. This method supports patch semantics.
androidpublisher.edits.apklistings.update	Updates or creates the APK-specific localized listing for a specified APK and language code.

We will have to look into if our code uses any of those.
Quick look through a diff of https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google/apis/androidpublisher_v2 vs. https://github.com/googleapis/google-api-ruby-client/tree/master/generated/google/apis/androidpublisher_v3:

classes.rb:

ApkListing and ListApkListingsResponse are indeed gone
some renaming
new CountryTargeting and LocalizedText
SubscriptionPurchase has new accessor auto_resume_time_millis
Track has several new accessors

representations.rb

similar to classes.rb

service.rb

delete_apk_listing, delete_all_apk_listings, get_apk_listing, list_apk_listings, patch_apk_listing, update_apk_listing are gone
many other methods are (slightly) renamed

Unfortunately we are using some of these methods and classes that seem to be gone:
https://github.com/fastlane/fastlane/blob/a8a602e8ab70fa86b70167965e85d44b49c77cd3/supply/lib/supply/client.rb#L215
https://github.com/fastlane/fastlane/blob/a8a602e8ab70fa86b70167965e85d44b49c77cd3
D

uplicate of /supply/lib/supply/client.rb#L344

So this definitely will not be a drop in replacement.

I

Hi Fastlane team,
I am also following this thread, to be notified when the update supporting Google API V3 will be ready.
Looking forward to update Fastlane
Thanks

Hi great team
I follow this post to have notification about the supporting of Google API V3.
Thanks

For future reference, there is a subscribe button on the right-hand side of GitHub issues, using which you can subscribe to the issues without commenting so that other people who have subscribed don't get notification thinking there's some progress from maintainers and the conversation remains on topic. :+1:

Hey Fastlane team! How's it going?
Just came back from my PTO, and moving to a different team. No longer have access to AppStore Connect. Will leave the rest in your capable hands :) Thanks again for your awesome support. It was a pleasure!
I am still around, let me know if you have any questions about the PR!

Thanks scorpion for your work.
Sorry to be annoying, but I have to make the change in the near future.
Will there be support in the next 1-2 months or should we change to a different deployment tool?
Or has somebody found a working workaround to use v3?

Hey 👋 I was using the changes I made for a couple of months already. We needed to find version details that has AAB files. Just point to the branch I made in your Gemfile like this,
gem 'fastlane', :require => ['spaceship', 'supply'], :git => 'https://github.com/scorpion35/fastlane.git', :branch => 'androidpublisherv3'

Please note there is still some work to be done. You can find the work completed here - https://github.com/scorpion35/fastlane/blob/androidpublisherv3/supply/androidpublisherv3_tracking.md. I think joshdholtz is working on wrapping it up!

Sorry for being annoying, but is this on Fastlane's roadmap?

@Panajev Like @janpio has already said, this is on the roadmap for Fastlane to be fixed before EOL if need be.
https://github.com/fastlane/fastlane/issues/14573#issuecomment-527417806

@panpanini What do you mean by "EOL"??
Fastlane users expect it to be done by the end of the year and even earlier, to have time for updating the projects,making sure update is working fine. Otherwise it doesn't make sense.

EoL is 1 December 2019. Today is 23 October which leaves less than 6 weeks. This should've been fixed and ready months ago! Just being on the roadmap is not a good enough answer at this point.

Dear Fastlane contributors,
Thank you very much for working on Fastlane, either on your own time or as a Google employee.
I am sorry that you have to endure people demanding an open source project to be fixed, without ever providing any help to fix the problem they have.
Keep up the good work. ❤💪

Fastlane users shouldn't expect anything. It's being worked on, if you're that desperate then do the work and create a PR!

Correct me if I'm wrong @mieliespoor @andrewsdv , you're not paying for support, right? So, what gives you the right to say how things should be done? Fastlane is a free/open source project. Instead of write critics and awful messages, you should thanks all fastlane devs for this amazing product.
@ fastlane devs: thanks for your work! :-) Unfortunately I can't help you with ruby, but if there is anything that we can do, we're here to support you :-)

Agree with what you're saying, unfortunately. :-) At the same time it sounds strange to me that such an important request of such a great product is being postponed till deadline.  I'm thankful to Fastlane team, nevertheless. Thank you, without any doubt.

I guess its more along the lines of "Google owns Fastlane, Google gets huge amounts of money from dev contributions to Android, devs have a right to demand improvement on the tool" train of thought. There will of course be an argument of whether things should be demanded and how driven by the "open source community" something is.
In any case, we're all devs which means we probably know that information of needs from other sources (users, other departments in your organisation, etc) is valuable but you feel much better about your job if it doesn't come with a negative tone.
Anyways you guys are doing a great job with Fastlane. Looking forward to API v3 integration so I can use it for Internal App Sharing.

Hi,
sorry if I repeat other commenters here, but is this work in progress and will be fixed until EOD?
Thanks for some infos ...

Hi,
sorry if I repeat other commenters here, but is this work in progress and will be fixed until EOD?
Thanks for some infos ...

I think that you want to read this (previous) comment: https://github.com/fastlane/fastlane/issues/14573#issuecomment-527417806

Hey all 👋
Also read this comment: https://github.com/fastlane/fastlane/issues/14573#issuecomment-536022612
Work done so far by me: https://github.com/scorpion35/fastlane/blob/androidpublisherv3/supply/androidpublisherv3_tracking.md
Bonus feature: This PR downloads full size screenshots from Google Play! (Part 2.1: Downloading full size screenshots, https://tinyurl.com/yxoqg9nn)
How to use my branch: https://github.com/fastlane/fastlane/issues/14573#issuecomment-540133148
Would love to help out wrap it up, but I no longer have access to Google Play console (I am on a different team now that doesn't deal with submissions). Please be patient folks. joshdholtz is working on wrapping it up I think!

Heyyy, I'm currently working off of @scorpion35 branch. He laid out some great ground work for this 💪  The change from Android Publisher V2 is Android Publisher V3 is a pretty big change. It is for the better as it will allow supply to do a lot more things but it's not as straight forward as we'd like. There is a lot of testing and verifying that needs to be done in order to make sure that all current setups that use supply work 100% with the upgrade to Android Publisher V3 so that there is absolutely no migration that needs to happen for any fastlane users.
I'm getting close to having this done but there are quite a bit of issues and changes to other fastlane tools that also demand attention at the same time. I appreciate everyone's patience 😊 ❤ I'm planning on having the PR out and ready for testing next week.

Hello, again! I wanted to give a little bit more information and the in-and-outs and status of this changes while my 🧠 is warming up with a cup of ☕ this morning 😊
Task Status
Working/Fixed

Release APK

With and without rollout
With uploading main and patch OBB
With referencing existing main and patch OBB

Release bundle (AAB)

With and without rollout

Update rollout of track
Promote

Move release from one track to another
Also can update rollout

Untested/Working On

Change log
Images
Screenshots
Metadata
Updating unit tests

Why is this change taking so long?
The update from Google::Apis::AndroidpublisherV2 to Google::Apis::AndroidpublisherV3 is not as simple of a replacement as just updating a gem/module (even though some updates have been in the past 😇). V2 to V3 had a name change to almost everything service method that supply uses and it also included a different data model change to tracks, releases, and version codes (which are pretty much the heart of supply). What this meant was that pretty much nothing ran when changing to the new module 🙃
The replacement process had to start at our lowest level of services and slowly work its way up the higher functional. Some of these new additions included explicitly creating tracks that didn't exist yet (things that we didn't need to do in V2) and manually creating releases (which wasn't as complicated but still a change). Rollout and promoting tracks also took a pretty big chunk of time since the APIs and logic behind these were almost a 100% change. Releases in a track can also now be custom named meaning they are no longer the "version name" which also forced an internal change of things are looked up.
The last big change was that tracks can have multiple releases which can have multiple versions. What this meant was that we could always say just "promote beta to production". Beta might have multiple version codes in it so we had to add a new optional configuration into supply called version_code which can be used to specify which release you would like to promote up from a track.
This isn't even all of the changes from Google::Apis::AndroidpublisherV2 to Google::Apis::AndroidpublisherV3 that had to happen but just the ones that come to mind 😊 But all of these changes had to be backwards compatible with the existing supply interface and docs so that none our users existing setups broke.
Along with all of this, there were also the yearly Xcode and iOS updates that required new support from fastlane and its other tools along with handling other changes/fixes that our users reported 😇 We always true to do things as quick as we can for our users so you are all the reason we make fastlane ❤ Its always hard balancing what to give our attention to and sadly this fix kept getting interrupted.
I can't thank @scorpion35 enough for starting the PR (and congrats on fatherhood!). The ground work that @scorpion35 laid out was amazing. Finishing up the PR with the features that still need fixing, making sure its backwards compatible, fixing the unit tests, and updating documentation was still however a pretty big task but its my highest priority right now 💪
I could have definitely provided more transparency about these updates to my sincerest apology to the community for not providing that 😔 fastlane is my passion and my life so I'm taking this as a lesson learned and going to grow from it 📈
Can't wait to get these changes out to everyone who needs them. I will post back next week the PR is ready for some early testing (with instructions provided on how to do that). I appreciate everyone's patience ❤
Now its time to get back to development now that I'm warmed up 😏🚀

Thank you for the comprehensive feedback and status update. Much appreciated!

Суббота, 26 октября 2019, 17:33 +05:00 от Josh Holtz<EMAIL_ADDRESS>
Hello, again! I wanted to give a little bit more information and the in-and-outs and status of this changes while my 🧠 is warming up with a cup of ☕ this morning 😊
Task Status
Working/Fixed

Release APK
With and without rollout
With uploading main and patch OBB
With referencing existing main and patch OBB
Release bundle (AAB)
With and without rollout
Update rollout of track
Promote
Move release from one track to another
Also can update rollout
Untested/Working On
Change log
Images
Screenshots
Metadata
Updating unit tests

Why is this change taking so long?
The update from Google::Apis::AndroidpublisherV2 to Google::Apis::AndroidpublisherV3 is not as simple of a replacement as just updating a gem/module (even though some updates have been in the past 😇). V2 to V3 had a name change to almost everything service method that supply uses and it also included a different data model change to tracks, releases, and version codes (which are pretty much the heart of supply). What this meant was that pretty much nothing ran when changing to the new module 🙃
The replacement process had to start at our lowest level of services and slowly work its way up the higher functional. Some of these new additions included explicitly creating tracks that didn't exist yet (things that we didn't need to do in V2) and manually creating releases (which wasn't as complicated but still a change). Rollout and promoting tracks also took a pretty big chunk of time since the APIs and logic behind these were almost a 100% change. Releases in a track can also now be custom named meaning they are no longer the "version name" which also forced an internal change of things are looked up.
The last big change was that tracks can have multiple releases which can have multiple versions. What this meant was that we could always say just "promote beta to production". Beta might have multiple version codes in it so we had to add a new optional configuration into supply called version_code which can be used to specify which release you would like to promote up from a track.
This isn't even all of the changes from Google::Apis::AndroidpublisherV2 to Google::Apis::AndroidpublisherV3 that had to happen but just the ones that come to mind 😊 But all of these changes had to be backwards compatible with the existing supply interface and docs so that none our users existing setups broke.
Along with all of this, there were also the yearly Xcode and iOS updates that required new support from  fastlane and its other tools along with handling other changes/fixes that our users reported 😇 We always true to do things as quick as we can for our users so you are all the reason we make  fastlane ❤ Its always hard balancing what to give our attention to and sadly this fix kept getting interrupted.
I can't thank  @scorpion35 enough for starting the PR (and congrats on fatherhood!). The ground work that  @scorpion35 laid out was amazing. Finishing up the PR with the features that still need fixing, making sure its backwards compatible, fixing the unit tests, and updating documentation was still however a pretty big task  but its my highest priority right now 💪
I could have definitely provided more transparency about these updates to my sincerest apology to the community for not providing that 😔  fastlane is my passion and my life so I'm taking this as a lesson learned and going to grow from it 📈
Can't wait to get these changes out to everyone who needs them. I will post back next week the PR is ready for some early testing (with instructions provided on how to do that). I appreciate everyone's patience ❤
Now its time to get back to development now that I'm warmed up 😏🚀
—
You are receiving this because you commented.
Reply to this email directly,  view it on GitHub , or  unsubscribe .

Алексей Путенихин

Hello, everyone 👋
I thhiinnnkkkk PR #15269 is ready for some early testers if anybody wants to give AndroidpublisherV3 a shot 🙃 All the functionality should be working but I"m sure there are some edge cases that may have been missed 😇
I have to get unit tests all fixed up yet but hopefully that's the easy part 🙏 If anybody has any issues when testing this out, please post them in the PR for me to see 👌
How to use this PR
Updated your Gemfile to 👇 and run bundle install, bundle update fastlane, or bundle update
gem 'fastlane', :git => 'https://github.com/scorpion35/fastlane.git', :branch => 'androidpublisherv3'

Hello!
Another update for you all today 😊 PR #15269 is pretty much code complete and all functionality has been tested and seems like it should be zero work for most people. There are some new options and some deprecated options but nothing that will be a breaking change.
I'm doing one more final pairing session with @snatchev today to code review and integration test. After this it should be pretty much 💯 to release.
The tests in supply have always been lacking so there aren't a ton of tests to fix for this but we are going to improve the test coverage. It may or may not be in this PR but there will be improved test coverage coming 💪
This PR will probably be good to release on Friday but will probably wait until next Monday or Tuesday so that nothing could possibly break over the weekend 😇
Thanks again for the patience ❤

Alright, fastlane fam! PR #15269 is ready 💪 All the things in supply work, all the actions that also use supply have been tested and fixed if needed, tests pass, and migration doc has been added explaining what new, what changed, and what is deprecated. This should not be a breaking change for majority of users 🤞
I'm not expecting any major issues with most users upgrading to this but I'm sure things will come up as software is software 🙃 I'm going to merge this tomorrow but will releasing this on Monday under version 2.135.0. I'll be paying super close attention to issues the whole week 😝
🙏 Please mention me in the issue if you see anything
😱 If its super bad you can tweet me a link to the GitHub issue at @joshdholtz but don't abuse 😇
And a huge thanks to @scorpion35 for getting this PR started and @snatchev for pairing and code reviewing with me ❤

Thanks guys, totally understand that this requires more testing on edge cases to get it right, patience is the key.
Keep up the good work fastlane !

@joshdholtz awesome and its very appreciated. Looking forward for the release and have a nice and relaxed weekend until next week ;)

Last comment! This migration has now been released in 2.135.0 😊 Please create any new issues and mentioned me in them if you have any issues 🙏  Thanks again for all the patience! ❤

The Play Store Developer console started showing a warning recently about this issue

We’ve detected that your app is using an old version of the Google Play Developer API. From December 1 2019, versions 1 and 2 of this API will no longer be available. Update to version 3 before this date.

I imagine there are many people who scratched their heads for a minute to figure out what was using the Google Play Developer API, only to realize it's fastlane. I'm just commenting here to help others save time tracking down what's going on. Thanks fastlane team!

Hi i have same problem i don't know how to resolve the problem could you resolve please
ACTION REQUIRED: Your automated publishing to Google Play will stop working on 1 December 2019
Your app is using an old version of the Google Play Developer API. From 1 December 2019, versions 1 and 2 of this API will no longer be available, and any calls to these versions will fail. Update to version 3 before this date

@Saifullah6 if you are using Fastlane to deploy your App to Goople Play Store just update your Fastlane to latest version 2.136.0 and deploy your app again with Fastlane. The issue should be gone then otherwise its something else within your app.

@wman1980  Thank You very much
but i don't know what is Fastlane

@wman1980 Thank You
but i dont use Fastlane
i don't know what is the problem
here is the link details
https://android-developers.googleblog.com/2019/03/changes-to-google-play-developer-api.html

@Saifullah6 if you don't use fastlane, then this is not the place to get your issue resolved. You can follow the instructions in the link you posted to get your integrations using the latest version of the api, or you can start using fastlane.

Hey guys
I updated to fastlane-2.135.0 but I still see the warning message in the Google Play Console Page
Look at my build log here

This my simple supply
supply(
   package_name: 'my.app.package',
   track: "assembleRelease",
   apk: "#{lane_context[SharedValues::GRADLE_APK_OUTPUT_PATH]}"
)

Can I provide any other staff to help for understanding if I made a mistake?
Thank you

@claudioviola If you click the Learn more link in the warning banner I believe it explains what you are seeing: the banner warning appears if the old api has been used at all in last 7 days, so it may be outdated relative to current state

Also please open a new issue for your problem instead of posting in a closed issue - then we can properly investigate and possibly help.

Also please open a new issue for your problem instead of posting in a closed issue - then we can properly investigate and possibly help.

Thank You @janpio
I don't know how to update version 3
and tomuch spend time on google for searching the solution but did not get any solution
ACTION REQUIRED: Your automated publishing to Google Play will stop working on 1 December 2019
Your app is using an old version of the Google Play Developer API. From 1 December 2019, versions 1 and 2 of this API will no longer be available, and any calls to these versions will fail. Update to version 3 before this date.
https://android-developers.googleblog.com/2019/03/changes-to-google-play-developer-api.html


Videos link doesn't work

Which page and which links are we talking about here?

Closing due to lack of information.


Conditionally load gfm plugin based on markdown flavor

Developing the Confluence connector, which involves obtaining HTML content and transforming it into Markdown using a dedicated library. The Markdown format is advantageous as it enables us to leverage the enhancements made with chunking V2, applying the markdown hierarchy as a prefix for subsequent chunks.
This PR,  segregate the gfm (GitHub Flavored Markdown) variant to allow for its reuse with standard markdown. This is feasible because gfm is a superset of all the features of basic markdown.

Thank you!


Installer fails on WSL 2 with syntax error

With a fresh install of omnisharp-vim, I answer "yes" to install the roslyn server the first time and get this error:
/home/myuserpath/.vim/bundle/omnisharp-vim/installer/omnisharp-manager.sh: 28: /home/myuserpath/.vim/bundle/omnisharp-vim/installer/omnisharp-manager.sh: Syntax error: "elif" unexpected (expecting "then")

I have both curl and wget installed which isn't the issue anyway since it doesn't like the syntax for some reason.
I ran the body of get_latest_version() method directly in my terminal and it worked. 🤷♂
I also tried running the script directly in the terminal and get the same error.

How strange.
Does the script get any further if you skip that function by passing in the version?
:OmniSharpInstall v1.37.0

what shell are you using in your wsl terminal?

Does the script get any further if you skip that function by passing in the version?

Good idea on trying different version. i didn't try that. unfortunately, I get the same error with both:
:OmniSharpInstall v1.37.0

and from the docs about WSL limitations:
:OmniSharpInstall v1.35.2

What shell are you using in your WSL terminal?

I am using zsh:
$ zsh --version
zsh --version
zsh 5.3.1 (x86_64-debian-linux-gnu)

The script is invoked using /bin/sh - what is that linked to on your system? /bin/sh --version ?

@gabrieljoelc I just updated the script slightly and simplified the conditionals. Can you check to see whether your system likes this version any better?

just tried latest with both versions above and got the same error.
oh interesting.sh --version isn't working:
/bin/sh --version
/bin/sh --version
/bin/sh: 0: Illegal option --

tried searching the interwebs for other ways to check sh version but haven't found it yet.

you could try ls -l /bin/sh too

Which Linux distro are you using in WSL2?  Ubuntu?

you could try ls -l /bin/sh too

~ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 23  2017 /bin/sh -> dash
~ apt-cache policy dash
dash:
  Installed: 0.5.8-2.4
  Candidate: 0.5.8-2.4
  Version table:
 *** 0.5.8-2.4 500
        500 http://deb.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status

Which Linux distro are you using in WSL2? Ubuntu?

~ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 9.5 (stretch)
Release:        9.5
Codename:       stretch

Odd, Dash is also the default shell on Ubuntu, so the script should work on Dash.
I found this Stack Overflow question which seems to be similar, so it could be caused by newline characters.
Maybe try removing and re-downloading OmniSharp-vim from inside WSL?

I also having this error. I try everything with coc, mono, translate_cygwin_ws; but I can't make it work.

this is embarrassing. :facepalm: i just used the same command given by @nickspoons in https://github.com/OmniSharp/omnisharp-vim/issues/506#issuecomment-561918936 (I opened that issue) and it worked.
i must have a systemic issue with my git configs. 😬
To be clear, here were the steps:

Opened /home/myuserpath/.vim/bundle/omnisharp-vim/installer/omnisharp-manager.sh
:w ++ff=unix on the file
Reran the installer

@jeeeem, that seems to be a different issue, could you open a new issue for it instead.

Ha ha, how funny to see the same names in the thread, nearly ba year later.
To quote myself from that thread:

Ah excellent, always nice to get a resolution!

@gabrieljoelc now that the installer ran for you, can you tell me if OmniSharp-vim is working correctly for you in WSL2? I haven't been able to test that environment yet, but I've heard one report of it not working - I'm really keen to learn whether it's WSL2 that is the problem for this other user, or if they have something else going on?

@nickspoons i'll give it a go this week.

I am gonna say there is most likely something up with WSL2. I have tried many different combinations I could think of to get it working but no dice. I swapped it to WSL1 and suddently everything worked like a charm. I am happy to open an issue for this and work through what ever needs to be done to help out but I am quite new to vim-land and might need a bit of extra explaining for some things :)

Oh ? I didn't have a problem with WSL2. omnisharp-roslyn got installed nicely from :OmniSharpInstall.

I swapped it to WSL1 and suddently everything worked like a charm

This tends to mean that the files were on the windows side. Were your source code on wsl or on windows?
I ran the command from a vim installed on the wsl2 side, on a file that was stored on the wsl2 side.


fix: maybe fix rare npe

still haven't been able to repro but attempts to fix #2251

Why doesn't it panic all the time though? Doesn't this code get run with the exact inputs every time?
Also code like the following does not result in a panic:
	var foo []*analysis.Analyzer
	var bar []*analysis.Analyzer
	foo = append(foo, bar...)
	println(foo)

I think the only way we could get this error is if one of the extractors is null somehow.

Why doesn't it panic all the time though? Doesn't this code get run with the exact inputs every time?
Also code like the following does not result in a panic:
	var foo []*analysis.Analyzer
	var bar []*analysis.Analyzer
	foo = append(foo, bar...)
	println(foo)

I think the only way we could get this error is if one of the extractors is null somehow.

yeah i'm not sure why the failure is occurring. it appears to be flaky and infrequent, and i haven't been able to repro it at all myself. this just kind of blindly attempts to add some safeguards based on the stack trace, but it's still a bit of a mystery to me
will add another check to only add non-null extractors from Extractor[i] just in case that's the issue

But if the extractor is null won't that mean that extraction will potentially not work 100%, resulting in even harder to diagnose flakiness?

Is it possible that this is a variable init order issue? From the golang spec:

Dependency analysis is performed per package; only references referring to variables, functions, and (non-interface) methods declared in the current package are considered. If other, hidden, data dependencies exists between variables, the initialization order between those variables is unspecified.

Does this mean that the array could be created at a time when some of the variables it refers to are not initialized yet as they are in different packages? I am not a go expert so this may be a question for @alecthomas

I haven't looked in detail at the code to see if this is what is happening, but yes, if there are values initialised when the runtime starts, inter-package ordering is not guaranteed.

I haven't looked in detail at the code to see if this is what is happening, but yes, if there are values initialised when the runtime starts, inter-package ordering is not guaranteed.

is wrapping the assignment of the Extractors var in an init() block the correct solution for that?


Non-functional changes only

@olaaun and @sgrostad please review
I took a look at your code, it is ok. Some minor fixes in this PR.
Could you please

add author tags (multiple ones are allowed) to all classes
add an explanation to all classes (not tests) about what it does/is for
add a precise spec of input/output/what an implementation should do to all interface methods (only two methods I think)

Other feedback (just for your learning)

Study immutability.
Try to avoid state (fields) in tests - it makes them hard to maintain because it becomes unclear what each test method uses. Especially when combined with test inheritance. If you need reusable state create another class to hold (and use) it instead.
Don't use implementation classes in type signatures.
Consider what others may need to know when using your code (what are constraints on input and output, in what context should something be used etc. etc. - anything that's necessary to know that not communicated in the API's themselves), and document it in Javadoc. If it is a lot it indicates that the code/API does not restrict usage enough.

Done


fail to get jason message req.body

I wrote some code to accept messages sent by the client like this：
`app.route('/api/tk1/addcar').post(users.addcar);
module.exports.addcar= function(req,res) {
console.log(req.body);
res.json('ok');
}`
I use the ARC as a client and send a jason
But the result is empty

What's the problem of it?

I don't know how ARC works, but the Raw Payload doesn't look like properly formatted JSON to me.
Try
{
  "name": "some name",
  "message": "hello message"
}

your json response is also invalid: res.json('ok')


SourceTree: set license to 'closed'

the app is freeware, no source provided

I'd say that gratis is a better fit, as it's free as in beer but not as in speech. closed is a pretty wide umbrella.

fixed, thanks

Thank you for the contribution. It was merged directly as a00b3221d3d1b41cd6ede584b2fc5ae85d74fb54 to keep commit history cleaner. Your contribution is still credited to you.


Increment version for storage releases

Increment package version after release of azure-storage-common

We did not release files-shares, and therefore there is no update here, correct?

@Jinming-Hu @katmsft I do not see a release of File::Shares.  Was that intended?

I don't know what the rationale for that was :(


todoman: disable failing tests

Motivation for this change
Fix build (https://hydra.nixos.org/build/157285216) and switch to pytestCheckHook.
ZHF: #144627
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 145262 run on x86_64-linux 1

1 package built:

todoman

nixpkgs-review happy, nixos x86_64 & aarch64 (emulated).
Could do with some reasoning of why they're ok to disable.

Could do with some reasoning of why they're ok to disable.

Comment added

Result of nixpkgs-review pr 145262 run on x86_64-linux 1

1 package built:

todoman


code example format in the doc

https://microsoft.github.io/FLAML/docs/Examples/Integrate - AzureML
add a space after the comma in subscription_id='<azure-subscription-id>',resource_group=

Can I work on issue #622

Can I work on issue #622

Yes please.

Hi I have fixed this in #624

@adi611 There was already a PR for this issue before yours. Thanks all the same. Would you like to work on a different issue?

@adi611 There was already a PR for this issue before yours. Thanks all the same. Would you like to work on a different issue?

Yes definitely


Background Download

How can I use this library to schedule a download using work manager along with other chained task(which should execute on success of download) in work manager

@fathimath-munisa Fetch creates and maintains its own thread and provide callbacks to return data. In order to work with work manager you would have to create an instance of Fetch and block the work manager thread until the download completes.
Example:
    override fun doWork(): Result {
        val fetch = Fetch.getDefaultInstance()
        val request = Request("url", "file")
        fetch.enqueue(request, { updatedRequest ->
            //success
        }, { error ->
            //failure
        })
        var competedDownloads = false
        while (!competedDownloads) {
            try {
                Thread.sleep(5000)
            } catch (e: InterruptedException) {
                e.printStackTrace()
            }

            fetch.hasActiveDownloads(true) { result -> competedDownloads = result }
        }
        fetch.close()
    }

I am currently looking for a way to make this better.

fetch.hasActiveDownloads(true) { result -> competedDownloads = result }
result returns false on pausing download.

Type mismatch.
Required:
Func
Found:
(Nothing) → Unit

Type mismatch.
Required:
Func
Found:
(Nothing) → Unit

the correct call is :
fetch.hasActiveDownloads(true, Func { competedDownloads = it })


updating docs about javax.inject

updating docs removing javax.inject dependency
removing it from blank project's pom

that because VRaptor core already declare javax.inject as provided and weld
impl already provide it for servlet containers... so, we can keep it simple for users.

:ship:


Reduce reloadItems lag

PLEASE STATE THE VERSION NUMBER you are using.
-> 7.1.6

Every time the user scrolls the calendar (vertically), the cells are reloaded using reloadItems. The problem is, it is laggy which is understandable. Question is, is there a way to reduce the lag when reloading?

...laggy is not understandable 😅
What are you doing in your cellForItemAt Date  function?

closing this issue until more information is provided.


TextArea component

Implement TextArea component. Working branch: https://github.com/DigitalRiver/react-atlas/pull/194

Merged: https://github.com/DigitalRiver/react-atlas/pull/194


About pretrained model

Hi, thank you for sharing code!
Will you release the pretrained model in the furture?
Thanks again.

Is the pretrained model is now available?
Thanks

Sorry for the late reply. I just uploaded the pretrained models. Thanks.


System unavailable: https://packages.adoptium.net/

Please put the system name in the title of this issue.

Link to any log file showing the problem: self-explicable

Please describe the issue: also self-explicable, we use adoptium for actions/runner-images and can't download a gpg key

This is being worked on with JFrog.

Issue has now been resolved. Closing


Issue assessing identifiability for enzyme hydrolysis models

I'm trying to assess the identifiability of reaction rates in a typical enzyme reaction model with hydrolysis. The measured quantity is an accumulated weight of several species over time. Unfortunately, assess_identifiability gets stuck while computing IO-equations for this model. Is this a local issue, or is there something intrinsically difficult about solving this problem? This is my code:

using Catalyst
using StructuralIdentifiability

#creating a model
@parameters t #time
vars = @variables E(t) S(t) ES(t) P(t) #species
@parameters k_a k_d k_c

#underlying model describing the data
# binding and unbinding of enzyme and substrate:
model = @reaction_network begin
    @parameters wE wS wP
    k_a, E + S --> ES
    k_d, ES --> S + E
    k_c, ES --> P + E
end

#known initial conditions
known_ic = [E, S, ES, P]

#the measured quantities are the sum of the weights of the species
@unpack wE, wS, wP = model
measured_quantities = [(wE+wS)*ES + wP*P + wS*S]

#convert the model to an ODE system
ODE = convert(ODESystem, model)
StructuralIdentifiability.assess_identifiability(ODE, measured_quantities = measured_quantities; funcs_to_check = [k_a, k_d, k_c])

Thanks in advance!

@MarcusGalea
Thanks for the interesting example! Indeed, the model is small but due to its nonlinearity direct identifiability computation gets stuck. A possible workaround is to use a conservation law E + ES = C in order to eliminate E. The resulting model is equivalent to the original one but much easier for the computation. Here is the code
ode = @ODEmodel(
       S'(t) = k_d * ES(t) - k_a * S(t) * (C - S(t)),
       ES'(t) = -k_c * ES(t) - k_d * ES(t) + k_a * (C - S(t)) * S(t),
       P'(t) = k_c * ES(t),
       y(t) = (wE + wS) * ES(t) + wP * P(t) + wS * S(t)
)
assess_identifiability(ode, known_ic = [S, ES, P, C - S])

We want to have this conversion to be done automatically but not yet there.

Thanks for the quick response! Apparently they are trying to address this issue in catalyst by running Catalyst.conservedequations before assessing identifiability directly on Catalyst reaction models. This is a change added for Catalyst 14.0. It doesn't seem to be working right now, due to changes in upstream packages. I guess I'll be waiting for this to be fixed in the future, when I'll be working with more complicated reaction networks.


Water Sensors: DRK

This site is partially offline. Only 830 and 819 are transmitting. Do we know if the other nodes are collecting data and just not making a connection? Can someone get out there and check connections? Do we need to reset it?

I'm having them go out to download data off those two nodes and reset the entire set

refer to issue #282


[PE-D][Tester C] Invalid profession can be added and edited to a client profile

When editing the client profile, I can change the profession to some numbers like 123 which is an invalid profession but it can still be updated successfully as shown in the screenshot below.

Perhaps can add restrictions in the profession parameter to check for invalid inputs like numbers or symbols?

Labels: severity.Medium type.FeatureFlaw
original: Jweng88/ped#8

Connectify would like the profession field to stay flexible. One might use some cryptic way that he would like to remember a person's profession is, and we would never know.
TODO: Add documentation.


pre-commit autoupdate

https://pre-commit.com/#pre-commit-autoupdate

https://github.com/tcort/markdown-link-check/issues/369


Support for project management

Dear maintainers,
LXD supports "projects" since version 3.6. It would be useful to be able to manage them using pylxd.
Would such a feature be accepted ? Is there some work planned on this ?
I would be interested in writing the code required for this, if it's not being done currently.
Thank you for you work on this library, it has been a pleasure to use.

This was implemented in #427, #430 and follow-ups

This was implemented in #427, #430 and follow-ups


add Testing doc

Coverage remained the same at 99.231% when pulling 3815bbe6c1576d9578b324b9d2c3054e9bde216f on add-test-doc into 982c65ba1edb1a33c0dff669177138ca0f0e7cb7 on master.


support for IO_uring

Hi, in the Readme you say

Use a non-blocking I/O network lib based on epoll (kqueue under macOS/FreeBSD) to provide high-concurrency, high-performance network IO

IO_uring is the new linux API that allow greater performance for async IO, I was wondering wether you could use IO_uring for even more performance?
https://github.com/axboe/liburing
feel free to close this issue, and BTW congrats for the amazing performance!

The maintainers have considered io_uring support. But temporary put it down due to the lack of time and the amount of changes it needs.
Without going into details. io_uring's model does not work well with database drivers. Current drivers are designed to work with epoll and kqueue. Where the framework doesn't need to know when and how DB talks. It merely asks the kernel to keep an eye on replies from DB. But io_uring expects the framework to submit read and write requests while using them as a notification for when IO is done. This either forces the framework to understand how DB communication works, or frameworks has to support both epoll and io_uring at the same time and dispatch different traffic to the respective function. It's a mess both ways.
We certainly are excited and eager to support io_uring. The matter is just complicated. But nevertheless contributions are more than welcomed :)


Does not implement PhpTypeProvider2

I could not manage to compile the plugin by my self. I spent some hour to fix, but I got stuck into the following interface implementation problem.
java.lang.Throwable: Extension class com.pulyaevskiy.phpstorm.phpdi.PhpDiTypeProvider does not implement interface com.jetbrains.php.lang.psi.resolve.types.PhpTypeProvider2

To me it seems, that the implementation is absolutely sufficient. I don't know, why the compiler is unhappy with it. I usually develop in php and I'm used to write IntelliJ plugins.
Maybe it's my development environment? I'm using the SDK from java-7-openjdk and the php-openapi from phpstorm 8.0.3 on Linux Mint 17.1.
Would be great if you can give me a hand.

Thanks for feedback!
Not sure what your use case is, but if you just need to install this plugin in PhpStorm you can install it via official repository now: https://plugins.jetbrains.com/plugin/7694
If you actually want to tweak this plugin I can take a look a bit later. This error does seem strange and looks like configuration issue.

Thanks for your help. The plugin binary from jetbrains works fine. That means I do something wrong, while compilation. I actually try to play a little with the code to see if I can contribute in any way or at least learn a bit of doing plugin development. I would appreciate it if you could look into it later.
The error pops up during runtime (after start) of Phpstorm. I guess it's a configuration problem, too. I have no clue of what's missing in my setting. I'll stay tune. When I got it fixed, I'll leave a note.
I hope I don't bother you. Just hoping for any kind of pointer.

Hey,
Sorry for the delay. I checked again with latest version of IDEA and PHPStorm, everything looks good.
Did you get this resolved by any chance?
Also did you use official guide to setup IDEA for plugin development? This one:
https://confluence.jetbrains.com/display/IDEADEV/Getting+Started+with+Plugin+Development
Also, you mentioned you're using java-7-openjdk, but the guide says Java 1.6 is recommended.

@devtop I'll close this issue for now. Feel free to reopen if/when you get any new info.

I had the same error while trying to compile another plugin. To fix this, do NOT add php-openapi.jar and php.jar as libraries to the plugin project, but add them to the IntelliJ SDK libraries.


Fix slices

Some slices are []const u8 when they should indicate they are null terminated [:0] const u8

Not actually an issue from what I can see


API Scheduler for fulfilling timeouts.

Each proof request has a time_out for when a proof becomes expired. The proof doesn't actually get labelled as expired until there is a request for the status of the proof here.
It would be a lot cleaner if we could complete remove the polling end point and replace it with some kind of scheduler that would handle expired proofs. Open to suggestions. 🤔

Is this something that should be built into ACA-Py?  The same thing came up around connection establishment time outs. As I recall, the timeouts are created via a decorator in the message.

Absolutely @swcurran . If we could receive a webhook notification when a proof expires that would solve all our problems.

+1 to having ACA-Py be able to send webhooks for these type of decorated events. Currently vc-authn is NOT using the decorator on the proof-request payload as far as i can remember, but it would make sense to switch over to using that rather than having a custom solution that would require development and maintenance.

Yes — I was thinking the same thing.  A webhook for the timeout.
Here is the decorator that I think would be used RFC 0032: Message Timing, and the “expires_time” item.

There is one edge scenario I am not sure the decorator would help us with: we want to visually indicate the proof-request expired in the QR code page as soon as we get past the expiry time. With the decorator, we'd only know that the proof-request expired once a response is received (I think), which could potentially be after the proof expiry time.
Example.: I load-up the auth page, the QR code/proof will expire in 1 minute, I respond to a phone call and come back after 1 minute. Iedally I would see the QR code page indicating the proof expired already, but if we (only) use the decorator I would still be able to respond and I would then be told the proof expired. A bit of a UX question.


[Bug] iotdb 1.0 ,Not enough memory to execute current fragment instance

Search before asking

[X] I searched in the issues and found nothing similar.

Version
iotdb 1.0
Describe the bug and provide the minimal reproduce step
当执行查询时 出现：executeStatement failed. cannot fetch schema, status is: 301，msg is: There is not enough memory to execute current fragment instance, current remaining free memory is 655989, estimated memory usage for current fragment instance is 1048576
需要配置什么才能解决这个问题？
What did you expect to see?
正常查询
What did you see instead?
executeStatement failed. cannot fetch schema, status is: 301
Anything else?
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR!

看了源码
private void checkMemory(Operator root, FragmentInstanceStateMachine stateMachine)
throws MemoryNotEnoughException {
if (!IoTDBDescriptor.getInstance().getConfig().isEnableQueryMemoryEstimation()) {
return;
}
long estimatedMemorySize = root.calculateMaxPeekMemory();
synchronized (this) {
  if (estimatedMemorySize > freeMemoryForOperators) {
    throw new MemoryNotEnoughException(
        String.format(
            "There is not enough memory to execute current fragment instance, current remaining free memory is %d, estimated memory usage for current fragment instance is %d",
            freeMemoryForOperators, estimatedMemorySize),
        TSStatusCode.MPP_MEMORY_NOT_ENOUGH.getStatusCode());
  } else {
    freeMemoryForOperators -= estimatedMemorySize;

每检查一次内存，freeMemoryForOperators 都会减少，当减少到  freeMemoryForOperators<estimatedMemorySize , 报异常。那么 freeMemoryForOperators在什么时候会重置呢？实际机器报该异常后也会一直报，后来就会 查询 time out


NIFI-10728 Upgrade Apache Derby from <IP_ADDRESS> to <IP_ADDRESS>

Summary
NIFI-10728 Upgrades Apache Derby dependencies from <IP_ADDRESS> to <IP_ADDRESS>.
Derby <IP_ADDRESS> requires Java 17 or higher so this change is targeted to the main branch. Derby also restructured their dependencies, moving the EmbeddedDriver class to the derbytools library. Changes include updating referencing modules to include both derby and derbytools when necessary.
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[X] Apache NiFi Jira issue created

Pull Request Tracking

[X] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[X] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[X] Pull Request based on current revision of the main branch
[X] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[X] Build completed using mvn clean install -P contrib-check

[X] JDK 17

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

+1 LGTM, Github Actions are happy too :) Merging to main


[doc] The auto replacement of "process.env.NODE_ENV" could be explained more clearly in doc

Describe the bug
It's fine that the string "process.env.NODE_ENV" is auto replaced, but some of its unexpected behavior isn't mentioned in the doc, and causes some surprises. I think it'd be great to explain it a bit more on this page.
Reproduction
alert("process.env.NODE_ENV"); // SyntaxError: missing ) after argument list

System Info
System:
    OS: Windows 10 10.0.19043
    CPU: (8) x64 Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
    Memory: 10.74 GB / 22.95 GB
  Binaries:
    Node: 14.17.4 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.5 - ~\scoop\apps\yarn\current\Yarn\bin\yarn.CMD
    npm: 6.14.14 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 92.0.4515.159
    Edge: Spartan (44.19041.1023.0), Chromium (92.0.902.84)
    Internet Explorer: 11.0.19041.906

Used Package Manager
yarn
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

What if I do want to replace process.env.NODE_ENV, such as using lib build mode. @patak-js


Run tests in puppeteer

With this change, we no longer require the canvas package, which is a
hassle to set up on some platforms.

@bartvde I'd really like to run the tests in headless Chrome with Puppeteer, to avoid issues for users with the canvas package. But unfortunately Puppeteer does not work out of the box in Jenkins/Docker (see https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md). Would you be able/willing to help make this work with our CI?

@ahocevar sure

@ahocevar although this will likely require updating the docker Image? I have not touched that but can reach out hopefully to people who have

@BerryDaniel do you have any thoughts on this?

@bartvde Thanks in advance. I think being able to use Puppeteer can also benefit our other projects.

@BerryDaniel @bartvde Any news on this? It would really make this library much more dev friendly if we could get this in.

@BerryDaniel Looks like the Docker issue that prevents Puppeteer from launching could be easily fixed. See https://techoverflow.net/2018/06/05/how-to-fix-puppetteer-error-while-loading-shared-libraries-libx11-xcb-so-1-cannot-open-shared-object-file-no-such-file-or-directory/.


Categories Graph is wrong

Clearly there are more than 3 categories but only 3 are reflected in the upper right donut graph.
The issue is that this should be set to keys NOT categories

This affects admins and users. Also because Awards have no category by default the graph freaks out a bit with a null category.
Fixes upcoming in the testing branch.
Also this graph is sort of wrong since it doesn't calculate by points and only calculates by count of category solve.

This should be fixed in master now