How to pass selected id which is not shown to the user but used for other purposes(to save to db) behind the scenes

Hi,
This is very very useful plugin in all XAMARIN FORMS plugins so far.
I have question and stuck with this for a while.

here item source return type has hardcoded List of string but I want to select id for the selected item
I see that there is selected item property.
But how do I set my list to contain id and value pair in first place but not show Id on the screen.
I tried following way to set but not succesful with the approach.
public class SelectList<T>
 {
     public T Value { get; set; }

     public string Text { get; set; }

     public string[] ValueText => (Value + "|" + Text).Split('|');

     public string GetSelectValue => ValueText[0];
     public string GetSelectedText => ValueText[1];
 }

 public List<SelectList<Guid>> GetData()
 {
 //return data here
 }

 public MainPageViewModel()
 {
   var data=GetData();
    var names =data.Select(n => n.GetSelectedText);

     //NamesSuggestions.ReplaceRange(data) ;
        NamesSuggestions.ReplaceRange(names) ;

    //In above line,I want to replace entire list with type SelectList<Guid> rather than just list of strings
   //and show only names on the page.
   //When selected from the list I want to pass the object but  how do I set the entire object.
 }

 public ObsColl<string> NamesSuggestions { get; } = new ObsColl<string>();
//public ObsColl<SelectList<Guid>> ObsColl{ get; } = new ObsColl<SelectList<Guid>>();

where ObsColl is short form of ObservableRangeCollection(using James MVVM helpers plugin)

I need to look in selectedItem property(not sure at this stage)
My goal is to make this generic so that I can get and set dynamic objects(for reusability on different types)
Ex:I can have list to show top 10 people and I don't know whether depending on index is suitable for my needs in future or not.
Work around is also Ok but looking for better way.
Any help is appreciated.

We use ObservableCollection and subscribe to the ItemSelected event.
The ItemSelected event contains a SelectedItemChangedEventArgs parameter and you can access the result with
e.SelectedItem.ToString();

I will try when I am free this and in the mean time can u provide sample or just add things to my code mentioned above(helps to understand and do it quickly)

@avinashramireddy-rapidd I've just made a commit to demonstrate how it's done.
You can either use the event ItemSelected and capture it in your codebehind, or you can bind a property to the SelectedItem property, and view it from your ViewModel.
https://github.com/XamFormsExtended/Xfx.Controls/commit/332ca2a8ac9744c3fb64def78267786026118018


cmd/link: Go tip fails to build with lld linker

While building go tip (at commit 3403ee524bef9f6d2d69e11410fbf16854447d21), I got the following error:
~/src/go/src$ ./make.bash
Building Go cmd/dist using /usr/local/go.
Building Go toolchain1 using /usr/local/go.

Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for linux/amd64.
# cmd/trace
runtime/cgo(.text): relocation target pthread_mutex_lock not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target pthread_mutex_unlock not defined for ABI0 (but is defined for ABI0)
# cmd/go
runtime/cgo(.text): relocation target pthread_mutex_lock not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target pthread_mutex_unlock not defined for ABI0 (but is defined for ABI0)
# cmd/pprof
runtime/cgo(.text): relocation target pthread_mutex_lock not defined for ABI0 (but is defined for ABI0)
runtime/cgo(.text): relocation target pthread_mutex_unlock not defined for ABI0 (but is defined for ABI0)
go tool dist: FAILED: /home/ayke/src/go/pkg/tool/linux_amd64/go_bootstrap install -gcflags=all= -ldflags=all= std cmd: exit status 2

This is because I use the lld linker from LLVM:
/usr/bin$ ll ld
lrwxrwxrwx 1 root root 8 mrt 22 19:26 ld -> ld.lld-8*

When I change the symlink to point to ld.gold or ld.bfd, compiling Go works as expected. I don't know what the error exactly means (pthread_mutex_* is both defined and not defined for ABI0?) but would expect Go to compile just fine with lld as the system linker.
My system is Debian stretch with LLVM 8 installed from here: http://apt.llvm.org/
What version of Go are you using (go version)?

$ go version
go version go1.12 linux/amd64

What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ayke/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/ayke"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build176331235=/tmp/go-build -gno-record-gcc-switches"

