Getting error with clang capture (-gmodules)

clang: error: unknown argument: '-gmodules'
Command /Users/Stuart/infer/infer/bin/../lib/capture/clang failed with exit code 1

I was using infer with a previous project a couple months ago fine, but now it's giving me this error. I even tried updating the master branches of both infer and the facebook-clang-plugins and recompiling, but still getting the error

Hello @tettoffensive,
Could you please provide instructions on how to reproduce this issue?
Thanks!

This is how I installed facebook-clang-plugins and infer:
cd infer
./update-fcp.sh && ../facebook-clang-plugin/clang/setup.sh && ./compile-fcp.sh
export PATH=`pwd`/infer/bin:$PATH

And then I ran:
cd ../MyProject
infer -- xcodebuild -workspace MyProject.xcworkspace -scheme MyProject -sdk iphonesimulator

This last command is where I saw the clang error over and over. I believe this workflow worked for me a few months ago with another project.

@tettoffensive the workflow has changed. It's now:
cd infer/
git submodule update --init
facebook-clang-plugin/clang/setup.sh && ./compile-fcp.sh
make -C infer clang
export PATH=`pwd`/infer/bin:$PATH

You can also use the release to avoid having to recompile clang and the plugin.

With 6553ba237916125be8e389f46a4006ed6e92abaf the problem should be solved, since the -gmodules flag gets replaced with equivalent ones.
Can you please check you are running the latest version?
To save time, follow the instructions above, provided by @jvillard

Thanks. Getting an error with compile-fcp.sh :
./compile-fcp.sh
+++ dirname ./compile-fcp.sh
++ cd .
++ pwd
+ INFER_ROOT=/Users/Stuart/infer
+ PLUGIN_DIR=/Users/Stuart/infer/facebook-clang-plugins
+ CLANG_EXEC=/Users/Stuart/infer/facebook-clang-plugins/clang/bin/clang
+ '[' '!' -f /Users/Stuart/infer/facebook-clang-plugins/clang/bin/clang ']'
+ pushd /Users/Stuart/infer/facebook-clang-plugins
~/infer/facebook-clang-plugins ~/infer
++ uname
+ platform=Darwin
+ '[' Darwin == Linux ']'
+ make clean
make -C analyzer clean
make -C libtooling/atdlib clean
make -C libtooling clean
rm -rf xcode *~
+ make -C clang-ocaml clean
<stdin>:69:10: fatal error: 'clang/AST/DeclNodes.inc' file not found
#include <clang/AST/DeclNodes.inc>
         ^