It works fine with ld.lld-6.
The command executed during make.bash:
[pid 22896] execve("/usr/bin/ld", ["/usr/bin/ld", "-plugin", "/usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so", "-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper", "-plugin-opt=-fresolution=/tmp/ccpfuiXA.res", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "-plugin-opt=-pass-through=-lpthread", "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_s", "--sysroot=/", "--build-id", "--eh-frame-hdr", "-m", "elf_x86_64", "--hash-style=gnu", "--as-needed", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-z", "relro", "-o", "/tmp/go-build852796803/b085/_cgo_.o", "/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o", "/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o", "/usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o", "-L/usr/lib/gcc/x86_64-linux-gnu/5", "-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu", "-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib", "-L/lib/x86_64-linux-gnu", "-L/lib/../lib", "-L/usr/lib/x86_64-linux-gnu", "-L/usr/lib/../lib", "-L/usr/lib/gcc/x86_64-linux-gnu/5/../../..", "/tmp/go-build852796803/b085/_cgo_main.o", "/tmp/go-build852796803/b085/_x001.o", "/tmp/go-build852796803/b085/_x002.o", "/tmp/go-build852796803/b085/_x003.o", "/tmp/go-build852796803/b085/_x004.o", "/tmp/go-build852796803/b085/_x005.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-lpthread", "-lc", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "/usr/lib/gcc/x86_64-linux-gnu/5/crtend.o", "/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o"], [/* 109 vars */]) = 0

I can reproduce this on my linux/amd64 Debian testing-ish machine by changing /usr/bin/ld to point to ld.lld-8. (Curiously, GO_LDFLAGS='-extld ld.lld-8' ./make.bash was not enough to reproduce it.)
I think the problem occurs when the cgo tool invokes the linker when building the cgo object for runtime/cgo. In the final link step that fails, like Ian mentioned, we haven't invoked the external linker at all yet. The only time we invoke the external linker is from the cgo tool, and in the build of cmd/go that only happens when building the runtime/cgo and net packages.
To demonstrate:
./make.bash
go install cmd/buildid cmd/pack
strace -f -e execve -s 256 go build -a -x -o /dev/null cmd/go >& /tmp/st

Search /tmp/st for /usr/bin/ld. The surrounding context shows it being invoked by cgo.

@cherrymui pointed out that _cgo_import.go is missing //go:cgo_import_dynamic pragmas for the two pthread_mutex_* symbols, even though it appears to have them for every other pthread symbol we use. If we put the bfd linker back, we get those //go:cgo_import_dynamic pragmas.
go build -a -x -work runtime/cgo
cat $WORK/b001/_cgo_import.go

This appears to be because the _cgo_.o file (which is actually a linked binary, not an object file) contains weak references to pthread_mutex_* when linked with lld:
$ readelf --dyn-syms $WORK/b001/_cgo_.o | grep pthread_
    11:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND<EMAIL_ADDRESS>(3)
    12:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(4)
    13:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND<EMAIL_ADDRESS>(3)
    14:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(4)
    16:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(3)
    17:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(3)
    22:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(3)
    23:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(3)
    24:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(3)
    27:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(3)

The cgo tool uses debug/elf.File.ImportedSymbols to iterate over the imported symbols in _cgo_.o and emit //go:cgo_import_dynamic pragmas, but this function specifically skips weak symbols.
Ping @ianlancetaylor @cherrymui for thoughts.

The functions pthread_mutex_lock and pthread_mutex_unlock are STB_WEAK in /lib/x86_64_linux_gnu/libpthread.so.0, although they are STB_GLOBAL in /lib/x86_64-linux-gnu/libc.so.6.  That must somehow be causing lld to emit them as STB_WEAK symbols, although GNU ld and gold act differently.
Unfortunately, elf.File.ImportedSymbols explicitly skips STB_WEAK symbols.
It seems to me that lld is acting incorrectly here.  Since we link against libc.so.6, and the symbols are STB_GLOBAL there, lld should emit them as STB_GLOBAL, not STB_WEAK.  I don't know if this has changed in lld-9.  CC @rui314.
In the meantime I think we need to change cgo to call DynamicSymbols, and we need to add a new exported API to debug/elf to do a version of File.gnuVersion that returns the library and version for a dynamic symbol index.

I just built LLD tip from source and it still generates weak symbols for pthread_mutext_lock/unlock.

I have a fix for the bootstrap, though it appears this isn't the only problem with lld 8:
--- FAIL: TestScript (0.00s)
    --- FAIL: TestScript/vendor_complex (1.24s)
        script_test.go:191:
            # smoke test for complex build configuration (1.240s)
            > go build -o complex.exe complex
            > [exec:gccgo] go build -compiler=gccgo -o complex.exe complex
            [stderr]
            # complex
            ld: error: undefined symbol: pthread_sigmask
            >>> referenced by generic-morestack.o:(__morestack_block_signals) in archive /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a

            ld: error: undefined symbol: pthread_sigmask
            >>> referenced by generic-morestack.o:(__morestack_unblock_signals) in archive /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a

            ld: error: undefined symbol: pthread_sigmask
            >>> referenced by generic-morestack.o:(__morestack_block_signals) in archive /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a

            ld: error: undefined symbol: pthread_sigmask
            >>> referenced by generic-morestack.o:(__morestack_unblock_signals) in archive /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a
            collect2: error: ld returned 1 exit status
            [exit status 2]
            FAIL: testdata/script/vendor_complex.txt:5: unexpected command failure

FAIL
FAIL	cmd/go	43.183s

(This happens with or without my fix, as long as I apply my fix to get past bootstrap.)

@ianlancetaylor, are there going to be other consequences of importing weak symbols in the cgo tool? I don't really understand the semantics here. Is the cgo tool just wrong to omit these right now?

The error you show above suggests that somehow the version of gccgo you are using is not passing -lpthread to the linker.  I don't think that has anything to do with any change you made to cgo.

It definitely doesn't have anything to do with my change to cgo because it happens if I revert my change.

What version of gccgo do you have installed?  What is go env GCCGO?

$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-18' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-18)

$ go env GCCGO
/usr/bin/gccgo

Ian, I believe that your "what the linker should do" analysis in the previous comment is a bit erroneous by being overcomplicated.  The STB_GLOBAL symbols in libc.so.6 are a red herring.
If I have an object file with a STB_GLOBAL reference to "foo", and link it against a shared library that exposes a definition of foo, I should get a STB_GLOBAL reference in the resulting file -- regardless of whether the definition of foo is weak or strong.  The weakness of the reference and the weakness of the definition are distinct things, and there's no reason they need to match.
Testing this with various linkers:
$ cat libweakfoo.c
int attribute((weak)) foo() {
return 23;  // fnord
}
$ gcc libweakfoo.c -shared -o libweakfoo.so
$ readelf --dyn-syms libweakfoo.so | grep ' foo'
6:<PHONE_NUMBER>00057a    11 FUNC    WEAK   DEFAULT   11 foo
$ cat callfoo.c
int foo();
int main() {
return foo();
}
$ gcc callfoo.c -c -o callfoo.o
$ readelf -s callfoo.o | grep ' foo'
10:<PHONE_NUMBER>000000     0 NOTYPE  GLOBAL DEFAULT  UND foo
$ gcc callfoo.o -L. -lweakfoo -o callfoo -fuse-ld=bfd
$ readelf --dyn-syms callfoo | grep ' foo'
4:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND foo
$ gcc callfoo.o -L. -lweakfoo -o callfoo -fuse-ld=gold
$ readelf --dyn-syms callfoo | grep ' foo'
2:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND foo
(Apologies for the compiler switch here; I don't have my gcc set up to use lld.)
$ clang callfoo.o -L. -lweakfoo -o callfoo -fuse-ld=lld
$ readelf --dyn-syms callfoo | grep ' foo'
6:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND foo
Looks like in this simple case, LLD (via Clang) is doing the right thing.   So it must be something other than simply the presence of weak definitions in libpthread.o that's causing LLD to emit the weak references in cgo.o.  (Or else this was fixed sometime between cherrymui@'s tip-of-trunk LLD from 16 days ago, and mine from a few days more recently.)
FWIW, I also repeated this analysis adding an attribute((weak)) to the reference in callfoo.c, and determined that the "UND" symbol in the linked binary is weak regardless of whether I link with a library that has a strong definition or a weak definition, and regardless of which linker I use.

(Note that the autoformatter changed my double-underscores around "attribute" to boldface formatting.)

I just build tip LLD and it is the same.
$ ld.lld --version
LLD 9.0.0 (http://llvm.org/git/lld.git 5a41ae1ba61fd6c3e5bb15e8d04c8deb9f63079d) (compatible with GNU linkers)

$ CGO_LDFLAGS=-fuse-ld=lld go build -work -x -a runtime/cgo
...
TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -o $WORK/b001/_cgo_.o $WORK/b001/_cgo_main.o $WORK/b001/_x001.o $WORK/b001/_x002.o $WORK/b001/_x003.o $WORK/b001/_x004.o $WORK/b001/_x005.o $WORK/b001/_x006.o $WORK/b001/_x007.o $WORK/b001/_x008.o $WORK/b001/_x009.o $WORK/b001/_x010.o $WORK/b001/_x011.o $WORK/b001/_x012.o -fuse-ld=lld -lpthread
...

The line above is how we invoke the linker.
The linker output contains weak references.
$ readelf --dyn-syms $WORK/b001/_cgo_.o | grep pthread_mutex
    11:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND<EMAIL_ADDRESS>(3)
    13:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND<EMAIL_ADDRESS>(3)

The input to the linker seems normal.
$ readelf -s /tmp/go-build382217838/b001/_x*.o | grep pthread_mutex
    22:<PHONE_NUMBER>000000     0 NOTYPE  GLOBAL DEFAULT  UND pthread_mutex_lock
    24:<PHONE_NUMBER>000000     0 NOTYPE  GLOBAL DEFAULT  UND pthread_mutex_unlock

Interestingly, if we don't pass -lpthread to gcc, it still works and actually generates strong symbols.
$ TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -o $WORK/b001/_cgo_.o $WORK/b001/_cgo_main.o $WORK/b001/_x001.o $WORK/b001/_x002.o $WORK/b001/_x003.o $WORK/b001/_x004.o $WORK/b001/_x005.o $WORK/b001/_x006.o $WORK/b001/_x007.o $WORK/b001/_x008.o $WORK/b001/_x009.o $WORK/b001/_x010.o $WORK/b001/_x011.o $WORK/b001/_x012.o -fuse-ld=lld
$ readelf --dyn-syms $WORK/b001/_cgo_.o | grep pthread_mutex
    11:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(3)
    13:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(3)

Note that gcc will still pass -lpthread to the linker even without -lpthread in the command line.
$ TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -o $WORK/b001/_cgo_.o $WORK/b001/_cgo_main.o $WORK/b001/_x001.o $WORK/b001/_x002.o $WORK/b001/_x003.o $WORK/b001/_x004.o $WORK/b001/_x005.o $WORK/b001/_x006.o $WORK/b001/_x007.o $WORK/b001/_x008.o $WORK/b001/_x009.o $WORK/b001/_x010.o $WORK/b001/_x011.o $WORK/b001/_x012.o -fuse-ld=lld -v
...
 /usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccvpBpuK.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -fuse-ld=lld -o /tmp/go-build549226297/b001/_cgo_.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. /tmp/go-build549226297/b001/_cgo_main.o /tmp/go-build549226297/b001/_x001.o /tmp/go-build549226297/b001/_x002.o /tmp/go-build549226297/b001/_x003.o /tmp/go-build549226297/b001/_x004.o /tmp/go-build549226297/b001/_x005.o /tmp/go-build549226297/b001/_x006.o /tmp/go-build549226297/b001/_x007.o /tmp/go-build549226297/b001/_x008.o /tmp/go-build549226297/b001/_x009.o /tmp/go-build549226297/b001/_x010.o /tmp/go-build549226297/b001/_x011.o /tmp/go-build549226297/b001/_x012.o -lpthread -lgcc --push-state --as-needed -lgcc_s --pop-state -lpthread -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
...

(there is -lpthread near the end)

@brooksmoses What you say makes perfect sense.
That said, here is how to recreate the problem.
> cat foo.c
#include <pthread.h>

static pthread_mutex_t mu = PTHREAD_MUTEX_INITIALIZER;

void f1(void) {
	pthread_mutex_lock(&mu);
}

void f2(void) {
	pthread_mutex_unlock(&mu);
}

int main() { return 0; }
> gcc -g -c -fPIC -pthread foo.c
> gcc -o x foo.o -lpthread # Using GNU ld
> readelf -s --wide x | grep 'pthread_mutex.*lock'
     4:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(3)
     7:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND<EMAIL_ADDRESS>(3)
    63:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND pthread_mutex_unlock@@GLIBC_2.2.5
    72:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND pthread_mutex_lock@@GLIBC_2.2.5
> gcc -o x foo.o -lpthread # Using lld
> readelf -s --wide x | grep 'pthread_mutex.*lock'
     6:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND<EMAIL_ADDRESS>(3)
     7:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND<EMAIL_ADDRESS>(3)
    35:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_lock
    37:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_unlock

I tested this using the lld I found at /google/src/files/255543051/depot/google3/third_party/crosstool/v18/stable/installs/llvm/bin/ld.lld.

@aclements I have no explanation for what you are seeing with gccgo.  It does work for me.  I guess it's unrelated to this issue, though, so should probably be dealt with elsewhere if at all.  It might help to see the go build -x output.

Thanks, @ianlancetaylor -- having a nice minimal reproducer like that is very helpful, and I'll dig into that tomorrow and see if I can boil this down to a clean easily-fixable LLD bug report.
The difference in symbol-versioning there is also weird (and perhaps significant).  I wonder if that's also related to getting the symbols from different places -- iirc, they're versioned in one library and not the other.

Quick confirmation: @ianlancetaylor, I can reproduce what you're seeing with my Clang-based setup -- including the fact that, without -lpthread, the LLD link gets strong symbols.

Some more reduction, using @ianlancetaylor's foo.c above.  (I'm omitting paths and -L options for clarity.)
ld.lld -o foo foo.o -lpthread -lgcc_s produces the weak references.
ld.lld -o foo foo.o -lpthread produces the strong references.

And, as one might start to expect from this data, libgcc_s.so.1 has these definitions:
readelf --dyn-sym libgcc_s.so.1 | grep pthread_mutex
   102:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND<EMAIL_ADDRESS>(13)
   165:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND<EMAIL_ADDRESS>(13)

A complete, simple reproducer:
$ cat foo.c
// A program with a strong reference to bar()
int bar();
int main() { return bar(); }

$ cat bar.c
// A strong definition of bar().
int bar() { return 23; }

$ cat baz.c
// An unused function with a weak reference to bar()
int __attribute__((weak)) bar();
int baz() { return bar ? bar() : 0; }

$ gcc foo.c -c -o foo.o
$ gcc bar.c -shared -o libbar.so
$ gcc baz.c -shared -o libbaz.so

First, to confirm foo.o has a strong reference:
$ readelf -s foo.o | grep bar
    10:<PHONE_NUMBER>000000     0 NOTYPE  GLOBAL DEFAULT  UND bar

If we link without libbaz.so, we retain a strong reference, as expected:
$ ld.lld foo.o libbar.so -o foo1
ld.lld: warning: cannot find entry symbol _start; defaulting to 0x201000
$ readelf --dyn-sym foo1 | grep bar
1:<PHONE_NUMBER>000000     0 FUNC    GLOBAL DEFAULT  UND bar

However, if we append `libbaz.so` to the end of the command line, it's a weak reference:

$ ld.lld foo.o libbar.so libbaz.so -o foo1
ld.lld: warning: cannot find entry symbol _start; defaulting to 0x201000
$ readelf --dyn-sym foo1 | grep bar
1:<PHONE_NUMBER>000000     0 FUNC    WEAK   DEFAULT  UND bar

That seems to pretty clearly be an LLD bug.  The program still has code that was written to require a strong reference to `bar`, and appending something with a weak reference shouldn't change that.

Interestingly, if we invert the order, making it `libbaz.so libbar.so`, we get a strong reference again.

I'll go file this in the LLVM bugtracker.

This is now filed as https://bugs.llvm.org/show_bug.cgi?id=42442.

Thanks @brooksmoses

Thanks to Ian and Brooks for analysis. I am really sad to see pthread weak undef in libgcc_s.so.1... Anyway, proposed fix of the bug: https://reviews.llvm.org/D63974
% clang -fuse-ld=lld -o x foo.o -pthread -Wl,-y,pthread_mutex_lock
foo.o: reference to pthread_mutex_lock
/usr/lib/gcc/x86_64-linux-gnu/8.0.1/libgcc_s.so.1: reference to pthread_mutex_lock
/usr/lib/gcc/x86_64-linux-gnu/8.0.1/../../../x86_64-linux-gnu/libpthread.so: shared definition of pthread_mutex_lock

% clang -fuse-ld=lld -o x foo.o -lpthread -Wl,-y,pthread_mutex_lock
foo.o: reference to pthread_mutex_lock
/usr/lib/gcc/x86_64-linux-gnu/8.0.1/../../../x86_64-linux-gnu/libpthread.so: shared definition of pthread_mutex_lock
/usr/lib/gcc/x86_64-linux-gnu/8.0.1/libgcc_s.so.1: reference to pthread_mutex_lock
### Without D63974, the weak undef in libgcc_s.so.1 sets the result binding to STB_WEAK.

Whoops, we have the info we need, but forgot to remove the label. Reopening.


[HELP] How to use with custom nginx proxy?

Hi,
First of all, thank you for such a great tool!
Recently I switched to network_mode: "host" for all my containers and I can't get lets encrypt companion to work now.
Here's typical docker-compose:
version: '2'
services:

  rproxy:
    build:
      context: ./reverse_proxy
      dockerfile: Dockerfile_stage_host
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - /usr/share/nginx/html
      - /etc/nginx/vhost.d
      - /certs/ssl:/etc/nginx/certs:ro
    ports:
      - "80:80"
      - "443:443"
    network_mode: "host"

  web_client_server:
    build:
      context: ./web_client_server
      dockerfile: Dockerfile_nginx_stage_host
    environment:
      LETSENCRYPT_HOST: "mydomain.com"
      LETSENCRYPT_EMAIL<EMAIL_ADDRESS>    restart: always
    expose:
      - "8080"
    network_mode: "host"

  ssl:
    image: jrcs/letsencrypt-nginx-proxy-companion:stable
    restart: always
    volumes:
      - /certs/ssl:/etc/nginx/certs:rw
      - /var/run/docker.sock:/var/run/docker.sock:ro
    volumes_from:
     - rproxy

My rproxy is configured to something like:
server {

    listen 443 ssl;
    listen [::]:443 ssl;
    ssl_certificate /etc/nginx/certs/mydomain.com.crt;
    ssl_certificate_key /etc/nginx/certs/mydomain.com.key;

    ssl on;
    ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    server_name mydomain.com;

    location / {
        proxy_pass http://localhost:8080;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

}

When I start letsencrypt-nginx-proxy-companion container it says:
ssl_1                | Sleep for 3600s
ssl_1                | 2017/02/17 01:48:50 Generated '/app/letsencrypt_service_data' from 0 containers
ssl_1                | 2017/02/17 01:48:50 Running '/app/update_certs'
ssl_1                | 2017/02/17 01:48:50 Watching docker events

Obviously there are no certs generated... Why doesn't letsencrypt-nginx-proxy-companion see the web_client_server container???
Thanks.

Anyone?

Check the solution in #173. Seems like the latest version of nginx.tmpl doesn't work. An older version seems fine though


警告问题 warning problem

indexing with dtype torch.uint8 is now deprecated, please use a dtype torch.bool instead.
how to avoid this warning when training？

I use pytorch 1.1.0 in my code. If you use the latest version, you can either omit the warning or replace torch.uint8 with torch.bool.

yes, I use the latest version of pytorch, and I don't know the code position to produce this warning, it's mean where can I replace torch.uint8 with torch.bool.
(/pytorch/aten/src/ATen/native/IndexingUtils.h:20: UserWarning: indexing with dtype torch.uint8 is now deprecated, please use a dtype torch.bool instead.)


Runner don't render error body if throw exception after ob_start()

In runner:
 try {
    // ...
    // Here response stream: `ob_start(); throw Exception()`
    $this->emit($request, $response);
} catch (Throwable $throwable) {
    $handler = new ThrowableHandler($throwable);
    /**
     * @var ResponseInterface
     * @psalm-suppress MixedMethodCall
     */
    $response = $container
        ->get(ErrorCatcher::class)
        ->process($request, $handler);
    $this->emit($request, $response);
}

It is no longer actual. Failed to reproduce.


Feature Request: missing question.yml file

Is your feature request related to a problem?
The policy has settings and in order to be able to properly show it in the UI we need the question.yml file.
Solution you'd like
Add the question.yml used by the UI.
Alternatives you've considered
No response
Anything else?
Related to https://github.com/kubewarden/ui/issues/207

FYI @jordojordo

I've added the file


How can I get the FID, IS and Acc with PointNet++?

The paper reports the results of FID and IS on CLIP-Forge and Point-E. It confuses me how do you get the FID and IS of Point-E and CLIP-Forge. As far as I know CLIP-Forge gets the FID and IS based on a voxel classifier while Point-E gets the FID and IS based on a pointcloud classifier. Which pointnet++ classifier should I use?

We use a pre-trained pointnet++ to extract point cloud features and calculate FID and IS according to formulas. For CLIP-Forge, we directly used the results reported in its paper.


sink/mq,sink/mysql(ticdc): remove useless opts for MQ sink

What problem does this PR solve?

Issue Number: ref https://github.com/pingcap/tiflow/issues/5849
What is changed and how it works?
remove useless opts for MQ sink.
Check List
Tests

Unit test

Questions
Will it cause performance regression or break compatibility?
No
Do you need to update user documentation, design documentation or monitoring documentation?
No, I didn't find any docs about this arg.
Release note
None

Codecov Report

Merging #5879 (4f40743) into master (6a451ea) will increase coverage by 0.0721%.
The diff coverage is 54.5454%.

Flag
Coverage Δ

cdc
62.1976% <41.6666%> (+0.2176%)
:arrow_up:

dm
51.9384% <38.0952%> (+0.0082%)
:arrow_up:

engine
62.2842% <63.9534%> (+0.0996%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
@@               Coverage Diff                @@
##             master      #5879        +/-   ##
================================================
+ Coverage   57.0764%   57.1485%   +0.0721%
================================================
  Files           682        676         -6
  Lines         80224      79806       -418
================================================
- Hits          45789      45608       -181
+ Misses        30146      29940       -206
+ Partials       4289       4258        -31

/run-all-tests

I tested:
v6.1.0 -> this pr
v5.0.6 -> this pr
v4.0.14 -> this pr
./cdc cli changefeed create --sink-uri="blackhole://" --changefeed-id="test1" --opts "registry=http://schema-registry:8081"

This PR simply removes the dead code.
Before.
You pass opts it won't do anything, but it won't report an error.
After the change.
You pass opts again cli will report an error.
Upgrade
The original parameters won't work after the upgrade, and it won't panic.

/merge

/run-dm-integration-test

/run-dm-integration-test

/run-dm-integration-test


Can the actual errors please be passed back to client?

Hi, I imagine this happens elsewhere, but I am looking at signup giving a generic "something went wrong" type error. Could it pass back the actual error to be more useful? e.g. "email xxxx already in use"?
https://github.com/bigcommerce/storefront-data-hooks/blob/bf5d80224e4ae44413f6538b4855f88775e47494/src/api/customers/signup.ts

Yes, it's something we contemplate, I think in those cases like login it would be quite useful.
I close as it is a duplicate of #23


how to get selected columns name of a select sql

i already have getted table names by TablesNamesFinder like this:
String sql = "select field1,field2 from  (select field1,field2 from table_a left outer join table_b on table_a.aa=table_b.bb)";
Statement statement = CCJSqlParserUtil.parse(sql);
Select selectStatement = (Select) statement;
TablesNamesFinder tablesNamesFinder = new TablesNamesFinder();
List tableList = tablesNamesFinder.getTableList(selectStatement);
for(String tableName : tableList){
System.out.println(tableName);
}
but I don't know how to get elected columns name of a select sql,please help

Just use a deparser and override visit Column method to get all recognized columns.

@gunaskr You can, but selectItems could contain complex expressions. Those have to be deparsed as well.

@gunaskr You can, but selectItems could contain complex expressions. Those have to be deparsed as well.

You're right. But i specifically suggested the answer to find the selectItems. If you need to refine from their you could use SelectItemVisitor and ExpressionVisitor and pass any item of interest from the selectItems( given in my previous answer).

You could look at https://stackoverflow.com/questions/40908062/parsing-table-and-column-names-from-sql-hql-java?rq=1.
Maybe I should extend the wiki examples here.

Hi,
For the following select query:
SELECT F.* FROM FIRES F, (SELECT MAX(ESTLOSS) MAXLOSS FROM FIRES) M WHERE F.ESTLOSS = M.MAXLOSS;

I am able to get either of the following output by using various methods to retrueve the column names
F.*

(OR)
ESTLOSS
F.ESTLOSS
M.MAXLOSS

What is the method I should be using to get the following as the output?
ESTLOSS

Any help would be useful. Thanks in advance.

Are there any problems applying the suggested stackoverflow solution?

Both the techniques mentioned in the StackOverflow solution give me the following output:
ESTLOSS
F.ESTLOSS
M.MAXLOSS

But I was wondering if there is a possibility to get the following output i.e., the F.* should be expanded to columns corresponding to the table F and the column names found in criteria should not be included?
ESTLOSS

Ok. Now I understand your problem.
First of all JSqlParser is a parser and therefore not able to expand the definition of F because this is only known to your database schema. You need some kind of postprocessing JSqlParsers output.
The tablenames finder method visits all nodes within your parsed object tree. You need to first build a visitor that detects all SelectItems and for each SelectItem you should run the columns method above. The other possibility would be to switch of column name detection of TableNamesFinder if it is entering a where statement.
The F.* expression is not matched as Column but as AllTableColumns.

Ok. Thanks for the clarification!

@sivaraam So can we close this issue?

Yeah, I think we can given that there is only so much you could achieve with a parser alone 😉


Add aiohttp to cachito

Signed-off-by: Paul Belanger<EMAIL_ADDRESS>

Pull-request updated, HEAD is now 4ff9232527e35b83ab6acb84e54b74675425a7d4

Pull-request updated, HEAD is now 85b25c254816d8a98bafdd0de5a14a3bf5493247

Pull-request updated, HEAD is now f81e46b77976acae54b307477c875734ec0ad62e

recheck


upgrade to pydantic v2

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.

Example Code
All the chat model responses inheriting BaseModel are converted into dict using response.dict(). This throws the warning in the console
PydanticDeprecatedSince20: The `dict` method is deprecated; use `model_dump` instead. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.5/migration/
  response = response.dict()

Description
Need to update the package to migrate to the new pydantic version - https://docs.pydantic.dev/2.0/migration/#changes-to-pydanticbasemodel
System Info
langchain==0.0.336
Related Components

[X] LLMs/Chat Models
[X] Embedding Models
[ ] Prompts / Prompt Templates / Prompt Selectors
[X] Output Parsers
[X] Document Loaders
[X] Vector Stores / Retrievers
[X] Memory
[ ] Agents / Agent Executors
[ ] Tools / Toolkits
[X] Chains
[ ] Callbacks/Tracing
[ ] Async

Starting to work on async

To piggyback here, there's more than the deprecation warning at hand. Consider this minimal example (runs as-is, after pip install langchain_core and pydantic v2):
#/bin/bash python3
"""
The issue is, essentially, that the langchain toolchain does not support pytdantic v2 objects.
Here, I use the JsonOutputParser because that's my main exposure to the v1/v2 painpoint.
"""
from pydantic import BaseModel, Field, field_validator   # <- v2 namespace
from langchain_core.output_parsers import JsonOutputParser

class A(BaseModel):
    a: int

JsonOutputParser(pydantic_object=A)

It produces this error:
Traceback (most recent call last):
  File "minimum_6841_test.py", line 12, in <module>
    JsonOutputParser(pydantic_object=A)
  File "venv/lib/python3.11/site-packages/langchain_core/load/serializable.py", line 107, in __init__
    super().__init__(**kwargs)
  File "venv/lib/python3.11/site-packages/pydantic/v1/main.py", line 341, in __init__
    raise validation_error
pydantic.v1.error_wrappers.ValidationError: 1 validation error for JsonOutputParser
pydantic_object
  subclass of BaseModel expected (type=type_error.subclass; expected_class=BaseModel)

So, in short, the JsonOutputParser can't handle pydantic v2 objects.

would this help https://github.com/pydantic/bump-pydantic ?

Hello, when is pydantic v2 upgrade planned? It would be handy to use without the fears of version mismatch. Is there anything we could contribute to expedite it? Thank you


add vSphere 6.7.3 and update 6.7.2 & 6.7.1

Description

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots (if appropriate):
How Has This Been Tested?

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos6 ✔centos7 ✔debian. JID-260

@blueorangutan test centos7 vmware-65u2

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + vmware-65u2) has been kicked to run smoke tests

Trillian test result (tid-329)
Environment: vmware-65u2 (x2), Advanced Networking with Mgmt server 7
Total time taken: 31850 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr3564-t329-vmware-65u2.zip
Smoke tests completed. 77 look OK, 0 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

Test LGTM, let's review and merge need another +1/lgtm - @borisstoyanov @andrijapanicsb


Progress bar when downloading

Add a progress bar when downloading a video

I'm going to try -> cli-progress


Artifacts using TemporalMedian

Am I missing something?
Using:
clip = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/test edge bars.avi", format="YUV422P8", stream_index=0, cache=0, prefer_hw=0)
clip = core.zsmooth.TemporalMedian(clip, radius=1`)

with both the avx2 and the avx512 version on Windows11, Ryzen 9 7950X, Vapoursynth R65.
Artifacts change depending on the input color space.
This only happens with some files.
This does not happen with all files, but a bunch, I attached a small sample file
example.zip

no clue what the cause happens with different files with different resolution and color spaces.

Fascinating - thanks for the bug report. I'll take a look at what could be causing this in the next few days.
Do the artifacts appear on any other filters, or just TemporalMedian?

I have a sneaking suspicion that I already know what the issue is (and that's my handling of stride). I'll try and get some tests in soon.

Solid, thank you for confirming @dnjulek .
I'll update all of my functions to respect stride properly and then I'll post a new version.

Nice, looking forward to a fixed version.
(happy that it isn't an issue only I have and it is a problem with my hardware ;))

Selur, please try the 0.3 release, which should have everything fixed now: https://github.com/adworacz/zsmooth/releases/tag/0.3

At least here it is not fixed, now I get a black bar on the right side,... (resolution: 720x480)

Bugger okay, thank you for confirming.
I also found that it crashes with non 8-bit content as well, so I'll work on a new round of fixes.

I also found that it crashes with non 8-bit content as well

For non 8-bit stride you need to divide it by @TypeOf(T)

If you don't want to divide, sekrit-twc usually casts the ptr back to u8 and always makes the ptr shift as u8.
example:
https://github.com/vapoursynth/vapoursynth/blob/d27b54e121112cb85cdb8f4200c706396265bbb7/src/core/kernel/x86/convolution_avx2.cpp#L18-L21

I also found that it crashes with non 8-bit content as well

For non 8-bit stride you need to divide it by sizeOf(T)

Yup, that's exactly the solution I came to myself. Since all divisions are powers of 2, I've got no problems using division since the compiler will optimize it all to right shifts anyways.
@Selur - I've got version 0.4 up now: https://github.com/adworacz/zsmooth/releases/tag/0.4
I tested it locally with TemporalMedian (radius = 1) on RGB, YUV420, YUV422, YUV444, in 1920x1080 and 720x480 and I get no black bars anywhere. I even added unit tests to assert the stride handling behavior.
So fingers cross all of the artifacts/black bars issues should be fixed now.

Doesn't work either.

(for both avx2 and avx512)

Just to show that it's not just mpeg2 content:

small sample (190x240, MPEG-4 ASP): sample_mpeg4.zip

I've just build from source and the error doesn't happen, maybe the dll is wrong?

I tested both and used:
https://github.com/adworacz/zsmooth/releases/download/0.4/zsmooth.avx2.dll
https://github.com/adworacz/zsmooth/releases/download/0.4/zsmooth.avx512.dll
just tested it again.

To be sure it's nothing else I did, I simplified the script:
# Imports
import vapoursynth as vs
# getting Vapoursynth core
core = vs.core
# loading plugins
core.std.LoadPlugin(path="F:/Hybrid/64bit/vsfilters/SourceFilter/LSmashSource/LSMASHSource.dll")
core.std.LoadPlugin(path="F:/Hybrid/64bit/vsfilters/DenoiseFilter/ZSmooth/zsmooth.avx2.dll")

# Source: 'C:\Users\Selur\Desktop\sample_mpeg4.mp4'
# Current color space: YUV420P8, bit depth: 8, resolution: 190x240, frame rate: 30fps, scanorder: progressive, yuv luminance scale: full, matrix: 470bg, transfer: bt.601
# Loading C:\Users\Selur\Desktop\sample_mpeg4.mp4 using LibavSMASHSource
clip = core.lsmas.LibavSMASHSource(source="C:/Users/Selur/Desktop/sample_mpeg4.mp4")

original = clip
clip = core.zsmooth.TemporalMedian(clip, radius=1)

original = core.text.Text(clip=original,text="Original",scale=1,alignment=7)
clip = core.text.Text(clip=clip,text="Filtered",scale=1,alignment=7)
stacked = core.std.StackHorizontal([original,clip])

# output
stacked.set_output()

Okay, so it must be something related to my setup.
You did use https://github.com/adworacz/zsmooth/releases/download/0.4/zsmooth.avx2.dll right?

Yes, CRC64: E3D6E45A3C709BF6

Do you know a tool which calculates CRC64 on Windows?
SHA512-Hash of zsmooth.avx2.dll:
2c19f8cdce4b53be14d273b6bc20fb74263108d3fe5545c0c09a7f91c6fa2568b5a91b6178dd9a450c7013ad1e813ea57a0ac80697cf7e8537340408d1d9d6b0

found one:
crc64 zsmooth.avx2.dll
CRC: [0x50F2D3E114F1F9A4] File: [zsmooth.avx2.dll]

Redownloaded https://github.com/adworacz/zsmooth/releases/download/0.4/zsmooth.avx2.dll
crc64 is still 50F2D3E114F1F9A4
Seems like we are using different files

This is what I have on my end, which seems to match your original sha512, Selur
sha256
e6d9360b2fd8a1bc3a94ed81efd272bd533f6f553de9ef56a4d45a913ab8f7c3  zsmooth.avx2.dll
sha512
2c19f8cdce4b53be14d273b6bc20fb74263108d3fe5545c0c09a7f91c6fa2568b5a91b6178dd9a450c7013ad1e813ea57a0ac80697cf7e8537340408d1d9d6b0  zsmooth.avx2.dll

I'll try testing with your sample

Hmmm, I'm also seeing no issues at all using your test sample.
I'm using version 66 of Vapoursynth - what version are you using?

Used script:
import vapoursynth as vs
core = vs.core

clip = core.lsmas.LibavSMASHSource("/home/adub/Downloads/sample_mpeg4.mp4")
zsmooth = clip.zsmooth.TemporalMedian(radius=1)

clip = clip.text.Text("Original")
zsmooth = zsmooth.text.Text("Filtered")
stacked = core.std.StackHorizontal([clip,zsmooth])
stacked.set_output(0)

Do you know a tool which calculates CRC64 on Windows?

7-zip, right-click -> 7-zip has all the options.

I'm using R65 since some of the torch stuff I use isn't available for Python 3.12.
I'll test with R66.

Do you know a tool which calculates CRC64 on Windows?

7-zip, right-click -> 7-zip has all the options.

Name: zsmooth.avx2.dll
Größe: 946176 Bytes (924 KiB)
CRC64: E3D6E45A3C709BF6
so we are using the same file :)

Using R66 I still have the same error. :(

This is very strange. It's almost like the it's not processing all planes, or getting the wrong width for different planes.
I think I'm going to have to put a debug build together that spits out some of this information so we can see what the plugin is working with. I have no idea why it would be any different on your machine, since it should be using the same function calls in Vapoursynth for all of them.
It is interesting that the output looks a little different in VS 66 - there's some of the original image that's come through, but it's like one of the planes wasn't operated on properly.

It is interesting that the output looks a little different in VS 66 - there's some of the original image that's come through, but it's like one of the planes wasn't operated on properly.
I agree, using the same script:
R65:

R66:

I can reproduce this with the 0.4 release DLLs (both avx2 and avx512), however I cannot repo when compiling af9c95659b34d033dd8ae2172120282c0d217d83 with 0.13.0-dev.46+3648d7df1
Here's my env
Windows 11
7950X3D
        Core R66
        API R4.1
        API R3.6
        Options: -
        Number of Threads: 32
        Max Cache Size: 4096

Minimal test case:
import vapoursynth as vs
core = vs.core

clip = core.std.BlankClip(None, width=720, height=480, format=vs.RGB24, color=[127]*3)

zsmooth = core.zsmooth.TemporalMedian(clip, radius=1)

zsmooth.set_output()

Oh realllyyy???
That’s fascinating. I wonder if it’s a zig version difference (I’m using 0.12), or something else.
Or are you saying that the issue was created in DLL 0.4?
@NSQY - would you mind trying a rebuild using  0.12 with the latest commit?
I want to track down if it’s a zig version thing or a bug introduced in 0.4.

It might also be a cross-compilation issue, since I’m compiling the binaries on a Linux machine. Zig should be doing everything right for cross-compilation, but we’ll have to see.
I’ll look into setting up a Windows VM so I can attempt to replicate the problem myself.

Or are you saying that the issue was created in DLL 0.4?

I'm saying that I can only reproduce with whatever was used to compile the provided .dll files, so either they're based off a different commit or something went wrong in the compile.
I can reproduce the original problem with git checkout 0.2, but not the broken row of pixels. I can only reproduce this with the provided DLL.
The DLLs were compiled with this script, and cross compilation happens at this line specifically:
https://github.com/adworacz/zsmooth/blob/992421d08eca6a5692beab08bd56d9818598d255/build_all_libs.sh#L6
This was done on my Intel laptop, running Linux.
I’m going to set up a VM to see if I can get this issue reproduced.
Meanwhile, it sounds like the workaround is simply for Windows users to compile their own DLLs from source on the machines they’re going to run the DLL on.

Thankfully zig makes this trivial 😊

992421d08eca6a5692beab08bd56d9818598d255 .dll built with 0.12.0 on Arch using zig/zig build -Doptimize=ReleaseFast -Dtarget=x 86_64-windows -Dcpu=x86_64_v3 is bad.

This is great @NSQY ! I was starting to wonder the same thing, if it's related to the -Dcpu param.
If you run zig build -Doptimize=ReleaseFast -Dcpu=x86_64_v3 on you Windows install (not cross-compiling from an OS level, but from a CPU level), does the issue reproduce?
I'm starting to suspect that there's something wrong with the chosen SIMD vector lengths, and I'm wondering if it's specific to the CPU and not the operating system. Both you and Selur are running 7950X's, which have AVX512 and would use a 64 element wide SIMD vector for 8-bit content (for 512 bits). BUT the x86_64_v3 target uses a 32-element wide vector (256 bits), and shockingly so does the x86_64_v4 target
In theory, this shouldn't matter, but maybe I have a bug in my math somewhere or for some reason running 256bit vectors on a machine that supports 512bit vectors may be causing some kind of issue.

build -Doptimize=ReleaseFast -Dcpu=x86_64_v3 does indeed reproduce the ERROR with both zig 0.12.0 and 0.13.0-dev.46+3648d7df1 when compiled on Windows.

Excellent, we’re really narrowing things down now. I have a suspicion on the source of the issue.

I was checking this part of the code just now, I thought it would be here too.
About the width_simd formula, wouldn't  width - (width % vec_size) be better?

I was checking this part of the code just now, I thought it would be here too. About the width_simd formula, wouldn't width - (width % vec_size) be better?

They produce the exact same code after compilation. See this Compiler Explorer (Godbolt) link with both implementations. One jumps to other because they are identical.
https://zig.godbolt.org/z/fvW73PGrG

Okay, I've committed potential fixes to Temporal Soften and FluxSmooth as well.
sha256
30fc26acad1c5e1708598ca1503e41f447280bd1703b7c70fb44c7ee4df07a5b  zsmooth.avx2.dll

Please try this version of the DLL:
zsmooth.avx2.dll.zip

That one seems to work for me. 👍

I think with this we're good to go.
https://github.com/adworacz/zsmooth/commit/992421d08eca6a5692beab08bd56d9818598d255 ..\zig-windows-x86_64-0.12.0\zig.exe build -Doptimize=ReleaseFast -Dcpu=x86_64_v4

Summary
TemporalSoften1: ERROR
TemporalSoften2: ERROR
TemporalSoften3: ERROR
TemporalSoften4: ERROR
TemporalSoften5: ERROR
TemporalSoften6: ERROR
TemporalSoften7: ERROR
TemporalMedian1: ERROR
TemporalMedian2: ERROR
TemporalMedian3: ERROR
TemporalMedian4: ERROR
TemporalMedian5: ERROR
TemporalMedian6: ERROR
TemporalMedian7: ERROR
FluxSmoothT: ERROR
FluxSmoothST: OK
RemoveGrain1: OK
RemoveGrain2: OK
RemoveGrain3: OK
RemoveGrain4: OK
RemoveGrain5: OK
RemoveGrain6: OK
RemoveGrain7: OK
RemoveGrain8: OK
RemoveGrain9: OK
RemoveGrain10: OK
RemoveGrain11: OK
RemoveGrain12: OK
RemoveGrain13: OK
RemoveGrain14: OK
RemoveGrain15: OK
RemoveGrain16: OK
RemoveGrain17: OK
RemoveGrain18: OK
RemoveGrain19: OK
RemoveGrain20: OK
RemoveGrain21: OK
RemoveGrain22: OK
RemoveGrain23: OK
RemoveGrain24: OK

30fc26acad1c5e1708598ca1503e41f447280bd1703b7c70fb44c7ee4df07a5b  zsmooth.avx2.dll

Summary
TemporalSoften1: OK
TemporalSoften2: OK
TemporalSoften3: OK
TemporalSoften4: OK
TemporalSoften5: OK
TemporalSoften6: OK
TemporalSoften7: OK
TemporalMedian1: OK
TemporalMedian2: OK
TemporalMedian3: OK
TemporalMedian4: OK
TemporalMedian5: OK
TemporalMedian6: OK
TemporalMedian7: OK
FluxSmoothT: OK
FluxSmoothST: OK
RemoveGrain1: OK
RemoveGrain2: OK
RemoveGrain3: OK
RemoveGrain4: OK
RemoveGrain5: OK
RemoveGrain6: OK
RemoveGrain7: OK
RemoveGrain8: OK
RemoveGrain9: OK
RemoveGrain10: OK
RemoveGrain11: OK
RemoveGrain12: OK
RemoveGrain13: OK
RemoveGrain14: OK
RemoveGrain15: OK
RemoveGrain16: OK
RemoveGrain17: OK
RemoveGrain18: OK
RemoveGrain19: OK
RemoveGrain20: OK
RemoveGrain21: OK
RemoveGrain22: OK
RemoveGrain23: OK
RemoveGrain24: OK

626ade0f90768bd27f8df0cc02454d7b28b95b48 ..\zig-windows-x86_64-0.12.0\zig.exe build -Doptimize=ReleaseFast -Dcpu=x86_64_v3

Summary
TemporalSoften2: OK
TemporalSoften3: OK
TemporalSoften4: OK
TemporalSoften5: OK
TemporalSoften6: OK
TemporalSoften7: OK
TemporalMedian1: OK
TemporalMedian2: OK
TemporalMedian3: OK
TemporalMedian4: OK
TemporalMedian5: OK
TemporalMedian6: OK
TemporalMedian7: OK
FluxSmoothT: OK
FluxSmoothST: OK
RemoveGrain1: OK
RemoveGrain2: OK
RemoveGrain3: OK
RemoveGrain4: OK
RemoveGrain5: OK
RemoveGrain6: OK
RemoveGrain7: OK
RemoveGrain8: OK
RemoveGrain9: OK
RemoveGrain10: OK
RemoveGrain11: OK
RemoveGrain12: OK
RemoveGrain13: OK
RemoveGrain14: OK
RemoveGrain15: OK
RemoveGrain16: OK
RemoveGrain17: OK
RemoveGrain18: OK
RemoveGrain19: OK
RemoveGrain20: OK
RemoveGrain21: OK
RemoveGrain22: OK
RemoveGrain23: OK
RemoveGrain24: OK


Implement liststudents and listlessons commands

Fixes #15 and #14.
Implement commandsliststudents and listlessons. Tabs are also added to the GUI.

Codecov Report

Merging #68 (6ff87b3) into master (bc2424b) will decrease coverage by 0.74%.
The diff coverage is 20.00%.

@@             Coverage Diff              @@
##             master      #68      +/-   ##
============================================
- Coverage     60.19%   59.44%   -0.75%
- Complexity      445      447       +2
============================================
  Files            88       90       +2
  Lines          1658     1694      +36
  Branches        171      172       +1
============================================
+ Hits            998     1007       +9
- Misses          616      643      +27
  Partials         44       44

Impacted Files
Coverage Δ

...edu/address/logic/commands/ListLessonsCommand.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/ui/MainWindow.java
0.00% <0.00%> (ø)

...va/seedu/address/logic/parser/TeachWhatParser.java
84.21% <50.00%> (-4.68%)
:arrow_down:

...va/seedu/address/logic/commands/CommandResult.java
88.00% <87.50%> (-0.24%)
:arrow_down:

...du/address/logic/commands/ListStudentsCommand.java
100.00% <100.00%> (ø)

...ain/java/seedu/address/logic/commands/ViewTab.java
100.00% <100.00%> (ø)

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 bc2424b...6ff87b3. Read the comment docs.

Commit 3f7df15 implements a single info panel that is independent from the student and lesson tabs.


Add final code check link & confetti to tutorial completion page

What kind of changes does this PR include?

New or updated content
Changes to the docs site code

Description
Updates to the tutorial completion page:

Add a link to the final version of the tutorial code on GitHub and StackBlitz

Add confetti on page load to celebrate 🎊

Thanks for the idea @sarah11918! The confetti now only shows when you check the final checkbox off. Added bonus: you can uncheck and recheck as much as you want for extra confetti 🎉

Preview looks great! I think this is an amazing add to this page!


Reconsider Actor.main for v2

It could take care of asyncio.run for example, or it could be a decorator. There isn't much value in it now, compared to async with Actor.
A few mockups:
from apify import Actor

@Actor.main
async def main():
  Actor.push_data({})

from apify import Actor

async def main():
  Actor.push_data({})

Actor.run(main())

Let's just remove it


Floating Timezone: Today/Tomorrow incorrect

It appears that Todoist might have defaulted to a floating time zone. Which means that the Today/Tomorrow label changes according to GMT. So I (-8 GMT) keep having tomorrow's due dates, show as today. I'm able to work around by adding a time due (which adds a local timezone).

Yes. This is true. It does throw me off to see "Yesterday" displayed instead of "Today".

I just installed the Todoist module today, so I'm not sure how useful this fix is, but I simply added 1 to var diffDays on line 441 in MMM-Todoist.js. I'll watch to find out how many hours mine is off by to see if I can figure out a permanent solution so everyone can have their correct timezone.


Update chart victoria-logs-single to 0.8.2

This PR contains the following updates:

Package
Update
Change

victoria-logs-single
patch
0.8.1 -> 0.8.2

Release Notes

VictoriaMetrics/helm-charts (victoria-logs-single)
v0.8.2
Compare Source
Release notes for version 0.8.2
Release date: 2024-11-22

Removed redundant VECTOR_SELF_NODE_NAME env variable from vector values. See this issue.
Added Vector dashboard. See this issue.
updated common dependency 0.0.23 -> 0.0.31
fixed app.kubernetes.io/version tag override if custom tag is set. See this issue.
Upgraded VictoriaLogs 0.41.0 -> 1.0.0

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Edited/Blocked Notification
Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.
You can manually request rebase by checking the rebase/retry box above.
⚠ Warning: custom changes will be lost.


[Doc Improvement] [Content stage sharing state API]

Acrolinx Scorecards
We currently enforce a minimum score of 80.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/apps-in-teams-meetings/API-references.md
89
35
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.

Docs Build status updates of commit 27f8b94:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/apps-in-teams-meetings/API-references.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


[dv] Use platform-agnostic logs everywhere applicable

Added  `DV_INFO|WARNING|ERROR|FATAL that handles the switch between UVM logging and standard SV logging.
Updated all existing modules to use these macros instead of adding  `ifdef VERILATOR|UVM everywhere

prim_assert, sw_test_status, sw_logger_if

This change means that effectively all RTL code produced in OpenTitan or related to OpenTitan (such as Ibex) requires dv_cores.svh (well, at least all RTL using asserts). dv_macros.svh is a 15 kB source file with a lot of rather generically named symbols/macros.
For example, all users of Ibex now need to include dv_utils.svh as well (or need to provide similar macros and modify the source code accordingly). If they include the whole dv_utils.svh file, they need to be aware of name clashes, e.g. if they already have a DV_CHECK_GE function defined which might be implemented differently.
I find this a rather large dependency to add for just an error reporting macro. As a way out, can we provide a minimal version of DV_ERROR that uses $error within prim_assert_standard_macros.svh if DV_ERROR is not defined? That still doesn't solve the problem of how to specify the conditional dependency in fusesoc, but maybe we can push that discussion out further. But ideally, we can find a solution which doesn't need the dependency at all.

Very well, I can just replicate the `DV_ERROR macro in prim_assert. Macro redefinition shouldn't be a problem because of the ifndef guard.


cmd/go: go test -fullpath should include full paths for build errors too

What version of Go are you using (go version)?

f90b4cd6554f4f20280aa5229cf42650ed47221d

Does this issue reproduce with the latest release?
N/A
What did you do?

I ran this testscript:
! exec go test -C ./x -fullpath .
! stderr '\./x.go'

-- x/x.go --
package foo

var x = mistake

-- go.mod --
module test

What did you expect to see?
A passing test.
What did you see instead?
> ! exec go test -C ./x -fullpath .
[stdout]
FAIL
[stderr]
# test/x
./x.go:3:9: undefined: mistake
[exit status 1]
> ! stderr '\./x.go'
FAIL: /tmp/testscript142857279/x.txtar/script.txtar:2: unexpected match for `\./x.go` found in stderr: ./x.go

It seems to me that the intent of -fullpath is to cause all filenames to print in a way that's absolute, even when those errors come from the compiler rather than the test binary. I'd expect the compiler error to print an absolute path there too.

Yup, that sounds about right. I think that would be worth doing.

Sounds reasonable. This is essentially a revision on proposal #37708, so it should probably be a proposal itself.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

If we add -fullpath as build option, it may lead to confusion with the -trimpath flag:
        -trimpath
                remove all file system paths from the resulting executable.
                Instead of absolute file system paths, the recorded file names
                will begin either a module path@version (when using modules),
                or a plain import path (when using the standard library, or GOPATH).

What do you think if we just pass -test.fullpath to cmd/compile?

@quantonganh, if -fullpath and -trimpath are both specified, the “full path” logged by the test should correspond to the short filename joined with the package import path.
It isn't clear to me what -fullpath as a build option should do in that case, though. 🤔

Also: if -fullpath is (also) a build flag, should it apply uniformly to all build commands? It seems inconsistent to apply it to only the build portion of go test.


A supplementary question for the modification of PCA color coefficients

Hi Patrik, thank you for your answer last time, I am sorry to disturb you again.
In fact, I hava loaded a model that contains color information, but I didn't succeed to modify the PCA color coefficients in the mopharble_model.hpp draw in render::Mesh draw_sample.
I run the fit-model.cpp, after the line 220 of
std::tie(mesh, rendering_params) = fitting::fit_shape_and_pose(morphable_model, blendshapes, landmarks, landmark_mapper, image.cols, image.rows, edge_topology, ibug_contour, model_contour, 50, boost::none, 30.0f);
I have gotten a morphable model with 129 color eigenvalues but I didn't succced to read the PCA color coeffiecients and modify them, can you give me some indifications step by step for the modificatin of the color coefficients please?
In fact, I am still exploring your wonderful programs to get a better understand for your algo. And if we just want to load PCA color coefficients instead of using the texture information, we have to change something in these lines or not as my comprehension?
Mat affine_from_ortho = fitting::get_3x4_affine_camera_matrix(rendering_params, image.cols, image.rows);
Mat isomap = render::extract_texture(mesh, affine_from_ortho, image); (fit_model.cpp line 227 228)
Hopes for your guide.
Thank you in advance.
Sincerely

Hi,
As I mentioned last time, you can use draw_sample to modify the colour coefficients. It takes a vector<float>.
As the documentation says, fitting::fit_shape_and_pose fits the shape model, not the colour model. eos currently doesn't fit the colour model, however I think at the end of the fit-model-ceres example there's an example of how colour fitting might look like - but to make this succeed you need a light model and other stuff as well, see the various papers on 3DMM fitting, and it doesn't run in real-time.

Thank you very much for your help and anwer me quickly, I will try it.


⚠ Bofrost.lu has degraded performance

In 7188666, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1539 ms

Resolved: Bofrost.lu performance has improved in 4aa792d after 6 minutes.


New version: Tencent.VooVMeeting version <IP_ADDRESS>0

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
Resolve #161822

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

/azp run

/azp run

https://github.com/microsoft/winget-pkgs/issues/142854


Feasibility of using oneOf, anyOf or allOf in schema for jsonschema2pojo.

Hi,
Can anyone please let me know whether using oneOf, anyOf or allOf in schema for jsonschema2pojo will work or not. Or is there any other option to handle the scenario.

Have you seen https://github.com/joelittlejohn/jsonschema2pojo/wiki/Proposal-for-allOf,-anyOf-and-oneOf?

@lvimalchandran These features of JSON Schema have a lot of problems when it comes to static binding.  They are really geared to validation.  In general, it seems like any potential binding solution would require a validator during type selection.  That is blocking support for these keywords.

Hi,
I read the information here https://github.com/joelittlejohn/jsonschema2pojo/wiki/Proposal-for-allOf,-anyOf-and-oneOf
But I do not understand, if the jsonschema2pojo allows the use of simple OnOff?
Or the use of these keywords does not work at all?

Hi, I am working on a project which used to have jsnoschema2pojo Gradle plugin 0.5.1
the spec has the
attr: {
description: some description,
myannoation1: value1
myannoation2: value2
allOf {
$ref: anotherType
}
}
In version 0.5.1 this used to work once I did an upgrade to version 1.0.1 it stopped works.
I use a class to create my own annotations, because without this allOf, as this example
attr: {
description: some description,
myannoation1: value1
myannoation2: value2
$ref: anotherType
}
All that is out of $ref is not used, then my own annotations are not generated
Does anybody have any suggestions?
Is it related to this issue?

Any update on using oneOf

same question as AceHack: Any update on using oneOf's?

I'm curious what the expected Java class would look like in a "oneOf" scenario, since Java doesn't really have support for such a notion. Could one of you post an example of what you'd expect the output to be? Is the problem that you just want the schema generator to generate a class with all candidates of oneOf included in the class?
For example are you expecting this schema
{
  "allOf": [
    {
      "oneOf": [
        { "ref": "a.json" },
        { "ref": "b.json" }
      ],
      "oneOf": [
        { "ref": "c.json" },
        { "ref": "d.json" }
      ]
    }
  ]
}

to generate this class?
class OutterClass
{
  private A a;
  private B b;
  private C c;
  private D d;
}

Honestly, I'm just struggling with what the expected behavior would have been, and would probably benefit from a test schema and expected output.

Hi, just as a first idea not really knowing if it could work
Schema with oneOf
"dbParams":{
"oneOf": [
{"$ref": "#/definitions/mongoParams"},
{"$ref": "#/definitions/cassandra.Params"}
]
}
could give following classes:
class DbParams
class MongoParams extends DbParams
class CassandraParams extends DbParams
class OutterClass
{
private DbParams dbParams;
}
or use of an empty Interface like:
public interface DbParams
{
}
class MongoParams implements DbParams
class CassandraParams implements DbParams
class OutterClass
{
private DbParams dbParams;
}
Hope this helps

@dewthefifth it's not as this.
"oneOf": [
        { "ref": "a.json" },
        { "ref": "b.json" }
      ],

Sorry for the absence, I ended up sick for a bit.
@eirnym I understand the difference in my suggestion vs the schema, my point was that Java doesn't particularly support the notion of a "oneOf" or "choice". However, I didn't really consider using interfaces the way @andrevocat suggested. I think that adds another perspective that could be explored, albeit a perspective that could be very difficult to work with since it would end up creating a number of generic interfaces. It would need to be interfaces, since you'd be opening an opportunity for MongoParams to be a "oneOf" in any number of places (IE any number of interfaces), and optimally you'd be able to detect if the "oneOf" scenarios matched one another and reuse the interface, but in order to make sense I think it might need to match in terms of choices and in terms of name.
It's something worth considering though.

@dewthefifth I glad you're back and it wasn't serious. I'm sorry for my useless comment.
(all below examples are in YAML as it's much easier to type snippets by hands)
Basically it's annoying a bit for me to write every time:
# for generator:
extends:
   $ref: base_class.yaml

# for others:
allOf:
- $ref: base_class.yaml

For basic implementation in conjunction with library to check actual JSON with actual schema, I see following algorithm:

All branches which doesn't contain references and/or definitions -> ignore (with an exception of allOf -> merge)
I see it as: if there's only one allOf which takes a reference => it's the same as 'extends'
everything else -> just copy fields. It's seems to be impossible to tell a random generator and tell it "you should take only these fields" (this library supports many of them)

This will result with a class which extends defined in referenced.yaml, having 2 properties someProperty, someOtherProperty
type: object
allOf:
  - properties:
      someProperty:
        type: string
  - properties:
      someOtherProperty:
        type: integer
  - required:
      - someOtherProperty
  - $ref: referenced.yaml

This will result with a class which extends defined in referenced.yaml, having 2 properties someProperty, someOtherProperty, because you can't decide on this level how it would be (de)-serializing and in which cases which field to take. In Java only nulls are some "border".
type: object
anyOf: # or oneOf as well
  - properties:
      someProperty:
        type: string
  - properties:
      someOtherProperty:
        type: integer
  - required:
      - someOtherProperty
  - $ref: referenced.yaml

Yes, the way I see it:

allOf = merge
anyOf and oneOf = generate an interface with a number of implementing classes

There are countless examples where this approach would not accurately express the intent of the schema, but it's better than nothing.
In the case of anyOf/oneOf, Jackson (or any other library) will not be able to deserialize without some kind of type hint. So we would need to annotate with JsonTypeInfo and JsonSubTypes. We require that a sub type name is present in the allOf/anyOf schemas and we would require that a property name is chosen which will identify the 'type' of the JSON object. I'm not really interested in trying to support all possible JsonTypeInfo strategies defined by JsonTypeInfo.As and JsonTypeInfo.Id.

I prefer JsonTypeInfo.Id.NAME because it's a lot more secure. All the recent Jackson CVEs seem to be problems associated with allowing arbitrary classes to be instantiated with crafted JSON data.

The subtypes which restrict the types are not part of the CVEs.  It's when you don't restrict and allow any class by name where the CVEs come in like enableDefaultTyping.
https://www.google.com/amp/s/blog.sonatype.com/jackson-databind-the-end-of-the-blacklist%3Fhs_amp=true

@joelittlejohn we need to preserve inheritance if possible. Otherwise I'll have to repeat the same code every time I had an inheritance.

Any update?  Would love oneOf, don't really care about allOf?

This will always be a little funny because JSON Schema was never intended as a representation for a polymorphic class hierarchy, so solutions will either feel bolted on or can only use a subset of JSON Schema.

Hello everyone (by the way, great community job you are all doing here).
I've came across  jsonschema2pojo when trying to generate java code from some JSON Schemas that have the infamous (code generation speaking) allOf.
Please correct me if I'm wrong (I will probably be, I've just arrived), but may be we are mixing here schema validation with code generation. Things like additionalProperties should refer to validation which values can it have, not code which attributes the class can have.
Would it make sense to you that allOf, anyOf and oneOf were treated equally when it comes to code generation? Applying the following rules:

Every "schema" referenced in a "$ref" of a xxxOf should generate (apart from the class) an interface with the getters and setters defined in the "properties" of the referenced schema
Every xxxOf should generate a class that implements all the interfaces defined in the nested schemas and xxxOf's.

And at the same time has the "properties" defined in its nested "object" element.

This way you can accommodate every possibility, and it's the validation that should say if the content of the instance is valid or not. To me the structure should accommodate the minimal that contains every possible case, not be valid at compile time.
For instance, the "conflicting cases" mentioned in the wiki:
{
"allOf": [
{
"oneOf": [
{ "ref": "a.json" },
{ "ref": "b.json" }
],
"oneOf": [
{ "ref": "c.json" },
{ "ref": "d.json" }
]
}
]
}
Should generate:
* 4 interfaces (interfaceA, interfaceB, interfaceC and interfaceD), each one with the getters/setters definied in their respective schemas.
* 4 classes, each one for each schema (classA implements interfaceA, classB implements interfaceB, etc...). This was already being generated, we would be adding only the implements and @Override's
* A class that implements this 4 interfaces (this would be the one defined in the conflicting json schema) and @Override's all the getters/setters
* The naming would clearly be something to work on
I'll try to work on a PR

A first step to work on allOf could be the merging of compatible objects:
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "properties": {
        "MCVE": {
          "allOf": [
            {
              "type": "object",
              "properties": {
                "value": {
                  "type": "number"
                },
                "unit": {
                  "type": "string"
                }
              },
              "required": ["value", "unit"]
            },
            {
              "properties": {
                "unit": {
                  "type": "string",
                  "const": "(unitless)"
                }
              },
              "required": ["unit"]
            }
          ]
        }
    }
}

is equivalent to
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "properties": {
        "MCVE": {
            "type" : "object",
            "properties" : {
              "value" : {
                "type" : "number"
              },
              "unit" : {
                "type" : "string",
                "const" : "(unitless)"
              }
            },
            "required": ["value", "unit"]
        }
    }
}

and could be parsed accordingly.

Just throwing an idea, but it could be implemented as base class that has accessors to get the specialized object.
e.g. for
 {
   "allOf": [
     {
       "oneOf": [
         { "ref": "a.json" },
         { "ref": "b.json" }
       ],
       "oneOf": [
         { "ref": "c.json" },
         { "ref": "d.json" }
       ]
     }
   ]
 }

would end up being:
public class NameMe {
    // include additionalProperties get/set/etc

   public A getAsA() {
     // use A to parse the contents of this object
   }

   public B getAsB() {
    // use B to parse the contents of this object
   }

  public C getAsC() {
    // etc
  }

  public D getAsD() {
    //etc
  }
}

It would be responsability of the user to know what object could be used - but maybe this can make use of the actual schema to know such if it's something valid - such as:
public isC() {
  return isValid(rawContent, cSchema);
}

Since this feature request keeps coming up... JSON Schema was really designed for validation, not representing class schemas with inheritance, and that's why this doesn't quite work. Protobuf and Java records don't support inheritance either, and tend to suggest composition instead. If you really need inheritance, I'd consider a different codegen tool. Otherwise, I'd work with its limitations.

Yes David, I totally agree, the "*Of" should be just ignored,
however the structures inside should be generated/included just as if there had been no "*Of" container.
This would ensure user could move the properties around using their IDE refactoring function, if they want,
vs just missing them completely "without a trace".

This is the one thing I need so this tool can be used at all. Right now it generates 2 pojo's out of a large json schema, the second one contains the rest as oneof elements. Got it. I'll need to do it by hand then :/

Could we at least add a warning message in the output noting that *Of is currently not supported (maybe with a link to this issue / the wiki page)? As it is now, the maven-plugin just silently skips *Of, not generating anything in our case. If the plugin would print a corresponding warn message this would likely save many people a lot of time trying to debug why no schemas are being generated.

@Elewyth Yes, agreed, that makes a lot of sense.


Create k8s resources in support chart to run gcp-filestores-backup

fixes #4395

I think now it's tweaking this until it runs ok in the container continuously.

I don't think it will run until gcloud has the necessary credentials - so I will have to complete #4396


itvr-296-304-312--bcsc--dynamic-keycloak

(1) This replaces PR #127 (now closed); it appears that having multiple keycloaks initialized at the same time would cause the app to break (intermittently when only one keycloak was logged in, and completely when two keycloaks were logged in). Also, on Safari, the app would get into this infinite redirect loop immediately upon landing on the home page.
(2) Now, only one keycloak is initialized at a time, depending on what the user selects. The user's selection is persisted through redirects/refreshes using localStorage. Also, the app does not break if the user manages to log into both bceid and bcsc at the same time.
(3) I'm still not sure if this solution is ideal; what would be ideal is if the bceid and bcsc idps are both in the same keycloak realm; if this is not possible from a security standpoint, this video (https://www.youtube.com/watch?v=lJlKNmAsaiE) suggests using subdomains to determine which keycloak to use. For example, we would have bcsc.goelectric.ca, and bceid.goelectric.ca. However, this would involve UI redesigns and possibly need to coordinate with the people designing the "go electric" website that will point to our app...

@naomiaro I made the changes, setup a new itvr client in the rzh2zkjq realm, and gave Kuan the new env vars; should be good now!


fix: bring back type ignore for config import

Quickfix
Without #type ignore there is CI problem in pre-commit:
superset/config.py:959: error: Incompatible import of "CELERY_CONFIG" (imported name has type "Type[superset_config.CeleryConfig]", local name has type "Type[superset.config.CeleryConfig]")
superset/config.py:959: error: Incompatible import of "CeleryConfig" (imported name has type "Type[superset_config.CeleryConfig]", local name has type "Type[superset.config.CeleryConfig]")

SUMMARY

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TEST PLAN

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

Codecov Report

Merging #11333 into master will decrease coverage by 5.45%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master   #11333      +/-   ##
==========================================
- Coverage   65.66%   60.21%   -5.46%
==========================================
  Files         835      394     -441
  Lines       39656    24924   -14732
  Branches     3604        0    -3604
==========================================
- Hits        26042    15007   -11035
+ Misses      13505     9917    -3588
+ Partials      109        0     -109

Flag
Coverage Δ

#cypress
?

#javascript
?

#python
60.21% <0.00%> (-0.70%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

superset/config.py
90.15% <0.00%> (ø)

superset/db_engines/hive.py
0.00% <0.00%> (-85.72%)
:arrow_down:

superset/db_engine_specs/hive.py
53.90% <0.00%> (-30.08%)
:arrow_down:

superset/db_engine_specs/presto.py
69.76% <0.00%> (-11.67%)
:arrow_down:

superset/db_engine_specs/sqlite.py
65.62% <0.00%> (-9.38%)
:arrow_down:

superset/utils/celery.py
82.14% <0.00%> (-3.58%)
:arrow_down:

superset/examples/world_bank.py
97.10% <0.00%> (-2.90%)
:arrow_down:

superset/examples/birth_names.py
97.59% <0.00%> (-2.41%)
:arrow_down:

superset/views/database/mixins.py
80.70% <0.00%> (-1.76%)
:arrow_down:

superset/result_set.py
96.69% <0.00%> (-1.66%)
:arrow_down:

... and 448 more

Continue to review full report at Codecov.

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

cc: @willbarrett @mistercrunch

Going to merge this to get green checkmarks back on PRs (we need to sort out these linting mismatches on mypy/black)

Thanks for fixing this. I've had some issues with tox/mypy/pyenv lately where I think mypy/tox were using the wrong version of python in some cases. This helped https://pypi.org/project/tox-pyenv/, unclear on mypy / pre-commit


fix(README): add initial readme

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Environment variable OLLAMA_NUM_PARALLEL is ignored (Linux)

What is the issue?
After updating Ollama to the latest version (from 0.1.48) I noticed that the environment variable OLLAMA_NUM_PARALLEL is now ignored., Instead, the default value 4 is used.
My startup script:
export OLLAMA_MAX_LOADED_MODELS:2
export OLLAMA_KEEP_ALIVE:60m
export OLLAMA_NUM_PARALLEL:10
/bin/ollama serve
OS
Linux
GPU
Nvidia
CPU
Intel
Ollama version
0.2.5

The issue was in the syntax of setting the variables.
This is the correct way and is working as expected:
export OLLAMA_NUM_PARALLEL=10


kamel install uses the wrong channel in OLM

It's using alpha, meaning it will install 1.0.0-RC2: https://github.com/apache/camel-k/blob/ba2603da84ce40b61cdf7e1d05ca04ad19ec60c2/pkg/util/olm/operator.go#L43
We should fix it in a minor.

I have created a PR to set this to stable, pointing to the 1.0.0 (Current).


[web][api][SIMS #1145] Remove Scholastic Standing records for assessment requests

In the requests table on the assessment page of the ministry portal (top top table) scholastic standing records is not possible
In the DB, approved_data, assessed_by, assessed_date no longer used
ENUM labels pending and declined no longer needed
screenshots

Nice work @ann-aot . Added some comments.


[DOC] code-block fix on chemistry.py

PR Description
Please describe the changes proposed in the pull request:

Fixed code-block sphinx directive so that docs correctly render.

Because the only failure relates to an HTTP timeout, I'm going to merge this docfix so that it can get built on readthedocs.


Guess who's back?

For the ones who have missed the cause of my last absence from OS/etc, please follow this link:
https://twitter.com/gsscoder/status/821821285701451777
Here everything is explained.

Thanks! I think that having given full commit access to CommandLine main contributors allows the project to grow also with my coordination. Now you know the codebase better than me! ;)
Ciao

Does that mean there'll be an official 2.x release on nuget soon? That would be cool!

Yes, time allowing, but it will be in (advanced) beta status... :)


empty YAML and .from_yaml

Hi
Here is some piece of code
require "yaml"

class Something
  YAML.mapping(
    x: {
      type:    String,
      default: "bbb",
    }
  )
end

puts YAML.parse ""                # returns an empty YAML::Any
puts Something.from_yaml "o: oo"  # returns a Something
puts Something.from_yaml ""       # raises an error

which results in
$ crystal yaml.cr

#<Something:0x1db1f20>
expected DOCUMENT_START but was STREAM_END at 0:0 (YAML::ParseException)
[4379207] *CallStack::unwind:Array(Pointer(Void)) +87
[4379098] *CallStack#initialize:Array(Pointer(Void)) +10
[4379050] *CallStack::new:CallStack +42
[4373400] *raise<YAML::ParseException>:NoReturn +24
[4447594] ???
[4448248] *YAML::PullParser#expect_kind<LibYAML::EventType>:Nil +136
[4448090] *YAML::PullParser#read<LibYAML::EventType>:LibYAML::EventType +10
[4448267] *YAML::PullParser#read_document_start:LibYAML::EventType +11
[4470237] *Something +61
[4361522] ???
[4373081] main +41
[139780543627077] __libc_start_main +245
[4360153] ???
[0] ???

While parsing an empty string with YAML parser is all ok, it's not tolerated by the .from_yaml, even while the mapping don't declare any mandatory key.
I checked the mapping code a bit and I see why, but I'm not sure there would be an easy way to fix it. Or is there?

Perhaps the easier solution to consistent behaviour is to raise in all cases?

@jhass I think the empty content still a legal YAML. How about just return nil in YAML.parse, and skip the empty document in the Object.from_yaml?

Just as a side note, in ruby YAML.parse "" returns a FalseClass object.

@mose they discussed about returning false here, and maybe nil is better for "nothing here": https://github.com/tenderlove/psych/issues/149

Not sure what to do with this, an empty YAML is not like an empty object/hash.
@mose What's your use case?

My case is that I have a config Class with default values for all items in YAML.mapping, and the config file is optional. So when there is a config file to be found, I load the file content to create my config object. Otherwise, I want to create that config object with default values only.
 It will also be a bit faster like that.

@asterite your solution is good, but I still considered that empty content should be a valid YAML document.
Because in YAML document, it said:

A YAML stream consists of zero or more documents.

And the rule of stream is pasted below and it seems that empty content is still a valid yaml stream:
[211]	l-yaml-stream	::=	l-document-prefix* l-any-document?
                            ( l-document-suffix+ l-document-prefix* l-any-document?
                            | l-document-prefix* l-explicit-document? )*

@david50407 How can we implement YAML.mapping for this case?

I know if we move parser.read_document from Object.from_yaml into Foo#initialize(YAML::PullParser) and check if the stream is ended before here will be complicated.
IMO, accept STREAM_END appears in read_document with a optional flag that if we accept to read a STREAM_END for read_document, it will still yield the block. like this:
class YAML::PullParser
  def read_document(allow_stream_end = false)
    read_document_start if allow_end && kind == EventKind::STREAM_END
    value = yield
    read_document_end if allow_end && kind == EventKind::STREAM_END
    value
  end
end

I know that will use more time to compare the flag and the kind of current token, maybe it can be a separated function named like read_document_or_end
And we can raise in the built-in types (like Int32, Float64 ...) that don't have default values while we passed a empty document (because a empty document only can performed as a empty hash/array or null)
I think the empty content is the same to the content --- which means a stream and a empty document in it, so the action of "" and "---" should be the same at least.

@mose btw, you can pass "---" for a empty YAML document.

@david50407 yeah that's what I thought, but using --- works with YAML.parse and raises an error with Something.from_yaml


error: pathspec 'replace' did not match any file(s) known to git

run yarn generate on latest
"@cosmology/proto-parser": "^1.2.1",
"@cosmology/telescope": "^1.2.5",
Receiving the error
error: pathspec 'replace' did not match any file(s) known to git
Note: switching to '44a6a100a92f2984a760b41b7486fb9000ac670e'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 44a6a100a refactor/fix: build push sqs pipeline from branch (#7027)
Cloning into '.repos/cosmos-sdk'...
remote: Enumerating objects: 128532, done.
remote: Counting objects: 100% (1424/1424), done.
remote: Compressing objects: 100% (878/878), done.
remote: Total 128532 (delta 884), reused 950 (delta 510), pack-reused 127108
Receiving objects: 100% (128532/128532), 23.04 MiB | 14.09 MiB/s, done.
Resolving deltas: 100% (74438/74438), done.
remote: Enumerating objects: 32, done.
remote: Counting objects: 100% (22/22), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 32 (delta 1), reused 0 (delta 0), pack-reused 10
Receiving objects: 100% (32/32), 180.35 KiB | 753.00 KiB/s, done.
Resolving deltas: 100% (1/1), done.
remote: Enumerating objects: 164, done.
remote: Counting objects: 100% (131/131), done.
remote: Compressing objects: 100% (120/120), done.
remote: Total 164 (delta 32), reused 11 (delta 11), pack-reused 33
Receiving objects: 100% (164/164), 122.16 KiB | 1.44 MiB/s, done.
Resolving deltas: 100% (42/42), done.
error: pathspec 'replace' did not match any file(s) known to git

Hi, Thx for you feedback, could you please provide the path of the repo that I can reproduce this issue?

Hi, there're three steps in yarn generate:
"generate": "yarn generate:proto && yarn generate:packages && yarn generate:telescope",
"generate:proto": "./scripts/get-proto.sh",
"generate:packages": "ts-node --esm scripts/gen-package-types.ts",
"generate:telescope": "tsc scripts/codegen.ts --noEmit --skipLibCheck && ts-node --esm scripts/codegen.ts && yarn lint:fix"
And the error is usually from git. So I guess it's from this step: "generate:proto": "./scripts/get-proto.sh",
Since there's no git invoke inside process of codegen.ts.


Removed code for checking bucket name length=1 in check_dns_name

Already a condition exists for checking bucket name length<3 so this is not necessary to add another condition for checking length=1.
Fixes: #1785

Codecov Report

Merging #1792 into develop will increase coverage by 0.04%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop    #1792      +/-   ##
===========================================
+ Coverage    92.44%   92.49%   +0.04%
===========================================
  Files           53       53
  Lines         9876     9873       -3
===========================================
+ Hits          9130     9132       +2
+ Misses         746      741       -5

Impacted Files
Coverage Δ

botocore/utils.py
97.95% <ø> (+0.32%)
:arrow_up:

botocore/credentials.py
98.74% <0%> (+0.37%)
:arrow_up:

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 67d2782...38f1e71. Read the comment docs.


Add support for org policies to folder and project modules

Opening this PR to track work on adding support for org policies to the folder and project modules, leveraging the code in the recently added organization module.

lgtm


Run not working with Autohotkey

Could you please add https://atom.io/packages/language-autohotkey2 functionality, so I can run this language via your package? I believe (don't quote me on this) that the Autohotkey you have incorporated into your package is outdated.
That would be amazing!
Thanks <3

Stopped working for me also.


Extract method inside State that only uses BuildContext should be allowed

If you have the following code (you can imagine a larger closure since this one is easy but the point is the popup/dialog):
class Home extends StatefulWidget {
  const Home({super.key});

  @override
  State<Home> createState() => _HomeState();
}

class _HomeState extends State<Home> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: ElevatedButton(
          onPressed: () {
            showAboutDialog(context: context);
          },
          child: const Text('Press me'),
        ),
      ),
    );
  }
}

You can't extract this closure into a method. Only because it is using the context variable from the parameter. In this case, for StatefulWidgets I believe we could allow this function to be extracted since we can access BuildContext context from anywhere.

Related to:

https://github.com/dart-lang/sdk/issues/56853
https://github.com/dart-lang/sdk/issues/56852


Multiple target support

Current visualization is only capable of drawing lines from multiple sources to one target. To support multiple target:

[x] Add IP or hostname when generating ip.csv
[x] Query MMDB with target IP
[x] Change how lines are hashed in scanners
[x] Add target IP label to the visiualization: how to add only once?
[x] Change hash in the lines classes city -> source_ip_target_ip

Done in 53c0d6c7755dab0e3f83e9b5a76812629d218e0c


V3 is coming

Discussed in https://github.com/rphlmr/supa-fly-stack/discussions/66

Originally posted by rphlmr February 17, 2023
Hello there,
I'll publish a v3 with some breaking changes on the "auth module".
I have launched a new stack with a new way to commit auth session and I want to have the same pattern on every stack I maintain :)
Nothing hard to understand but a major change: requireAuthSession will no more magically refresh the session in loader.
Currently:

in loader function, If the access_token expires, I refresh it and reload the loader.
in action function, because we can't reload it, you have to commit the session in every return json.