1 error generated.
make[1]: *** [build/ASTExporter.h.p] Error 1
rm -rf tests/*.out build
+ make
make -C analyzer all
clang++ -stdlib=libc++ -std=c++11 -I/usr/local/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-uninitialized  -Wno-missing-field-initializers -Wno-vla-extension -Wno-c99-extensions -O3 -DNDEBUG -c PluginMain.cpp -o build/PluginMain.o
PluginMain.cpp:11:10: fatal error: 'clang/StaticAnalyzer/Core/Checker.h' file not found
#include <clang/StaticAnalyzer/Core/Checker.h>
         ^
1 error generated.
make[1]: *** [build/PluginMain.o] Error 1
make: *** [all] Error 2

@tettoffensive just to be sure, is that after running facebook-clang-plugin/clang/setup.sh?

@jvillard Yes. I followed your instructions.

The release build gave me different errors:
INFER_ANALYZE_MODELS=1 /Users/Stuart/Downloads/infer-osx-v0.4.0/infer/models/c/../../bin/infer -o /Users/Stuart/Downloads/infer-osx-v0.4.0/infer/models/c/out --models_mode --no_failures_allowed -- make -C src -j
gcc -c -w  glib.c -o glib.o
gcc -c -w  infer_builtins.c -o infer_builtins.o
gcc -c -w  libc_basic.c -o libc_basic.o
gcc -c -w  math.c -o math.o
gcc -c -w  wchar.c -o wchar.o
gcc -c -w  wctype.c -o wctype.o
gcc -c -w  xlib.c -o xlib.o
In file included from math.c:13:
./infer_builtins.h:13:10: fatal error: In file included from glib.c'stdlib.h': 13file:
 not./infer_builtins.h :found13:
10: fatal error: 'stdlib.h' file not found
#include <stdlib.h>
         ^
#include <stdlib.h>
         ^
In file included from infer_builtins.c:13:
./infer_builtins.h:13:10: fatal error: 'stdlib.h' file not found
#include <stdlib.h>
         ^
wctype.c:14:10: fatal error: 'wctype.h' file not found
#include <wctype.h>
         ^
In file included from xlib.c:13:
./infer_builtins.h:13:10: fatal error: 'stdlib.h' file not found
#include <stdlib.h>
         ^
In file included from wchar.c:13:
./infer_builtins.h:13:10: fatal error: 'stdlib.h' file 1not error  generated.
found
#include <stdlib.h>
         ^
1 error generated.
In file included from libc_basic.c:29:
./infer_builtins.h:13:10: fatal error: 'stdlib.h' file not found
#include <stdlib.h>
         ^
1 error generated.
1 error generated.
1 error generated.
make[3]: *** [xlib.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [glib.o] Error 1
make[3]: *** [infer_builtins.o] Error 1
1 error generated.
make[3]: *** [wctype.o] Error 1
1 error generated.
make[3]: *** [wchar.o] Error 1
make[3]: *** [libc_basic.o] Error 1
make[3]: *** [math.o] Error 1
make[2]: *** [run_infer] Error 2

you can try (re)installing the command-line tools: xcode-select --install (see #132).

ah...thanks...i forgot about that one. Release build works now

Now I'm getting this:
PhaseScriptExecution Copy\ Pods\ Resources /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Intermediates/Channels.build/Debug-iphonesimulator/ChannelsTests.build/Script-BA302EC9EE207DAA9DAA0F70.sh
    cd /Users/Stuart/Channels/Channels
    /bin/sh -c /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Intermediates/Channels.build/Debug-iphonesimulator/ChannelsTests.build/Script-BA302EC9EE207DAA9DAA0F70.sh
building file list ... done

sent 29 bytes  received 20 bytes  98.00 bytes/sec
total size is 0  speedup is 0.00

Touch /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/ChannelsTests.xctest
    cd /Users/Stuart/Channels/Channels
    export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Users/Stuart/Downloads/infer-osx-v0.4.0/infer/bin:/Users/Stuart/.opam/4.01.0/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin:/Users/stuart/.rvm/gems/ruby-1.9.3-p385/bin:/Users/stuart/.rvm/gems/ruby-1.9.3-p385@global/bin:/Users/stuart/.rvm/rubies/ruby-1.9.3-p385/bin:/Users/stuart/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/b:/Users/Stuart/.rvm/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Users/Stuart/Downloads/infer-osx-v0.1.0/infer/infer/bin"
    /usr/bin/touch -c /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/ChannelsTests.xctest

** BUILD FAILED **

The following build commands failed:
	CompileC /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Intermediates/Pods.build/Debug-iphonesimulator/pop.build/Objects-normal/i386/TransformationMatrix.o pop/pop/WebCore/TransformationMatrix.cpp normal i386 c++ com.apple.compilers.llvm.clang.1_0.compiler
	Ld /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/pop.framework/pop normal i386
	GenerateDSYMFile /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/pop.framework.dSYM /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/pop.framework/pop
	Ld /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/Channels.app/Channels normal i386
	GenerateDSYMFile /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/Channels.app.dSYM /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/Channels.app/Channels
	Ld /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/ChannelsTests.xctest/ChannelsTests normal i386
	GenerateDSYMFile /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/ChannelsTests.xctest.dSYM /Users/Stuart/Library/Developer/Xcode/DerivedData/Channels-gtqfdtofjptjyddzlcsmzkppvsqf/Build/Products/Debug-iphonesimulator/ChannelsTests.xctest/ChannelsTests
(7 failures)
None

The xcodebuild command on its own compiles fine

Have you tried using the workspace in the xcodebuild command, as explained in https://github.com/facebook/infer/issues/84#issuecomment-114098965?

I am using -workspace.

do you have a simple example that I can use to reproduce the issue?

here is a project I have that is structured similarly and had the same failure: https://github.com/tettoffensive/ASCollectionViewTest

Hello @tettoffensive do you know whether your issue is now solved using our latest release?
Thanks!


Adjust Freecen2 Place fields that are displayed and/or edited

I am looking at the form for entering a new Place to the place name file.
The screen appears to have been copied from FreeREG, who only deal with UK places and therefore Genuki becomes a reference.
I am currently adding New South Wales, so obviously that is not in Genuki.
Can we amend the caption to become more general please? Perhaps ‘Gazetteer website (e.g. Genuki)’ would be more suitable as it is less specific.

Changes made. Deployed to test3

New caption is fine.
This item can be closed.
Geoff


BLST Library Decoding Errors Not Handled Correctly

Deserialization of points into BLST structures may fail, but the errors go unhandled. This risks the ability to pass invalid points into the ceremony and must be fixed.

Fixed in #142


Privatize web socket client pending concrete implementation

As discussed awkwardly late on #5520.

Nah, didn't occur to me until I was getting ready to brag about it in the release notes.


Injection broken due to inject.js going missing

As alluded to in https://github.com/remy/jsconsole/issues/66#issuecomment-219896798, requesting http://jsconsole.com/inject.js or https://jsconsole.com/inject.js yields a 404 response, with the body:
{"code":"ResourceNotFound","message":"/inject.js"}

This makes it so the bookmarklet is no longer functional.

inject.js went away again 😢


Create Search+Copy+Hover Feature for docs OnyxIconLibrary

We want to create a search / copy feature in apps/docs/src/.vitepress/components/OnyxIconLibrary.vue

+ Improve the hover behavior, currently we use the standard browser feature which might take 3secs until a hover reacts.

do we also need a svg-download feature here?

Figma:
https://www.figma.com/file/YfEUBOHk4J4nYrk04geswG/onyx---Design-System-Figma-Library?type=design&node-id=662%3A5755&mode=dev&t=ei4JbTU8gYxuxFmN-1

do we also need a svg-download feature here?

Currently we just linked to the files in GitHub for the download but I guess a download feature might be handy.
Maybe we could add a switch at the top to switch between "Copy code" and "Download SVG" when clicking?

I Think a swith is not that handy. I think it would lead to a lot of unwanted downloads :D
A modal like this is the more understandable way for people
https://icons.stackit.schwarz/attachment
But this is no priority task for now I guess.

=> so we don't do a download for now, we just implement copy on click, right?

Note: aliases are empty for now. in the future, we will investigate how to import them from figma automatically.

Note: aliases are empty for now. in the future, we will investigate how to import them from figma automatically.


Fix/refactor frontend

No need to change dockerfile ?

@athos7933 You're right, it'll come in another commit 😉


Table View should have ability for users to resize columns

🙋 Feature Request
Requesting the ability for the table view to have a feature to allow users to resize the columns. Users have different needs for screen real estate.
😯 Current Behavior
Fixed table column sizes
🔦 Context
The Adobe Sign Manage page has many customers requesting the ability to change column sizes.
🧢 Your Team
Adobe Sign - Document Cloud
🎁 Tracking Ticket
DCCR-2323

Superseded by https://github.com/adobe/react-spectrum/issues/2555. Please track there. Going to close this one.


GPU CI - Add build status icon to README

To match libgdf and link to the master GPU CI builds for pygdf Pull request testing is active as well. Working on documentation for that separately.

Also, LGTM

LGTM, thanks, merging!


Mahalanobis distance penalty

I would like to have a penalty of the form: vecnorm(C*x).^2 for a specified matrix C. There are several contexts in which this is useful (for example, it can enforce a smoothness penalty on x)
Here is a derivation for the proximal operator (here I used D instead of C... sorry):

Right now I have some placeholder code that is quite slow:
function _prox!{T <: Number}(p::MahalanobisPenalty{T}, A::AA{T, 1}, s::T)
    y = (p.C'p.C + (one(T)/s)*I) \ (A./s)
    copy!(A,y)
end

I would be much much better if we computed Z = (p.C'p.C + (one(T)/s)*I) and once and stored the LU factorization so that we could compute Z \ (A./s) very quickly on each iteration/call to prox.
Any thoughts on how to implement this into the code?

@joshday - how does this look to you now? Any ideas for more thoroughly testing this?

Looks good to me.  👍


Garbled PCM track when using XGM ROM builder

Thanks for putting this together.  I'm trying to use the included XGM ROM builder to build a ROM to use on a real Genesis model 1 to do some recording.  I finally got it working and tried out the ROM in an emulator, but the drum track played on the PCM channel of the YM2612 is garbled.  That's the best way I can describe it.  Here's a recording of Green Hill Zone from Sonic 1 to illustrate:
ghz-garbled-drums.zip
I've seen reference to this problem on the interwebs, but it's from several years ago, so I'm hoping this is a known issue with a known fix and you can just let me know what to do.  (Like maybe the player ROM is out of date or something.)
Sorry if I'm posting to the wrong place.  I really can't find any other source of the XGM player ROM or ROM builder.  I know there's a magic rom.bin file that contains the player, but I don't know where the source code for that actually resides.  Of course, this could also be an issue with xgmtool and how it converts the .vgm to the XGM format.  But the .vgm source file I used plays correctly using libvgm and DeadFish's VGM player ROM (other than being about 98% speed on a the real Genesis, which is why I'm trying out this one instead).
In other news, I'm on Linux.  I could use some instructions for building xgmtool, as xgmRomBuilder.txt says you need to build it if you're on Linux, but I couldn't find instructions on how.  Instead, I pulled it out of the Docker image referenced in this project's README.  I also had to make a few fixes to the XGM ROM builder project, and that's probably also due to the fact that the release history mentions Java 6, but I didn't want to install that, so I used Java 8 to run it.  The fixes are around reading the rom.bin resource and executing the xgmtool process, but should not have any effect on the actual XGM conversion or playback.

Hi @meyertime
There are several thing to know about the XGM driver.
First, the PCM output rate is fixed to 14 Khz so it's generally better to use 14 Khz PCM too to avoid distortion due to the (poor) resampling algorithm used by rescomp tool.
The other thing to know is that XGM ROM Builder is outdated and do not use the last version of the XGM driver nor the last version of XGM Player and rescomp tool, so definitely you may have better results just by directly using the XGM Player sample sources so you can customize it to your needs (at least modify the track list).

Thanks, @Stephane-D.  I built the latest XGM Player in the sample folder.  It works, except I noticed a similar issue with the included Ice Cap Zone music.  I built it with Green Hill Zone, and it has the same issue, unfortunately.  However, I stripped all the channels out of the .vgm except for the PCM to get a better listen at what's going on.  Here's a recording of just the strange drum track by itself, along with a recording through libvgm of the way it's supposed to sound:
ghz-garbled-drums2.zip
Here are my observations:

The kick sound is played at a higher rate than it should be.
The snare sound is played at the correct rate when it is played at the correct time.
There are additional snare hits between when the kick and snare are supposed to be.  These snare hits are played at a lower rate than they should be.
Sometimes the snare doesn't hit when it's supposed to, and instead, the additional snare hit that happened right after the kick continues playing.  Other times, the snare does hit when it's supposed to, interrupting the previous note.

So, a theory:

The kick sound may have been sampled at a lower rate in the original game in order to save space in the ROM.  That would make sense, since kicks don't have as much treble anyway.
When played at the correct rate, the kick sample takes up all the time until the snare hits.  But since it's played at too high a rate, playback continues into the next sample in memory, which happens to be the snare sample, thus why there's an extra snare hit that shouldn't be there.
This still doesn't explain the difference in pitch between the correct snare hit and the additional incorrect ones...

And some questions:

You said PCM is fixed at 14kHz.  Does that mean that the samples are resampled to 14kHz ahead of time?  (Like during the VGM -> XGM conversion?)  Or are they resampled on-the-fly?
I want to be as authentic as possible to the way the music sounded in the original game.  The reason I'm using a ROM to play VGM files is so that I can isolate individual channels and still play them through the real hardware.  So if the samples are resampled to 14kHz, would that affect the way they sound when played through the YM2612 chip?  Or is it something like nearest neighbor, and the extra writes to the DAC won't matter since the value stays the same for the extra samples and the DAC will produce the same output?

Afaik the Ice Cap Zone music is an example i'm using as it's quite difficult to recover PCM properly.
VGM has different formats and older versions didn't had efficient / correct way of encoding PCM so the XGMTool converter has to recover it from simple DAC register write. The problem is that sound drivers weren't really good for PCM playback so it has many interruptions because of BUS contention or tasks delay so it's very difficult to properly reconstruct samples from that.
What you can try is to play with the extended flag options DI/DR in the XGM ROM Builder tool :

They affect the way PCM data are recovered but honestly it's almost impossible to recover them perfectly from so broken VGM dumps. XGM driver is meant to play 14 Khz samples defined from a directory (sample are resampled during conversion of course) so it can't play them the same play as the (huge) VGM dumps . The change in sample rate shouldn't affect too much the output as soon we are at higher sampling rate, at lower rate of course that would make a difference.

@meyertime Did you tested the last proposed solution ? Should definitely fix your issue.


Remove old CI workflow and reuse new one

Description of your changes
In this PR:

Added ccrddiff to Makefile
Updated uptest version to v0.5.0
The old CI workflow has been converted to the caller workflow. Consumes reusable workflows introduced in https://github.com/upbound/uptest/pull/68 and https://github.com/upbound/uptest/pull/75

I have:

[x] Run make reviewable to ensure this PR is ready for review.

How has this code been tested
crddiff:

It skips when no changes are made

On line 75 in provider-terraform/apis/v1beta1/workspace_types.go replace

Name string `json:"name"`

with
// +kubebuilder:validation:Optional
Name *string `json:"name,omitempty"`

Caller workflow manually tested on turkenf/uptest and turkenf/provider-terraform

something is wrong with check diff

Thank you, I am working on this

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

/test-examples="examples/workspace-inline-aws.yaml"


Question: More than one EOS token in the Jinja chat formatter

I'm using https://github.com/abetlen/llama-cpp-python/blob/main/llama_cpp/llama_chat_format.py#L167 but we consider more than one EOS token. I'm mostly convinced that Jinja templates can only accept the one string literal as an EOS option, but I'm curious if there'd be another recommended option. Thanks!

I am curious about this, could you show some examples about more than one EOS token?

This is a non-issue, I think it can be closed, I was misinterpreting the use of the eos_token in the template vs. in the chat handler.


Support PHPUnit 6

I use the PHPUnit\Framework\TestCase notation instead of PHPUnit_Framework_TestCase while extending our TestCases. This will help us migrate to PHPUnit 6, that no longer support snake case class names.
I just need to bump PHPUnit version to ^4.8.35 and ^5.7, that support this namespace.

The leading \ for the other use statements is wrong and should be removed.

Codecov Report

Merging #1238 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1238   +/-   ##
=======================================
  Coverage   72.31%   72.31%
=======================================
  Files          35       35
  Lines        5549     5549
=======================================
  Hits         4013     4013
  Misses       1536     1536

Continue to review full report at Codecov.

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

I've added PHPUnit 6 support. This will help us test against PHP 7.2, that the each method was deprecated.
I added a setExpectedException method layer, because it was removed in PHPUnit 6.


remap a shortcut for powertoy.run not working

Microsoft PowerToys version
0.78.0
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
Keyboard Manager
Steps to reproduce
remap a shortcut by keyboard manager is not working.

✔ Expected Behavior
In powertoy.run, ctrl-n will move to next item.
❌ Actual Behavior
ctrl-n not working
Other Software
None

Since this update I am getting intermitent issues with keyboard manager. After a while is not working anymore and I have to restart computer (restarting powertoys doesn't help)

solved by using PowerToys.PowerLauncher.exe target name.
reference: https://github.com/microsoft/PowerToys/issues/18893#issuecomment-1166624221


iio: Replace the marco with an inline function

Signed-off-by: Yong Li<EMAIL_ADDRESS>

@edersondisouza @laykuanloon please help to review this PR, it is based on PR #2231 and PR @2215

@yongli3
I have problem when patch this. The sensor scale become 0 causing all my data print out become 0.
WRN: ./src/lib/io/sol-iio.c:559 iio_set_channel_scale() Could not set scale to 0.000000 on channel [in_accel_x] of device0
DBG: ./src/lib/io/sol-iio.c:978 sol_iio_add_channel() channel [in_accel_x] added. scale: 0.000000 - offset: 0 - storagebits: 16 - bits: 12 - mask: 4095
If use PR #2231 then the scale is correct
DBG: ./src/lib/io/sol-iio.c:978 sol_iio_add_channel() channel [in_accel_x] added. scale: 0.019163 - offset: 0 - storagebits: 16 - bits: 12 - mask: 4095

I'm inclined to go with this patch instead of #2231. Once @yongli3 fixes it it should be fine. @laykuanloon any other comments about it?

Many thanks to @edersondisouza @laykuanloon! I fixed the typo and please help to review it.

Thanks @yongli3 . It seems right
Merged


Add expand tensor operation similar to PyTorch

Summary
I am proposing the addition of an expand tensor operation to the Burn deep learning framework, mirroring the functionality available in PyTorch. This operation is invaluable for broadcasting operations on tensors of different shapes, making certain types of tensor manipulations more intuitive and efficient.
Motivation
In PyTorch, the expand method allows users to expand the size of an existing tensor without copying data. This is particularly useful for performing operations that require tensors to be of the same shape, enabling more memory-efficient computations by avoiding the creation of large intermediate tensors. Its inclusion in Burn would greatly enhance the framework's tensor manipulation capabilities, aligning it more closely with PyTorch's feature set and making it more appealing to users transitioning between frameworks or leveraging both for different aspects of their work.
Technical Details
The expand function in PyTorch allows a tensor to be "viewed" with a larger size, with the new dimensions being broadcastable according to the broadcasting rules of tensors. The operation does not allocate new memory for the expanded tensor but provides a new view on the existing tensor, which is a very efficient way to perform many element-wise operations.
I propose that the API for the expand operation in Burn should closely mirror that of PyTorch for ease of use and familiarity.
Use Cases
This feature is crucial for operations where matching tensor dimensions is necessary without the need to duplicate data. For example, when adding a vector to each row of a matrix, or applying a mask across multiple dimensions of a tensor where the mask is initially only defined in a subset of those dimensions.
Example
In PyTorch, the usage of expand is as follows:
import torch
x = torch.tensor([1, 2, 3])
x_expanded = x.expand(3, 3)
# x_expanded is now [[1, 2, 3], [1, 2, 3], [1, 2, 3]] without copying data

A similar functionality in Burn would enable users to perform such operations with the same ease and efficiency.
Conclusion
The addition of an expand tensor operation to Burn could significantly improve its usability and efficiency for a wide range of tasks, making it a more competitive and versatile tool in the deep learning ecosystem. I believe this feature would be a valuable asset to the framework and its users.

From Discord discussion:

[4:15 AM]Zermelo Fraenkel: Just to mention that on the candle side, we handle expand by just setting some stride to 0s, so no copy is involved in the process (until an op is actually performed on the tensor), I guess the same is done in other frameworks.

[7:47 AM]Nathaniel: I though exactly of that, but then, when is it preferable to use repeat?

[9:26 AM]Zermelo Fraenkel: I don't think there is a very good case for doing a "concretised" repeat, you might need it if the next op is a kernel that requires an actual contiguous tensor e.g. matmul for some candle backends but it's more of an edge case.  repeat is just a shortcut for .expand().contiguous() and this seems a bit annoying to have such a subtle difference even if it's inherited from pytorch https://pytorch.org/docs/stable/generated/torch.Tensor.repeat.html


Safari forOf and spread issues for Set object.

When using the Set object, the following code fails in Safari 8 desktop and mobile:
"Error: undefined is not a function (evaluating 'f.next()')"
var set = new Set([1,2,3,4]);

var arr = [...set]; // FAIL

for (var v of set) // FAIL
  console.log(v);

var vals = set.values();
for (var v of vals) // FAIL
  console.log(v);

Note: This code fails to compile in the Traceur REPL on Safari.
https://google.github.io/traceur-compiler/demo/repl.html#var set %3D new Set([1%2C2%2C3%2C4])%3B

var arr %3D [...set]%3B

for (var v of set)
  console.log(v)%3B

var vals %3D set.values()%3B
for (var v of vals)
  console.log(v)%3B

spread@https://google.github.io/traceur-compiler/bin/traceur.js:1316:38

getAnonymousModule@https://google.github.io/traceur-compiler/bin/traceur.js:681:34
eval code
eval@[native code]
evaluateCodeUnit@https://google.github.io/traceur-compiler/bin/traceur.js:29800:36
evaluate@https://google.github.io/traceur-compiler/bin/traceur.js:29956:50
evaluate@https://google.github.io/traceur-compiler/bin/traceur.js:30257:37
handleCodeUnitLoaded@https://google.github.io/traceur-compiler/bin/traceur.js:30170:24
module@https://google.github.io/traceur-compiler/bin/traceur.js:30056:32
module@https://google.github.io/traceur-compiler/bin/traceur.js:30317:41
transcode
compileContents
compile
wrappedFunc

yeah, iterator protocol in JSC is still a work in progress. last I checked (in jan/feb), @@iterator wasn't exposed at all in JS, and was only implemented for specific types (just arrays, maybe).
maybe it would make sense to always use the polyfilled version for JSC?

We should probably be a lot stricter when it comes to determining when to use the polyfills. One suggestion is to use the polyfills if there is no [Symbol.iterator].

I just ran into a similar issue with Safari on iOS 8.1.3. The problematic cases in my case were for-of over an Array as well as construction of a Map from an Array (or iterable). The specific reasons were that

Safari natively implements Array.prototype.entries and Array.prototype.keys, but the iterators returned by them lack a next method.
Safari natively implements Map, but the constructor does not take an argument.

I can work around the problems by including the following as the first script of the page:
// Remove insufficient built-in implementations so that the polyfills from traceur-runtime kick in.
if (Array.prototype.entries && typeof [1].entries().next !== 'function') {
	delete Array.prototype.entries;
}
if (Array.prototype.keys && typeof [1].keys().next !== 'function') {
	delete Array.prototype.keys;
}
try {
	new Map([]);
}
catch(e) {
	delete Map;
}

I assume these checks could be built into the polyfillArray and polyfillMap functions but have not tried that.

Safari natively implements Array.prototype.entries and Array.prototype.keys, but the iterators returned by them lack a next method.

WHAT!! How do you iterate over them then? How can they ship something so broken... makes me very sad.
@cwalther What does Map.length return in Safari? If it says 0 we should be able to use that instead of using the try/catch.

I believe they've since fixed this in JSC (but still don't expose Symbol.iterator, afaik)

I have no idea what the purpose of these iterators is, they appear to have no methods (or other properties) at all besides the ones inherited from Object.
Map.length indeed returns 0. (I wasn’t even aware that functions had a length property, thanks for pointing me to that!)
Interestingly, Set.length is 0 as well, but new Set([4, 5]) still works (Set([4, 5]) on the other hand throws TypeError: Set does not accept arguments when called as a function ).

TypeError: Set does not accept arguments when called as a function

Sad. So misleading. Set throws when called.
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set-iterable
Step 1

I just see in that document that Map.length should be 0, unless I’m misunderstanding something, so maybe checking for that is not a suitable way of detecting insufficient implementations after all.
By the way, es6-shim also fixes the issues I had on that version of Safari, and it has a whole bunch of criteria for checking whether to replace Map, maybe that’s a more reliable source. (I didn’t use es6-shim as a final solution because I was wary of potential unintended interactions between es6-shim and traceur-runtime.)

You are correct. Map.length should be 0.
I think a suitable test is to see if Map.prototype[Symbol.iterator] is a function.

@cwalther @arv bad idea. es6-shim also has a problem - it's replace collections in all modern environment. Maybe it's partly fixed after yesterday's reworking. My point about collections polyfilling here.


fix: IssuerKeyId non-critical

So, let me start by saying I'm not crypto/gpg expert or anything. If this is wrong, I'd appreciate being pointed to the right direction 🙏
I maintain nFPM and GoReleaser, and, when golang.org/x/crypto was deprecated, I switched to your fork.
On commit cc34b1f it broke signatures for RPM versions, so I locked into the previous commit (c05353c).
After some time, I noticed that the latest commit (at the time, and now too) works RPM 4.17+ too.
I have been postponing investigating this properly for a couple of years (I think), today I finally went down the rabbit hole:

created tests signing and checking on several versions of fedora and centos, ranging RPM 4.14 - 4.18
made a sort of manual bisect of this project trying to find which commit fixed 4.17 so I could try to fix for other versions too

Finally, found it: a4f6767
It was the clue I needed to try to fix the whatever else is broken.
Then, through git blame, I found aef62243dce8452451d6dd6c009b22c58a6a50fa, which adds v5 signatures, but also changes the Issuer Key ID packet to critical on v4.
Change: https://github.com/ProtonMail/go-crypto/commit/aef62243dce8452451d6dd6c009b22c58a6a50fa#diff-65b30b147e6c8432806b9ff7fa5f3368af59ccbd942e99582137fa0cd46978f6L782
I'm not sure if that particular change is intentional or not, but reverting it (making issue key id non-critical in v4) fixes everything for all RPM versions.
Again, I don't know if this is correct per GPG spec and RPM is wrong, or the other way around, or something else, all I know is that this seems to fix thing and doesn't seem to break any tests.
Thanks for your time, and sorry about this whole novel of a writing.
Happy weekend!

forgot to link issue in nfpm: https://github.com/goreleaser/nfpm/pull/680

reading RFC 2440, the only thing about critical that I found is in the section <IP_ADDRESS>, Signature Subpacket Specification:

Bit 7 of the subpacket type is the "critical" bit.  If set, it
denotes that the subpacket is one that is critical for the evaluator
of the signature to recognize.  If a subpacket is encountered that is
marked critical but is unknown to the evaluating software, the
evaluator SHOULD consider the signature to be in error.
An evaluator may "recognize" a subpacket, but not implement it. The
purpose of the critical bit is to allow the signer to tell an
evaluator that it would prefer a new, unknown feature to generate an
error than be ignored.


[DRAFT] Remove db partition metadata from actor reminder storage.

Description
Remove db partition metadata from actor reminder storage.
Issue reference

Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

@artursouza I reopened this.

/ok-to-test

/ok-to-test

/ok-to-test


[FEATURE] Admin page feature - manual event merge

Description
Events are grouped now, but the grouping may miss depending on how the input is received.  This feature would allow admins to merge 2 or more events that are the same into one via an admin interface that would allow:

Selection of which to merge into the other (ex. which title to keep)

Current example of issue this would solve - Duplicated WeAreDevs Con:

Screenshots
No response
Additional information
No response

This is a great idea 👍  As we do have some the same but with different urls so cannot be auto merged

This is a cool Idea I would like to work on this.

I would like to add one more thing. As it is said that the "prevention is better than cure" it would be better if we do not allow user to paste the link if it already exists and notify user that this event already exists.

Problems comes when two different users post same event with different links. for example 👇:

Both of the URLs points to the same event. But the URLs are different.

I think this can be solved using time of the event and the domain. The idea is that the organisers would never conduct two tech events at the same time.
I would like to ask the community for any better ideas about filtering the same events.

you could look at discussion here on issue #8390

Could we have the admin just update the domain to make them consistent and then the app will automatically merge the events


just(range) passes the range as output instead of the matched value (1.0.7 alpha)

Repro:
use chumsky::prelude::*;
#[derive(Clone, Debug, PartialEq, Eq, Hash)]
pub enum Instr { Name(char) }
fn parser<'a>() -> impl Parser<'a, &'a str, Vec<Instr>, extra::Err<Rich<'a, char>>> {
    let name = just('a'..='z').map(Instr::Name);
    name.padded().repeated().collect()
}

This does not compile due to:
error[E0631]: type mismatch in function arguments
   --> src/lib.rs:9:36
    |
5   |     Name(char),
    |     ---- found signature defined here
...
9   |     let name = just('a'..='z').map(Instr::Name);
    |                                --- ^^^^^^^^^^^ expected due to this
    |                                |
    |                                required by a bound introduced by this call
    |
    = note: expected function signature `fn(RangeInclusive<char>) -> _`
               found function signature `fn(char) -> _`
note: required by a bound in `chumsky::Parser::map`
   --> /Users/orvar/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.7/src/lib.rs:519:18
    |
519 |     fn map<U, F: Fn(O) -> U>(self, f: F) -> Map<Self, O, F>
    |                  ^^^^^^^^^^ required by this bound in `Parser::map`
help: consider wrapping the function in a closure
    |
9   |     let name = just('a'..='z').map(|arg0: RangeInclusive<char>| Instr::Name(/* char */));
    |                                    ++++++++++++++++++++++++++++            ++++++++++++

I now recall why I didn't implement this: just accepts sequences, not just individual characters.
I think this is potentially a good reason to re-deduplicate just, splitting it into just and seq as before. That way, the behaviour of just(0..4) would be to accept any number from 0 to 4 (exclusive) and seq(0..4) would be to accept a sequence of numbers, 0-3 (inclusive).
Re-deduplicating would allow for the behaviour you're looking for!

I just made an initial attempt at this, but ran into problems: it led to a constraint such that just required the input to implement ValueInput, which isn't always practical, making just difficult to use for token streams and the like. One could feasibly imagine a solution that involves splitting out just into 3 combinators, like so:

just(...): doesn't return the token (works with all inputs)
filter(...) returns the token by-value (requires I: ValueInput)
seq(...) returns the matched tokens by-ref (requires I: SliceInput)

Thoughts welcome on this!


Remove Archive node requirement for contract calls

I understand the importance of the archive nodes for production subgraph, but since I'm using a local graph node connected to a local anvil node to do some testing, I really don't care about data consistency.
I wonder if is there any way to make contract calls without the need of a archive node? and use a simple ganache/anvil node?

"Normal" (so geth, erigon) RPC node can perform eth_call only on the latest 128 blocks. A Subgraph can started syncing way before those 128 blocks.
We cannot lift this requirement. If you are sure of you, just pretend your provider is an archive node, I do this for development often without any issue, graph-node don't check, it uses it only as a way to pick the right provider.