In future, you will have to commit the session in loader and action.
Because writing the full header is too long, I have imagined something and will provide a response helper to handle that for you.
export async function loader({ request }: LoaderArgs) {
  const authSession = await requireAuthSession(request); // maybe a refreshed authSession
  const { userId } = authSession;

  try {
    const notes = await getNotes({ userId });

    return response.ok(
      { notes },
      { authSession } // will commit it for you
    );
  } catch (cause) {
    throw response.error(cause, { authSession });
  }
}

export async function action({ request, params }: ActionArgs) {
  const authSession = await requireAuthSession(request); // maybe a refreshed authSession
  const { userId } = authSession;

  try {
    await deleteNote(params.id);

    return response.ok(
      { success: true },
      { authSession } // will commit it for you
    );
  } catch (cause) {
    return response.error(cause, { authSession });
  }
}

Spoilers: authSession will have a cookie property that is nothing more than the result of sessionStorage.commitSession(session, {     maxAge: SESSION_MAX_AGE,   }).
Then, response.ok or response.error will put this cookie in headers :)
You can check what is coming here: https://github.com/rphlmr/supa-stripe-stack

Hey! nice stack dude!
Would you consider following the docs here https://supabase.com/docs/guides/auth/auth-helpers/remix and using the remix helper library for supabase?  (not sure if this existed when you started)