ghost-<IP_ADDRESS>: SHA256 checksum FAILED! Try again later. Exiting.

Ran into this issue when using ghostman script to update to latest version of ghost-core:
$ ghostman/bin/ghostman.sh update
ghostman version 0.12 - Tue 02 Mar 2021 11:32:48 AM UTC
gathering info, please wait...   done!

*** a newer version of ghost is available. ***

  current version:  <IP_ADDRESS>
   latest version:  <IP_ADDRESS>

download https://github.com/ghost-coin/ghost-core/releases/download/v<IP_ADDRESS>/ghost-<IP_ADDRESS>-x86_64-linux-gnu.tar.gz
and install to /root/ghostcore? [y/N] y
 --> Downloading https://github.com/ghost-coin/ghost-core/releases/download/v<IP_ADDRESS>/ghost-<IP_ADDRESS>-x86_64-linux-gnu.tar.gz...  done!
 --> Checksumming ghost-<IP_ADDRESS>-x86_64-linux-gnu.tar.gz...   SHA256 checksum FAILED! Try again later. Exiting.```

should be resolved by https://github.com/ghost-coin/ghostman/commit/761437225a8d8fc8f28017a68355e93d25874098

I'll test this tonight and let you know my results.

Did a git pull and still got the same issue.
$ cd ghostman && git log | head && cd ..
commit 761437225a8d8fc8f28017a68355e93d25874098
Author: barrystyle<EMAIL_ADDRESS>Date:   Wed Mar 3 12:06:25 2021 +0800

    update for different extension

commit 6aff82e1a0fe47b08302e94b0f7b304d594edcca
Author: akshaynexus<EMAIL_ADDRESS>Date:   Sun Jul 5 00:15:19 2020 +0300

$ ghostman/bin/ghostman.sh update
ghostman version 0.12 - Thu 04 Mar 2021 01:35:29 AM UTC
gathering info, please wait...   done!

*** a newer version of ghost is available. ***

  current version:  <IP_ADDRESS>
   latest version:  <IP_ADDRESS>

download https://github.com/ghost-coin/ghost-core/releases/download/v<IP_ADDRESS>/ghost-<IP_ADDRESS>-x86_64-linux-gnu.tgz
and install to /root/ghostcore? [y/N] y
 --> Downloading https://github.com/ghost-coin/ghost-core/releases/download/v<IP_ADDRESS>/ghost-<IP_ADDRESS>-x86_64-linux-gnu.tgz...  done!
 --> Checksumming ghost-<IP_ADDRESS>-x86_64-linux-gnu.tar.gz...   SHA256 checksum FAILED! Try again later. Exiting.


test/eas/acceptance: documentation fixes

Some minor documentation fixes xoming from the EAS 1.1 integration guide.

I know this conflicts with @bjackman 's #197 and I'm happy to wait for that to be merged before this goes in.  I just wanted to put this here as a reminder to keep the integration guide and the tests "in sync".

@bjackman you want this in before your #197?
In that case, please merge this and refresh your PR on top of it. ;-)


Adding a public key doesn't add it to repository permissions

Using 1.1.3 with redmine 2.6.6.
When a user adds a public key to their redmine account, the key is added to gitolite but not given RW permission for repositories of projects they have access to.
This used to work with an older version of redmine and redmine_git_hosting (from a few years ago).
SSHing with the newly added key connects to gitolite fine but only returns RW access to the "testing" repo.
All config checks in the plugin's settings pass.
This is what what the plugin's log says when deleting and readding a key:
2015-09-15 14:50:26 -0400 [INFO] User 'sdragnev' has deleted a SSH key
2015-09-15 14:50:26 -0400 [INFO] Accessing gitolite-admin.git at '/tmp/redmine_git_hosting/git/gitolite-admin.git'
2015-09-15 14:50:27 -0400 [INFO] Deleting SSH key
2015-09-15 14:50:27 -0400 [INFO] delete_ssh_key : commiting to Gitolite...
2015-09-15 14:50:38 -0400 [INFO] User 'sdragnev' has added a SSH key
2015-09-15 14:50:38 -0400 [INFO] Accessing gitolite-admin.git at '/tmp/redmine_git_hosting/git/gitolite-admin.git'
2015-09-15 14:50:39 -0400 [INFO] Adding SSH key redmine_sdragnev_102@redmine_dev1
2015-09-15 14:50:39 -0400 [INFO] add_ssh_key : commiting to Gitolite...

No sign of trouble.
Redmine sees the project repositories fine so I think the link between the project and repo is fine.
Any tips to troubleshoot this?

When a user adds a public key to their redmine account, the key is added to gitolite but not given RW permission for repositories of projects they have access to.

This is normal. These 2 notions are now decoupled as you can access to the repository via SSH or HTTP (SmartHTTP).
So when you declare a user as a project's member it is automatically added to the Gitolite config file in the repository section. If not this might be the root of the issue.

I tried removing and re-adding a user to a project and the new key wasn't added to the gitolite config. Nothing changed in fact - keys weren't being removed either.
I wonder if it's some issue with not properly migrated repo-key links with redmine.

Okay...
I hadn't enabled the "Xitolite" SCM setting in redmine. I had git but no "xitolite". Whatever xitolite is.
I finally got an error from the plugin when I test-created a new repo. After tracing the error trigger, I saw the xitolite check in the code.
Mystery solved but at what twisty cost!!


assertion error " assert qkv.dtype == torch.float16"

I wanted to test out your flashattention implemention for a problem that I have been working out.  I tried to create a simple single layer attention module but I am getting an assertion layer error.  This is my module
class multiple_heads_attention(nn.Module):
    def __init__(self, model_params):
        super().__init__()
        self.num_bins = model_params['num_bins']
        self.bin_width = model_params['bin_width']
        self.d_model = model_params['d_model']
        self.n_transformer_heads = model_params['n_transformer_heads']
        self.num_outputs = model_params['num_outputs']
        self.input_dim = 4
        self.token_emb = nn.Linear(self.input_dim, self.d_model, bias=False)
        self.max_seq_len = context_length
        #self.pos_emb = nn.Embedding(self.max_seq_len, self.d_model)
        self.linear = nn.Linear(self.d_model, self.num_outputs)
        self.m_pos = nn.Softplus()
        self.flash_mha_1 = FlashMHA(self.d_model,
                                    num_heads = model_params['n_transformer_heads'],
                                    attention_dropout = .1,
                                    use_rotary_emb = '1d')
    def forward(self, x, **kwargs):
        x = x.transpose(1, 2)
        x = self.token_emb(x)
        x = self.flash_mha_1(x,x,x)
        return x

but I get an error
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/sc/arion/projects/ad-omics/clakhani/conda/envs/flash_attention_lightning/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
    return forward_call(*input, **kwargs)
  File "<stdin>", line 27, in forward
  File "/sc/arion/projects/ad-omics/clakhani/conda/envs/flash_attention_lightning/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
    return forward_call(*input, **kwargs)
  File "/hpc/users/lakhac01/flash-attention/flash_attn/flash_attention.py", line 112, in forward
    context, attn_weights = self.inner_attn(qkv, key_padding_mask=key_padding_mask,
  File "/sc/arion/projects/ad-omics/clakhani/conda/envs/flash_attention_lightning/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1102, in _call_impl
    return forward_call(*input, **kwargs)
  File "/hpc/users/lakhac01/flash-attention/flash_attn/flash_attention.py", line 41, in forward
    assert qkv.dtype == torch.float16
AssertionError

I'm guessing I need to cast my vectors as torch.float16?  If I do that then it causes an error with my linear embedding layer.  I'm trying to understand what to do in this case.  Also, what is the purpose of the arguments "x_ignored_, x_ignored_1_" in the forward pass?  I just put x back into the model because I'm not sure what else I should do.

Yes, we currently support fp16 only. You can run your model with torch AMP (https://pytorch.org/docs/stable/amp.html).
The arguments "x_ignored_, x_ignored_1_" are completely ignored, this was because we were at some point trying to maintain the same interface as Pytorch MHA (https://pytorch.org/docs/stable/generated/torch.nn.MultiheadAttention.html).
But I see that it's confusing, so I'll redo the interface soon.

Thanks for letting me know!  Have you tried this with PyTorch lightning?  I am guessing I just need to set the precision flag to 16?
For the time being I'm guessing this is the right way to use forward?
x = self.flash_mha_1(x,x,x)

Yes, we've been training models with Pytorch lightning, setting precision to 16.
Yes, that the right way.

Great, thank you
On Fri, Jun 10, 2022, 11:24 AM Tri Dao @.***> wrote:

Yes, we've been training models with Pytorch lightning, setting precision
to 16.
Yes, that the right way.
—
Reply to this email directly, view it on GitHub
https://github.com/HazyResearch/flash-attention/issues/9#issuecomment-1152478351,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQMA5S6ZI55M3JA2D33QBDVONMZTANCNFSM5YJ76LUA
.
You are receiving this because you authored the thread.Message ID:
@.***>


Default directives should be applied before configs are resolved

At the moment it is not possible to do (e.g.) defaultDirectives: { width: "10;100" } since this is only applied after the configs have been resolved, and so cannot generate multiple images.

Ah, this is basically the same as #139

Yeah I'm open to reconsider this, so lets to further discussion over at #139!


Package Structure

In order to make it easier to package up for PyPI and conda eventually, and also to make other maintenance things easier, you might consider altering the structure (how the files and directories are laid out).
There are some general guidelines and the PlanetaryPy Project offers some concrete examples.  There is a PlanetaryPy Package Template, but that's really to help you start a new, empty repo, and uses some templating tools.  However, you can take a look at the build branch to see an example of what a good layout might look like.
However, here are some specific suggestions:

Rename the craterstats3/ to just craterstats/ otherwise, when you eventually get to craterstats version 4, you'll have to change paths, and the "3" will be in places you forgot about, much cleaner to handle version numbers differently (the PlanetaryPy example shows good practice for where to keep the version number in the package).
While you're at it, you could put that craterstats/ inside a src/ directory, as that's the current recommended practice, but isn't required.
The config/ and gm/ directories should be moved inside the craterstats/ directory.
craterstats.py and demo.py should be moved inside craterstats/
I know, it may seem weird to have a craterstats.py inside a craterstats/ directory, that is, itself inside a "craterstats" repo (which means that there would be a path on your system that would be craterstats/craterstats/craterstats.py or craterstats/src/craterstats/craterstats.py) but again, in the long run, it'll make things easier.
I'm not sure about sample/. If this directory just contains information that will only be useful to developers that are testing things out, leave it where it is.  If it is data that is needed to run the demo, for example, then it needs to be distributed with the package (and wrapped up with it), and so then I'd move it to a data/ directory underneath craterstats/

Moving these things around will likely result in needing to adjust some (but not all) of the import statements and other minor changes.  It is a chore, but will make maintaining this package easier in the long run.

Hi Ross,
Thanks for the suggestions. I've had a try - I've got myself into a bit of a tangle with it. Previously, I saw 'craterstats3' as being package-like, in the sense that it contains the functionality that could be imported into another application. 'craterstats.py' imports this library and implements a command-line interface to it. 'gm' is a personal library that I use across different programs.
I rearranged as you suggested, but I'm not sure I can any longer import 'craterstats3' (now 'craterstats') as a package, since now I am inside it. Or perhaps it's just become ambiguous whether I'm asking for the package or the module 'craterstats.py' if I write 'import craterstats'? I have to admit that figuring out imports has been the most difficult thing for me about python!
Do you have any advice? Does it make sense to import a package from within? Is it better to import a series of modules individually?

Thanks for the suggestions. I've had a try - I've got myself into a bit of a tangle with it.

Yes, import statements definitely take some effort to get the hang of.

Previously, I saw 'craterstats3' as being package-like, in the sense that it contains the functionality that could be imported into another application.

Yes, this is exactly how you should think of it.

'craterstats.py' imports this library and implements a command-line interface to it.

Right.

I rearranged as you suggested, but I'm not sure I can any longer import 'craterstats3' (now 'craterstats') as a package, since now I am inside it. Or perhaps it's just become ambiguous whether I'm asking for the package or the module 'craterstats.py' if I write 'import craterstats'? I have to admit that figuring out imports has been the most difficult thing for me about python!

Okay, this is the tricky part: craterstats.py is, itself a "part" of that package (because when you eventually distribute it, you want people to get that command-line program), and so must be "inside" the craterstats/ directory.
Indeed, the problem is that there is a name clash between the "package" name, and the name of the file that contains your command line program.  I should have realized that earlier.   I think there are two solutions:

Your craterstats.py file cannot import craterstats, but must import things the same way that your __init__.py does (e.g. from .Epochs import Epochs).  This can be unsatisfying, and may still result in some problems, I'm not sure without testing.
Rename craterstats.py to a different name, so there is no name collision.  The name collision comes from the fact that the Python import mechanism has a conflict between craterstats/__init__.py and craterstats.py.  Giving it a different name should allow you to import craterstats from the newly-named file.

This second solution seems counter-intuitive, but let me tell you how it would work.  Typically, people would name that file cli.py to clearly indicate that it is a command line interface (CLI) to the package/library.  Now, you may wonder how would people that use your package be able to run:
> craterstats

to run your cli.py file when they get the package?  The answer is in the magic of the Python package management tools.  Eventually your repo will have a setup.py file like the example, and it will have this in it:
entry_points={
        "console_scripts": [
            'craterstats=craterstats.cli:main',
        ],
    },

With the above in your setup.py when someone installs the craterstats package via pip or conda install, they will suddenly magically have a craterstats program that does what they expect.
There are fancy things you can do to create a "development" environment for testing (so you have a "craterstats" command line program available while you work), but the easiest thing to do is move your current craterstats.py to craterstats/cli.py (or whatever name that isn't "craterstats"), and then create a new file called maybe cs at the top level of the repo, make it executable with this in it:
#!/usr/bin/env python

import craterstats.cli as cs

cs.main()

Then you can run /path/to/cs which should "execute" your command line program, and will be the most similar to what users will eventually see.  That file doesn't need to be committed to the repo if you don't want to.
I know this sounds like a lot of bending around to do what you think you've already got "working" but this arrangement will help your future self out.

'gm' is a personal library that I use across different programs.

Ah.  So you could create a separate gm repository and package it as a Python module separate from craterstats and then craterstats would depend on gm just like it depends on numpy.
However, I think at the moment, you can keep it as a part of craterstats.  If you end up authoring a bunch of packages that all really do depend on gm, then you can split it out.

Do you have any advice? Does it make sense to import a package from within? Is it better to import a series of modules individually?

That's my advice.  If you change the name of the "program file" then you should be able to import craterstats but it is still good practice to only import the things you directly need, and even then use the local from .Epochs import Epochs pattern.

Woah.  Okay, so all of the above was me shooting from the hip.  I decided to sit down with your code, and see if I could do what I described above.  And I think I ran into what you were talking about.
This is a pretty big can of worms, so my apologies.
The problem is related to the Python import mechanism, the way you use it, and the way you have things laid out.  Turns out, you can keep it named craterstats.py inside of the craterstats/ directory if you want to, but there may still be some gotchas that I didn't run into.
In your gm/ module's __init__.py and elsewhere you made heavy use of the import * mechanism, which brings all of the namespaces up to the top level and then you also have a few places "inside" of the gm/ structure, like file/read_textstructure.py that itself does an import gm which is kind of circular.  All of this makes your current gm/ structure kind of fragile, and which is why moving it inside of craterstats/ leads to all kinds of trouble.  In general, while developing a package you should strive to not use any import * patterns and only consider doing that at the very end once everything is working to maybe help out users of your module's API.
You also have a profusion of files in the gm/ structure which makes it even more complicated.  My suggestion is to collapse all of the files in each sub-directory down to a single file with all of that code in the one file.  So in the gm/ directory, I'd create the file maths.py and put all of the functions from all of the files in the current maths/ directory in that Python module, and then delete the maths/ directory.  Right now, without all of your import * shenanigans, to get at the poisson() function, it lives at gm.maths.poisson.poisson() which has some repetition.  If you put the poisson() function in the maths.py file in the gm/ directory then it would just be at gm.maths.poisson().  Then, for example in your Craterpdf.py file, the import statements might look like this:
from .gm import maths as gmmaths

# ... further down ...
pdf0=gmmaths.poisson(self.k,lam*10**x)

Or you could do this:
from .gm import maths

# ... further down ...
pdf0=maths.poisson(self.k,lam*10**x)

And then if you do this with all of the directories in gm/ some of those will need to reference each other, for example,
the string.py module would need to have:
from .maths import sigfigs

# ... further down ...
    return sigfigs(n,sf)

Again, this may seem like more work, but for modules "inside" the package, they should always be using the from .<module> import <submodule> pattern.
This also allows you to delete the gm/__init__.py file, because now you're always reaching to import only exactly what you need.  The import * pattern that you have in __init__.py should be avoided as much as possible.
So there are some other consequences of this change.
One is that having craterstats.py import demo.py and then having demo.py import craterstats.py seems like a bad move.  However, the demo() function in that file is pretty small, and you can just pull it right into craterstats.py
Another is that you have some hard-coded paths to things, which means that if you put a cs executable file outside the craterstats/ directory, like I suggested above, then all of those paths will need to start with craterstats/, but more importantly, it means that the user's current working directory must always be at the repo level.  That's fine for now, but we'll eventually need to make that more generic so users don't have to cd to a particular directory to run the program.
One more thing I noticed is how you use argparse.  You have a function parse_args() that instantiates a parser, and then runs its parse_args() function.  However, a more robust pattern is to have that function return the parser object.  Then you have the first lines of main() look like this::
def main(args):
    parser = parse_args()
    args = parser.parse_args(args)

You could do that all in one line.  Anyway, the value of having that function return a parser rather than the args object is that this will help with an aspect of documentation down the line.  This documentation page for pvl shows the two command line programs that we provide, and lists their options.  We don't write that out twice, there's a module in the documentation generator that can be pointed to a function in our module that returns a parser object, it then uses that parser object to auto-generate the documentation, so we don't have to update it manually.  Using this pattern also makes integrating the demo function easier, so inside it can just be:
        print(f'\nDemo {i}\npython craterstats.py '+c)
        main((f.format(i) + c).split())

That was ... a lot.  So I have modified the code as I described above and it is working (the demo runs).  I would be happy to share that with you so you can see a working example, but I don't want to just rewrite your code on you.  If I were in your shoes I'm not sure if I'd want to "do it myself" or see an example so I'll let you pick, and I want to be clear that I'm just offering suggestions that you can take or leave.

Hi Ross,
Thanks for all your suggestions! I just completed your previous set, and that got things working again: I updated the repository.
I shall also have a look to sort out this gm structure. I'm not sure about merging the subfolders into single files, since these are only a subset of a much larger number I intend to port as I continue with Python. I would sooner pull out a subset of files than pieces of files for a new project. But I get what you say about the importing gm within the library - I didn't like doing it that way.
I'd be glad to see your changed code. I'll look at the argparse issue, too.
Thanks again.

Now it is my turn to be confused.  I pulled down your changes, and when I try and run it, this happens:
> python cli.py -h
Traceback (most recent call last):
  File "cli.py", line 9, in <module>
    import craterstats as cst
ModuleNotFoundError: No module named 'craterstats'

I know why this is happening (another import issue), but I'm just curious how you are getting it to run with this new configuration?

Ah, ok. I see that now. I ran the demo from PyCharm, which has craterstats/src on the path, so sees the craterstats package.

ok - I moved the library code one further down in the directory structure, not unlike how it was. What do you think of it like that? I changed the argparse code as suggested; moved demo inside now-renamed cli.py. The gm package is not causing any problem now (that I see!), but I'll still look at revising those internal imports.

sorry - it's still not working... leave it a bit

should work now

Ah.  I see what you did, this is looking good.  I've just got a few suggestions that would tweak this just a tiny bit.
I see that you moved things down into craterstatslib/ but you don't need to.  Let me take a different stance on imports than I did above.  Admittedly switching everything around to the from .<module> import <submodule> pattern is a bit much, and is the stance you'd use to try and always import things from "inside" the module.  But we can instead adopt the import pattern that someone "external" to your module would use.
So you currently have this pattern:
import craterstatslib as cst
import gm

The problem is that this pair of lines implies that there is a craterstatslib module and a gm module present in the namespace, and there isn't unless you are exactly in the directory with those two sub-directories.
However,  we can change it to this pattern:
import craterstats as cst
import craterstats.gm as gm

So the idea here is that this is what Python users "outside" your package would use to import your functions and attributes, everything starts with craterstats at the root.  Just like when you use numpy you start with import numpy and everything follows from that.  The other thing about this is that you only need to change the import statements and don't have to mess with the body of the programs.  This is also the import pattern that tests which you will eventually write will need to end up following.  Making this conceptual change then allows you to bring all the stuff (__init__.py included) back up from craterstatslib/ and then you can delete that directory.
The trick here is then how to "call" the program so that it runs, and also has access to these modules which are "part of" the craterstats module.  Before you were having trouble "calling" the craterstats module from craterstats.py because you were "running" craterstats.py from "inside" the directory, and the import mechanism couldn't resolve the name.  The solution is to "run" it from outside (a crutch for now, not particularly different from running it from inside, just a slightly better crutch).
So if you make a little script program, and put it in the src/ directory, and run it from there, then the import pattern above will work (because there's a craterstats/ directory that the Python import mechanism can load).  More importantly, when you move on to packaging this up for distribution, and using setuptools this is how the eventual craterstats command line program that will be installed when users pip- or conda-install the craterstats package.
The other piece to get this to work is to amend the hard-coded paths that you have.  Again, eventually there are ways to abstract those paths, but for now we can leave them hard-coded.  For example, you have template="config/default.plt" that would need to change to template="craterstats/config/default.plt".  Also, sadly, all of the paths to the sample/ directory in config/demo_commands.txt are going to need to get prefixed with craterstats/.  Again this is temporary, and it'll be switched up later.
So my example of all this can be found in this example branch, including a little cs script in the src/ directory.  So to run the program you would:
> cd /path/to/craterstats/src/
> ./cs -h

And you can see the differences from your current set-up by looking at the commit diffs.
I then have one remaining question.  In your get_parser() function you had this:
def get_parser():
    if "parser" in get_parser.__dict__:
        return get_parser.parser
    #
    # ... further down ...
    #
    get_parser.parser=parser
    return parser

And I'm not sure what the intent was here?  Commenting it out didn't break anything, so maybe this was just leftover from some experiments?  Maybe you were trying to save the work of re-building the parser during your successive demo runs, but Python is pretty good about optimizing that under the hood, and I don't really think you'll see a performance hit.

Thanks, Ross. That looks good - I'll try it. Thanks for the github demonstrations, too - that's helpful to see. You're right - the parser code was to avoid rebuilding the parser. I have to work on some other stuff for the next few days... I'll come back to this end of next week.

Hi Ross, I included all the changes you suggested - that works.


Ubuntu build fails with glib-2.0 required by crate glib-sys

I'm not sure why this happens, havent found anything about it regarding actions online. Only someone with an outdated rust setup.
I've got it building locally, but in the action it fails on the ubuntu build:
https://github.com/wolbodo/bifrost/actions/runs/8552800430/job/23434669313#step:8:577
I've followed the docs. It is a tauri@2 app.

You forgot to update the matrix in your last commits https://github.com/tauri-apps/tauri-action/blob/dev/examples/publish-to-auto-release.yml#L17-L26


a11y - sharing page - search icon label - cms ui

Describe the bug

Search icon doesn't have label

To Reproduce

inspect the icon or using a screen reader
<button class="ui icon button"><i aria-hidden="true" class="search icon"></i></button>

Screenshots

ts
Software (please complete the following information):
Volto Version 17.0.0-alpha.19
Plone Version 6.0.4
Additional context
Add any other context about the problem here.

Hello Sir,
What do you exactly want? Do you want a level below the icon or show the label in a tooltip?


Ensure that tmp_disable is set on a thread local

This makes it thread-safe when used in threaded servers such as puma.

Coverage increased (+0.1%) to 90.455% when pulling f9bc113d6a19aef64453ad23b8a35ff99aa1e67b on nebulab:thread-safe-tmp-disable into 6d373391a5b9d28984bc3b868fce8b86a7cc754d on dtaniwaki:master.

No worries, thanks for reviewing and merging!


Self serve flow

don't automatically assign a host when creating a new collective
filter memberOf by type of collective
allow changing host of collective if empty balance
custom redirect and post action after connecting stripe account
added isPublicHost as a parameter to allCollectives

Coverage increased (+0.1%) to 71.461% when pulling 1ae199e367271f71c4b6fc73aadebf9e3939a00e on selfServeFlow into 88f4ce7ab1de160e52f5552da89bf9e93a0165b7 on master.


Non force replica set reconfig can only add or remove at most 1 voting member.

Just got this setup (thank you for your effort!) and my replicas won't join under any circumstances.  When I start with replicas=3, I get the error from the title spewed every 5 seconds.  Here's why, according to Mongo docs:

Reconfiguration Can Add or Remove No More than One Voting Member at a Time
Starting in MongoDB 4.4, rs.reconfig() by default allows adding or removing no more than 1 voting member at a time. For example, a new configuration can make at most one of the following changes to the cluster membership:
Adding a new voting replica set member.
Removing an existing voting replica set member.
Modifying the votes for an existing replica set member.
To add or remove multiple voting members, issue a series of rs.reconfig() operations to add or remove one member at a time.
Issuing a force reconfiguration immediately installs the new configuration even if it adds or removes multiple voting members. Force reconfiguration can cause unexpected behavior, such as the rollback of "majority" committed write operations.

Looks like the replica script has to only make one change per update now.

I submitted a PR with fixes for this.

Fixed with v0.5.0
Thank you!


Pulumi tries to replace RDS instance even when no changes are made

What happened?
pulumi up tried to replace our production RDS instance (Aurora MySQL) even though nothing changed on the surface. but Thankfully it failed because protect flag was set to true, but this could be a catastrophic failure.
Expected Behavior
No updates
Steps to reproduce
I'm not sure how to reproduce this apart from trying to run pulumi up on a pre-existing aurora cluster. If such a cluster exists, just running pulumi up should lead to a repro. Our conclusion is that this is happening because Amazon is associating aurora as the storageType for these clusters and this leads pulumi to believe that it needs to recreate the instance. It's possible that AWS only started doing this recently (in the last 2-3 days).
Output of pulumi about
CLI
Version      3.59.0
Go Version   go1.20.2
Go Compiler  gc

Plugins
NAME        VERSION
aws         5.13.0
command     0.0.3
confluent   0.2.2
docker      3.1.0
eks         0.40.0
kafka       3.1.2
kubernetes  3.21.2
mysql       3.1.0
nodejs      unknown
postgresql  3.4.0

Host
OS       darwin
Version  13.2.1
Arch     arm64

This project is written in nodejs: executable='/nix/store/q8wfjfd61il46wz1bzfrq20zy6shmzvl-nodejs-18.13.0/bin/node' version='v18.13.0'

Backend
Name           pulumi.com
URL            xxxxxxxx
User           xxxxxxxxxx
Organizations  xxxxxxx

Dependencies:
NAME                VERSION
typescript          4.6.2
@pulumi/command     0.0.3
@pulumi/docker      3.1.0
@pulumi/mysql       3.1.0
ts-node             10.9.1
@pulumi/confluent   0.2.2
@pulumi/postgresql  3.4.0
@pulumi/pulumi      3.28.0
uuid                8.3.2
@databases/mysql    5.2.1
@types/node         17.0.21
node-jq             2.3.3
process             0.11.10
@types/uuid         8.3.4
netmask             2.0.2
ts-md5              1.2.11
@pulumi/aws         5.13.0
@pulumi/eks         0.40.0
@pulumi/kafka       3.1.2
@pulumi/kubernetes  3.21.2

Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Hi @bothra90 - Thank you for opening this issue.  I understand unexpected changes like this can be frustrating, and we'll be looking into this issue as soon as we can. Thank you.

@kpitzen: FWIW, we see this on our cluster in ap-south-1 (when running aws rds describe), but not us-west-2. It's possible AWS is rolling out a maintenance update that's applied in some regions but not all.

@bothra90 Update: I've confirmed that the above program reproduces this issue in ap-south-1:

We'll be looking at this ASAP - appreciate your patience!

That's awesome. Thanks, @kpitzen!

I've also confirmed that running pulumi up followed by pulumi refresh does not update Pulumi state - the subsequent pulumi up will still reproduce this issue.

From my testing, it appears that this issue seems to only seems to affect the ap-south-1 region currently. I've tried to look into upstream AWS documentation and the upstream provider documentation/issues to see if this is noted, but it looks like this is a new inconsistent behaviour introduced by the AWS RDS API.
What's interesting is that storageType is not supported to be specified and should be unset when creating an Aurora instance. The following error occurs when you attempt to create an aurora-mysql cluster with a non-empty storageType field:
* creating RDS Cluster (aurora-cluster-rquitales): InvalidParameterCombination: StorageType isn't supported for DB engine aurora-mysql.
status code: 400,

Workaround Solution:
As this issue is isolated to the ap-south-1 region, and more specifically, it appears to be an inconsistent issue with the upstream API, a potential workaround for now would be to add the storageType field to the ignoreChanges field in your Pulumi code as documented here: https://www.pulumi.com/docs/intro/concepts/resources/options/ignorechanges/
An example minimal Typescript code:
const rds = new aws.rds.Cluster("default-cluster", {
    backupRetentionPeriod: 5,
    clusterIdentifier: "aurora-cluster-default",
    databaseName: "mydb",
    engine: "aurora-mysql",
    engineVersion: "5.7",
    masterPassword: "bar",
    masterUsername: "foo",
    preferredBackupWindow: "07:00-09:00",
    skipFinalSnapshot: true,
}, { ignoreChanges: ["storageType"] });

This should help unblock usage of Pulumi with aurora RDS instances in the ap-south-1 region while we investigate the next steps to improve the user experience here.

Note: Downgrading from p1 since this issue only affects a single region, we have a workaround provided, and it appears to be an upstream API issue currently.

I am seeing this in eu-west-1 too, with a MariaDB instance in RDS as well.

Seeing this exact behaviour in eu-central-1 as well with Postgres Aurora Serverless V2. Well, I'm using ion.sst.dev but I don't think this issue is on their side. I also checked the state json before/after and there are no changes in the cluster whatsoever, so ignoreChanges does nothing and it still tries to recreate the cluster.


Lack of evaluation code and confusion on evaluation dataset

Thanks for the interesting work and for releasing the code. Could you please provide more details on the evalution steps in your experiments ? Additionaly, I noticed that you evaluated the method on the GSO dataset and RTMV dataset, but it seems that the GSO dataset is a subset of  RTMV dataset. Could you please clarify the evaluation procees and provide more information on how you evaluated on these two dataset ?

Hi @xyyeah , thank you for your interest in our work. I wouldn't say GSO is a subset of RTMV. A subset of RTMV, named Google Scanned Object, is composed of 300 scenes, each with 20 GSO objects. Therefore, each scene's geometry and texture is much more complicated than any single object in GSO. The experiments section of the paper as well as the appendix section have covered a lot of details regarding the evaluation process. Feel free to let me know if there's still anything unclear.

Thank you for your quick reply, I figured out the difference between GSO dataset and subset in RTMV. But I found that there are 2.5T data in the RTMV dataset, did you evaluate all the datasets or only a subset? If it is a subset, which subset did you evaluate?

We used 20 scenes randomly sampled from the Google Scanned Obejct subset, each scene with 17 novel views (1 for input and 16 for evaluation). Zero123 is very fast at inference time so we can easily evaluate hundreds of scenes. The difficulty in including more scenes for evaluation is that it's very expensive to train DietNeRF (one of our baseline). It takes around 24 hours to train one scene for DietNeRF on 1 GPU.

@ruoshiliu Thanks for your explanation.
If I want to reproduce the same results of yours in Table 1 and Table 2 as you did, Can you give some information on which 20 scenes and 17 novel views are used and 1 for the input? If datasets are not large, sharing both GSO and RTMV information will be really helpful.

@ruoshiliu Thanks for your quick reply.
I would like to reproduce the same evaluation results showed in the paper. I have downloaded the GSO dataset but cannot find any paired image/camera poses. Could you share more information about the preprocess method used to obtain the test datasets for the results in Table 1 and Table 2? Or as @taeyeopl suggested, could you share the preprocessed GSO and RTMV datasets ?

@ruoshiliu Looking for code for GSO and RTMV as well~ It would be great if these preprocessing codes are released!!

Here's the script to render 25 views for GSO: gso_render.zip. I believe the RTMV dataset already contains 150 rendered views for each scene.

Thanks so much for your help!!!

@ruoshiliu Thanks for your rendering scripts.
It looks like the model names are in the test.json in your script, if you could share the test.json I would appreciate it.


Raspotify multiroom

Hi
I don't know if it's possible with snapcast but I want to achieve this kind of setup :

multiroom audio
each player can play Spotify separately
multi groups of player.

I can set the multi room with Android app. I have two times my player under Spotify. One for raspotify and the second for snapcast. Is it normal ?
Is it possible to have multi group ? For example : my wife listen on kitchen and living room and me I listen on garage + bedroom.
Thank for your help.

This is a question for Snapcast, ask it there.
IIRC, Snapcast starts an instance of librespot which can coexist with another instance of librespot, and an Android device is required to manage snapclients.


Application crashes when run from command line

Assertion failed: f, file file.cpp, line 19
Running from Visual Studio works just fine.

the executable output folder is not in the default working directory. It doesn't find the shaders. If you want to package a build, copy the exe to the root and the shaders directory in the same folder.

I will add a .bat file to package exe and shaders together (create build folder).

Thanks, that makes sense.

Added a bat file.


Application default credentials not set

I tried using this step right before using Pulumi to orchestrate some infrastructure on GCP. However, Pulumi's whining about ADC:
 +  pulumi:pulumi:Stack infrastructure-develop create
    gcp:storage:Bucket my-bucket-eO4o4P1qpwmyq4U7Mk5Jq27FTj3t08IZ  error: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.
 +  pulumi:pulumi:Stack infrastructure-develop create
    gcp:storage:Bucket my-bucket-eO4o4P1qpwmyq4U7Mk5Jq27FTj3t08IZ  1 error

Diagnostics:
  gcp:storage:Bucket (my-bucket-eO4o4P1qpwmyq4U7Mk5Jq27FTj3t08IZ):
    error: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.

I assumed that using this action as a setup step before using Pulumi would work, but apparently that's not the case. Any ideas?

Hi @theomessin apologies for any confusion. When the gcloud CLI is installed it does not automatically setup ADC, as this would be problematic from a security perspective. You can however incorporate this into your workflow using these commands:
gcloud iam service-accounts keys create [FILE_NAME].json --iam-account<EMAIL_ADDRESS>export GOOGLE_APPLICATION_CREDENTIALS="[FILE_NAME].json"

@craigdbarber  I tried this, but get from my application, file not found

opened up a PR: https://github.com/GoogleCloudPlatform/github-actions/pull/30

Hi @theomessin apologies for any confusion. When the gcloud CLI is installed it does not automatically setup ADC, as this would be problematic from a security perspective. You can however incorporate this into your workflow using these commands:
gcloud iam service-accounts keys create [FILE_NAME].json --iam-account<EMAIL_ADDRESS>export GOOGLE_APPLICATION_CREDENTIALS="[FILE_NAME].json"

This command will create a new key every time action is runned, it can be a bit messy
I use the following in my workflow
env:
    GOOGLE_APPLICATION_CREDENTIALS: key.json
steps:
- uses: actions/checkout@v2
- uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
  with:
      version: '270.0.0'
      service_account_key: ${{ secrets.GCP_SA_KEY }}
- run: echo -n ${{ secrets.GCP_SA_KEY }} | base64 --decode > $GOOGLE_APPLICATION_CREDENTIALS


Accesses aren't refreshed after creating root tenant

After installation, it's required to create the root tenant. Accesses are configured to restrict access to only tenant collection if there's no tenants yet. But after the root tenant is created, admin panel still doesn't show other collections since the accesses has not been refreshed after submitting the form.

Current discussion: https://github.com/payloadcms/payload/discussions/2191


quick-start doc problem

Gorse version
latest version
Describe the bug
wget https://raw.githubusercontent.com/zhenghaoz/gorse/master/docker/docker-compose.yml
wget https://raw.githubusercontent.com/zhenghaoz/gorse/master/docker/config.toml
Url is 404

Sorry for the outdated documents. You may try these two files:

https://github.com/gorse-io/gorse/blob/master/docker-compose.yml
https://github.com/gorse-io/gorse/blob/master/config/config.toml.template

thanks, it works.


Update zh_cn.json

could you remove last \n in speedrunigt.option.timer_start_type.description?

ok


ArchLinux下运行失败！failed to load config from /opt/blurlyric/resources/app.asar/vite.config.js

如题。
我将软件包做了移植，ArchLinux AUR地址：blurlyric-bin
报错信息如下：
$ /opt/blurlyric/blurlyric
failed to load config from /opt/blurlyric/resources/app.asar/vite.config.js
(node:272058) UnhandledPromiseRejectionWarning: Error: spawn ENOTDIR
    at ChildProcess.spawn (node:internal/child_process:413:11)
    at Object.spawn (node:child_process:783:9)
    at ensureServiceIsRunning (/opt/blurlyric/resources/app.asar/node_modules/esbuild/lib/main.js:2041:29)
    at Object.build (/opt/blurlyric/resources/app.asar/node_modules/esbuild/lib/main.js:1931:26)
    at bundleConfigFile (/opt/blurlyric/resources/app.asar/node_modules/vite/dist/node/chunks/dep-80fe9c6b.js:61921:34)
    at loadConfigFromFile (/opt/blurlyric/resources/app.asar/node_modules/vite/dist/node/chunks/dep-80fe9c6b.js:61898:35)
    at resolveConfig (/opt/blurlyric/resources/app.asar/node_modules/vite/dist/node/chunks/dep-80fe9c6b.js:61425:34)
    at createServer (/opt/blurlyric/resources/app.asar/node_modules/vite/dist/node/chunks/dep-80fe9c6b.js:60080:26)
    at loadVite (/opt/blurlyric/resources/app.asar/main.js:35:24)
    at /opt/blurlyric/resources/app.asar/main.js:82:5
(Use `blurlyric --trace-warnings ...` to show where the warning was created)
(node:272058) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:272058) electron: Failed to load URL: http://localhost:18775/ with error: ERR_CONNECTION_REFUSED
Error: ENOENT: no such file or directory, open './util/config.json'
    at Object.openSync (node:fs:600:3)
    at Object.func [as openSync] (node:electron/js2c/asar_bundle:2:1822)
    at Object.writeFileSync (node:fs:2221:35)
    at generateConfig (/opt/blurlyric/resources/app.asar/generateConfig.js:14:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Object.start (/opt/blurlyric/resources/app.asar/app.js:5:3) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: './util/config.json'
}
server running @ http://localhost:18775

通过浏览器打开http://localhost:18775正常，但是Electron界面空白。
AUR的PKGBUILD文件内容如下：
# Maintainer: zxp19821005 <zxp19821005 at 163 dot com>
pkgname=blurlyric-bin
pkgver=2.4
pkgrel=1
pkgdesc="A simple, beautiful, and user-friendly third-party player for NetEase Cloud Music.高颜值,高性能的网易云音乐第三方音乐播放器"
arch=('x86_64')
url="https://blurlyric.app/"
_githuburl="https://github.com/Project-And-Factory/BlurLyric"
license=('GPL3')
conflicts=("${pkgname%-bin}")
depends=('nspr' 'nss' 'libdrm' 'mesa' 'glibc' 'libxkbcommon' 'dbus' 'expat' 'libxfixes' 'libxcb' 'libxext' 'gcc-libs' 'pango' \
    'libxcomposite' 'at-spi2-core' 'glib2' 'libcups' 'alsa-lib' 'libxrandr' 'gtk3' 'libx11' 'libxdamage' 'cairo')
source=("${pkgname%-bin}-${pkgver}.zip::${_githuburl}/releases/download/v${pkgver}/${pkgname%-bin}_ubuntu-0fc3fe9713556040b35c54874c047cfcd2e6824d.deb.zip")
sha256sums=('dd0cc53636376a20db154efd169204010eaa6189df4d131271e07fb1da36ad69')
package() {
    bsdtar -xf "${srcdir}/${pkgname%-bin}_${pkgver}.0_amd64.deb"
    bsdtar -xf "${srcdir}/data.tar.zst" -C "${pkgdir}"
    install -Dm755 -d "${pkgdir}/opt"
    mv "${pkgdir}/usr/lib/${pkgname%-bin}" "${pkgdir}/opt"
    rm -rf "${pkgdir}/usr/bin" "${pkgdir}/usr/lib"
    sed 's|Exec=blurlyric|Exec=/opt/blurlyric/blurlyric|g' -i "${pkgdir}/usr/share/applications/${pkgname%-bin}.desktop"
    chmod 0755 "${pkgdir}/opt/${pkgname%-bin}/chrome-sandbox"
}

稍后我自己编译一下试试看。

编译完成后直接运行，终端信息如下：
$ ./blurlyric
▲ [WARNING] Duplicate key "@vitejs/plugin-vue" in object literal [duplicate-object-key]

    ../../package.json:51:4:
      51 │     "@vitejs/plugin-vue": "^2.3.3",
         ╵     ~~~~~~~~~~~~~~~~~~~~

  The original key "@vitejs/plugin-vue" is here:

    ../../package.json:46:4:
      46 │     "@vitejs/plugin-vue": "^2.3.3",
         ╵     ~~~~~~~~~~~~~~~~~~~~

  > Local:    http://localhost:18776/
  > Network:  http://<IP_ADDRESS>:18776/
  > Network:  http://<IP_ADDRESS>:18776/
Error: ENOENT: no such file or directory, open './util/config.json'
    at Object.openSync (node:fs:600:3)
    at Object.func [as openSync] (node:electron/js2c/asar_bundle:2:1822)
    at Object.writeFileSync (node:fs:2221:35)
    at generateConfig (/home/zxp-endeavouros/.cache/paru/clone/blurlyric/src/BlurLyric-2.4/out/blurlyric-linux-x64/resources/app/generateConfig.js:14:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Object.start (/home/zxp-endeavouros/.cache/paru/clone/blurlyric/src/BlurLyric-2.4/out/blurlyric-linux-x64/resources/app/app.js:5:3) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: './util/config.json'
}
server running @ http://localhost:18775
[281670:0802/152559.702601:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.DBus.StartServiceByName: object_path= /org/freedesktop/DBus: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[281670:0802/152559.721575:ERROR:CONSOLE(1)] "Uncaught (in promise) TypeError: Failed to fetch", source: devtools://devtools/bundled/panels/elements/elements.js (1)
[OK] /login/status?timetamp=1690961159628
4d5addf3b326ac
{
  id: '4d5addf3b326ac',
  res: '{"id":"4d5addf3b326ac","config":{"configVersion":"1.7","lyricSet":{"dur":600,"text":"最高","funcBlur":true,"funcDelay":true,"animeFontSize":false,"maxfps":true},"useAnimeBackground":false,"useTransitionNextMusic":false},"playList":{"num":0,"tracks":[]}}'
}
undefined { code: 'ok' }
[OK] /personal_fm?timetamp=1690961159628
[OK] /user/playlist?uid=8586889603&timetamp=1690961159932
[OK] /recommend/songs
[OK] /daily_signin?type=1
[OK] /daily_signin?type=0

程序能够正常启动，但是会了另外弹出一个浏览器窗口，浏览器窗口内报错信息如下：
[vite] connecting...
client.ts:53 [vite] connected.
request.js:40 false true
runtime-core.esm-bundler.js:40 [Vue warn]: Invalid prop: type check failed for prop "imgSrc". Expected Object, got String with value "/src/assets/icon.png".
  at <Background dynamic=true imgSrc="/src/assets/icon.png" mainDisplay="buttom" >
  at <App>
warn2 @ runtime-core.esm-bundler.js:40
runtime-core.esm-bundler.js:40 [Vue warn]: Invalid prop: type check failed for prop "mainDisplay". Expected Object, got String with value "buttom".
  at <Background dynamic=true imgSrc="/src/assets/icon.png" mainDisplay="buttom" >
  at <App>
warn2 @ runtime-core.esm-bundler.js:40
vue-router.mjs:35 [Vue Router warn]: <router-view> can no longer be used directly inside <transition> or <keep-alive>.
 This is likely a Vue internals bug. Please open an issue at https://new-issue.vuejs.org/?repo=vuejs/core
  at <MuLib data= {user: {…}, player: {…}, ui: {…}, recommendSongs: {…}, myMusicList: Array(1), …} onVnodeUnmounted=fn<onVnodeUnmounted> ref=Ref< Proxy(Object) {loginOut: ƒ, removePl: ƒ, …} > >
  at <RouterView key=0 data= {user: {…}, player: {…}, ui: {…}, recommendSongs: {…}, myMusicList: Array(1), …} >
  at <KeepAlive>
  at <App>
warn2 @ runtime-core.esm-bundler.js:40
logError @ runtime-core.esm-bundler.js:214
handleError @ runtime-core.esm-bundler.js:206
callWithErrorHandling @ runtime-core.esm-bundler.js:160
flushJobs @ runtime-core.esm-bundler.js:390
Promise.then (async)
queueFlush @ runtime-core.esm-bundler.js:282
queueJob @ runtime-core.esm-bundler.js:276
(anonymous) @ runtime-core.esm-bundler.js:5743
triggerEffect @ reactivity.esm-bundler.js:397
triggerEffects @ reactivity.esm-bundler.js:387
trigger @ reactivity.esm-bundler.js:355
set2 @ reactivity.esm-bundler.js:526
(anonymous) @ App.vue:1185
Promise.then (async)
myPlayList @ App.vue:1184
(anonymous) @ App.vue:1144
muLibList.vue:116 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'nickname')
    at muLibList.vue:116:33
    at renderList (runtime-core.esm-bundler.js:2912:22)
    at Proxy._sfc_render (muLibList.vue:118:13)
    at renderComponentRoot (runtime-core.esm-bundler.js:898:44)
    at ReactiveEffect.componentUpdateFn [as fn] (runtime-core.esm-bundler.js:5702:34)
    at ReactiveEffect.run (reactivity.esm-bundler.js:187:25)
    at instance.update (runtime-core.esm-bundler.js:5745:56)
    at callWithErrorHandling (runtime-core.esm-bundler.js:157:36)
    at flushJobs (runtime-core.esm-bundler.js:390:17)
(


Reduce LEDGER_MIN_CONSENSUS

Make LEDGER_MIN_CONSENSUS slightly smaller and not a multiple of
LEDGER_GRANULARITY to avoid fluctuations in the heartbeat timer needlessly
delaying consensus.
Changes made in collaboration with @wilsonianb and @scottschurr.

How did you calculate that the LEDGER_MIN_CONSENSUS should be reduced by 50ms?  Or was that an arbitrary test choice?

It is somewhat arbitrary.  We wanted to make it smaller to avoid small (<10ms) fluctuations in the heartbeat timer undershooting LEDGER_MIN_CONSENSUS, which ends up requiring an extra LEDGER_GRANULARITY=1s delay to declare consensus.   This was a reasonable value to protect against that but still leave enough time to receive peer proposals before checking for consensus.  We also validated the improvement on the altnet.
As the consensus refactor and simulation framework matures, we will be able to do more controlled experiments and explore the trade-off more carefully.

Codecov Report

Merging #2013 into develop will decrease coverage by -0.03%.

@@             Coverage Diff             @@
##           develop    #2013      +/-   ##
===========================================
- Coverage    67.27%   67.25%   -0.03%
===========================================
  Files          683      683
  Lines        49231    49231
===========================================
- Hits         33121    33109      -12
- Misses       16110    16122      +12

Impacted Files
Coverage Δ

src/ripple/app/misc/impl/LoadFeeTrack.cpp
81.53% <ø> (-4.62%)
:x:

src/ripple/beast/core/WaitableEvent.cpp
87.75% <ø> (-4.09%)
:x:

src/ripple/server/impl/BaseWSPeer.h
77.5% <ø> (-3.34%)
:x:

src/ripple/core/impl/Stoppable.cpp
92.55% <ø> (-3.2%)
:x:

src/ripple/app/main/LoadManager.cpp
73.68% <ø> (-1.32%)
:x:

src/ripple/core/impl/JobQueue.cpp
86.17% <ø> (-0.47%)
:x:

src/ripple/basics/impl/make_SSLContext.cpp
53.5% <ø> (+1.27%)
:white_check_mark:

Continue to review full report at Codecov.

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

Seems fair enough.

:+1:

Rebased on 0.60.0-b5

In 0.60.0-b7