Hey! nice stack dude!
Would you consider following the docs here https://supabase.com/docs/guides/auth/auth-helpers/remix and using the remix helper library for supabase?  (not sure if this existed when you started)

Thanks 😇
I have one with only Supabase : https://github.com/rphlmr/supa-remix-stack but it is not up to date 😅

Awesome! i'll check it out - I also noticed your benchmarks around using RLS with Supabase... thats a real kicker 200ms delay is not nice.
Do you know if theres a way to avoid going through Gotrue with Supabase, I doubt it - but just wondering!
Really want to use RLS with managed Postgres, just exploring my options at the minute

Since this stack, I have built a SAAS project.
Server-side, I don't use RLS.
I use it front side to use RealTime on tables I want to react on change (for example: on a new mention in a comment, Realtime triggers a Remix revalidator.revalidate() to refresh the notification counter).
RLS here helps me to only react if the logged user is concerned.

I plan to make a new stack around Supabase, with Drizzle ORM (faster than Prisma, true SQL) and Realtime 🫢

I’ll try to use RLS server side in pure SQL when I have time.
If I found something reliable, I’ll ping you ;)

@rphlmr I appreciate that! I'll have a look into it myself in the mean time


A1 - Create account (2 pts)

As an administrator, I want to create an account so that I can see my soccer league and make changes to it

[ ] #24


Add DeepChem to projects that use rdkit

Reference Issue
None
What does this implement/fix? Explain your changes.
Add DeepChem to list of projects using rdkit.
Any other comments?

Thanks for that!


Add "total_domains" to quota json unmarshalling

[x] main
[x] v7
[x] v8

Description of the Change
Consumers of this library can access the total_domains field from the api with this change.
Why Is This PR Valuable?
The value of this parameters is not included into unmarshalled data and is missing at the moment. The value should be available from the API as documented in https://v3-apidocs.cloudfoundry.org/version/3.163.0/#organization-quotas-in-v3

Closing this PR for now, feel free to create an issue that includes a proposal for the UX changes as mentioned in https://github.com/cloudfoundry/cli/pull/2881


Inventor Class No Longer Available

uninstalled and reinstalled latest version--
what happened

Also unable to select my Ranger for new quests

Please fully read the changelog for any required RESPEC before update.
You now select inventor subclasses.