OpenBLAS has issues solving triangular matrices on win32

Using the 32 bit openblas causes timeouts while running the scipy tests:

https://ci.appveyor.com/project/scipy/scipy/build/1.0.40/job/7vqlq835677r4xde

Do I read that correctly - you are using a binary distribution of 0.2.19 from some third party site (which could be one of the sourceforge mirrors sites, but then again could be something else) ? Could you retest with the current "develop" snapshot which has a bunch of fixes vs. 0.2.19 (or at least build 0.2.19 yourself on your platform to see if it passes the built-in tests) ? In any case I guess a minimal example run on a well-defined system would be preferable to a big unedited dump from an appveyor vm.

That was built 12 days ago: https://github.com/scipy/scipy/pull/7616#issuecomment-318169023

In any case I guess a minimal example run on a well-defined system would be preferable to a big unedited dump from an appveyor vm.

Is there any way to turn on debug output?

excuse me; the URL was not apparently correct. Retrying with 2.20 now.

not sure if 0.2.20 will build in your environment (depending on how and where you build - a cross-compile on linux like the binaries provided on sourceforge will probably go okay. the issue is a botched commit that breaks things on non-glibc systems, waiting for xianyi to release 0.2.21) which is why I suggested taking a snapshot of "develop" (easily done by clicking on the green "Clone or download" button on the "Code" tab here). Normal build from source should run a few tests at the end automatically (though as a Linux guy I am not completely sure it does this on Windows as well.

Thanks for the link to the scipy issue. From reading that, it seems your tests were (at least at some point in the history of that PR) already done with 0.2.20 (?)
Do you still believe the problematic behaviour is with potrf specifically ?

Thanks for the link to the scipy issue. From reading that, it seems your tests were (at least at some point in the history of that PR) already done with 0.2.20 (?)

That's what I thought, but HEAD had 2.19. I updated to 2.20 just now.

Do you still believe the problematic behaviour is with potrf specifically ?

That is my suspicion; @carlkl used a completely different build method and still had issues with OpenBLAS on win32 but not win_amd64. Of course it would be helpful to get more debug output in order to understand what is happening.

That is my suspicion; @carlkl used a completely different build method

Specifically he used cross compiling with gcc rather than building with MSVC.

Cross compiling with gcc will currently get you the hand-optimized assembly functions (which use inline assembly and AT&T notation that MSVC does not support), building with MSVC will use generic C implementations instead (which are possibly still a bit faster than the netlib reference implementation).
Latest commits to "develop" allow compiling with clang which supports the optimized assembly (but will need a windows flang compiler for completeness)

Specifically what lapack is imported by arpack?

Specifically what lapack is imported by arpack?

Lapack and BLAS both come from OpenBLAS.

https://ci.appveyor.com/project/scipy/scipy/build/1.0.44/job/wix716oq76ft44r4
Looks like we still have issues:
  File "C:\Python36\lib\site-packages\scipy\optimize\tests\test_trustregion.py", line 76, in test_solver_concordance
    options={'return_all': True})
  File "C:\Python36\lib\site-packages\scipy\optimize\_minimize.py", line 486, in minimize
    callback=callback, **options)
  File "C:\Python36\lib\site-packages\scipy\optimize\_trustregion_exact.py", line 43, in _minimize_trustregion_exact
    **trust_region_options)
  File "C:\Python36\lib\site-packages\scipy\optimize\_trustregion.py", line 184, in _minimize_trust_region
    p, hits_boundary = m.solve(trust_radius)
  File "C:\Python36\lib\site-packages\scipy\optimize\_trustregion_exact.py", line 418, in solve
    delta, v = singular_leading_submatrix(H, U, info)
  File "C:\Python36\lib\site-packages\scipy\optimize\_trustregion_exact.py", line 185, in singular_leading_submatrix
    return delta, v
+++++++++++++++++++++++++++++++++++ Timeout ++++++++++++++++++++++++++++++++++++
[gw3] node down: Not properly terminated
fReplacing crashed slave gw3
...................F....F..........x................................................

It's not to difficult to reproduce; just download and install python 32 bit, install the wheel from appveyor and run the test. I can also instrument this if you want, just tell me what tooling I need to use.

(but will need a windows flang compiler for completeness)

Yeah, I actually opened an issue on flang for that; if anyone has time, I would be greatly appreciative.

Sure, and your binary numpy too, ten times.
Some backtrace would be nice....

Some backtrace would be nice....
I can also instrument this if you want, just tell me what tooling I need to use.

Sorry but I am not so familiar with debugging OpenBLAS. I am happy to provide a backtrace but I need assistance here.

The problem that I don't know how to debug an MSVC lib that has called into a gcc lib.

@matthew-brett Perhaps you would be better at obtaining the backtrace?

The OpenBLAS build is with a slightly aged Mingw variant over at https://anaconda.org/carlkl/mingwpy.  See: https://mingwpy.github.io.  The build runs on Windows (not a cross-compile).
I've just set off a build from OpenBLAS master, in case that's useful:

https://github.com/matthew-brett/build-openblas/commit/269689a02d41f2c859f08342f8cc76e35dfcfdac
https://ci.appveyor.com/project/matthew-brett/build-openblas/build/1.0.76

@xoviat - sadly I'm not experienced with this either.

Excuse me? You pull binary numpy linked against unknown BLAS and say that specifically OpenBLAS is at fault. Without backtrace that sadly goes nowhere.

Numpy is not being called here. We are calling OpenBLAS directly.

Numpy is only used for numpy.distutils.

Without backtrace that sadly goes nowhere.

I agree that this impossible to solve without a backtrace. How can I do this?

Usually you get debugger next to compiler.

My guess is that this is going to be undebuggable:
MSVC EXE (python) ==> MSVC DLL (*.pyd) ==> gcc DLL (OpenBLAS)

Just to check we're on the same page:

We're reporting some crashes, and some numerical test failures with the Scipy tests when linking Scipy Fortran code against OpenBLAS.
OpenBLAS is being built with a reproducible build on Appveyor using (a version of) gcc mingw-w64, linking against MSVCRT - links to the build above;
Numpy is being built with another reproducible build on Appveyor, using the OpenBLAS from the step above, using MSVC as a C compiler;
Scipy is being built with a reproducible build on Appveyor, using the OpenBLAS above, using MSVC as s C compiler, and mingw-w64 gfortran as a Fortran compiler.

Using this same rig, all running on 64-bit, we get no test failures or crashes.

Can you break into frozen process with a debugger? Is it reproducable?

I think what would be ideal is a fortran test case linked against OpenBLAS with no numpy/scipy involved at all. This should also eliminate any risk of a conflict between mingw and msvc runtime libraries.
(Or I guess just the input to potrf would suffice for building such a test case - but wading through a big appveyor log and scipy issue thread is a bit strenuous if done after regular work hours. Also do you have any indication what OpenBLAS thinks it is running on (CPU type) in the failing appveyor tests. (May be its in there somewhere but I missed it). 32bit windows probably sees less testing nowadays than the other platforms. Any chance to run the test on some local win32 system rather than appveyor virtual-whatever ?

I also got identical scipy errors on 32bit with OpenBLAS-0.2.19, OpenBLAS-0.2.20 as well as OpenBLAS-develop. I also made tests with different OPENBLAS_CORETYPE settings. However, I still didn't dig very deep into these errors right now.
For the interested: recent 32bit OpenBLAS binaries with debug informations can be found here:
libopenblas-v0.2.20-15-g1e9247c_win32_debug.7z
The name of the DLL is libopenblas_v0.2.20_mingwpy.dll, so the DLL can be used as a drop-in replacement for the libopenblas DLL with identical name inside @matthew-brett's numpy builds.

Can you reduce test case to few lines of python maximum? Like something fitting in a single page.
It does not even tell what was last that crashed slave did before crashing....
If you dont tell which function is called out of your provided or openblas-provided DLL it is hard to tell between 200 exported functions which one is wrong....

@pv created a testcase: https://github.com/scipy/scipy/pull/7616#issuecomment-320892300
results: https://github.com/scipy/scipy/pull/7616#issuecomment-321028819
as well as a list of failing Lapack functions:

sygvd
sygvx
sygv
hegvd
hegvx
hegv

More easily copypastable test case https://gist.github.com/pv/d5939656dcc0e36e0b66f4a4e7f1c6ba (copying from the github comment drops newlines...)

this testcase compiled with debug symbols:
testdpotr_test_gh_2691.exe   (28,2Mb !)

As all failing routines are Lapack Fortran functions I will recompile OpenBLAS with a different gfortran version and test again. Due to time constraints this may take some time.

Script sample looks reasonable, i will get off the beach next week and try it out (on linux)
We are not here with dll forensics, you could try with x64dbg on your own system, at least call chain best with arguments leading to crash(es). Small minimal screenshot is ok. Thanks already.

I'm not sure the claims above about crashes are accurate -- if I'm not wrong it's only wrong results that have been verified. The "crashes" in the tests are only timeouts, probably due to infinite (or nearly enough so) loops entered due to garbage output.

Yeah, I was wrong about the crashes. My guess would be an overflow.

Can you try develop version? @martin-frbg recently commited some crash fix of the type.

I think we just tried that.

I think we should just wait until you get back from vacation, as that will be the most time-efficient for everyone.

Thanks for sample. It is ennough for now.

Can you get appveyor vm cpuid? It is in variables.
Sample does not crash android-gnuroot-debian-armv7.

@matthew-brett Rebuilt HEAD with different compiler arguments and that resolved the problems. I am not sure whether you want to proceed with this issue.

test sample can stay in a closed issue. Can you share problematic args?

I'm wondering if #1271 could be related, i.e. xianyi's prebuilt windows binaries on sourceforge may be equally affected if it is a compiler version or options issue.

See https://github.com/scipy/scipy/pull/7616#issuecomment-321371519. This error did show up on 32bit mingw-w64 based on gcc-5.3. Other releases of mingw-w64 works well. This needs definitely more examinations.

In this build I built commit 5f998ef with current mingw-w64 32-bit toolchain, and we don't see any errors for @pv's gfortran test case -
and all the other Scipy crashes and failures go away.  On my previous mingwpy build I built the same commit, with @carlkl's Mingwpy toolchain, to get the failure on the test function as well as the failures you've seen in the logs above.

#1253 is another one that could be related, again dpotrf is implicated but that compilation was with mingw-w64 7.1.0 which appears to be what your successful build uses. Building without thread support
probably is a wholly different use case than yours however.

While betting on buffer sizing that sounds feasible theory.

Thinking of #1141 here ? This definitely needs looking into.

It seems that newer mingw-w64 versions can build Lapack without this error. This could be either an gcc bug or more likely a bug with mingw-w64 itself. Compiling OpenBLAS with a recent version of mingw-w64 and testing on this bugs seems to be a reasonable workaround right now.

@martin-frbg it needs backtrace and/or coretype, currently it is in state of trying to induce same testcase problem for whole day.

For comparison I compiled openblas_v0.2.20_1e9247c (develop) with mingw-build gcc-7.1 for 32bit. The dpotrf testcase https://github.com/xianyi/OpenBLAS/issues/1270#issuecomment-321391585 now runs without error. And all 32bit scipy wheels compiled with mingwpy also runs without errors and failures. (these builds are different from that created by @xoviat and mentioned in the commenat above).
It seems, that mingw-w64 toolchains based on gcc-5.3 and gcc-4.9 has problems with Lapack.

It should be all fortran77 from netlib
Can you build openblas without lapack and then netlib produce with -lopenblas ?

The mingw-w64 based builds mentioned in https://github.com/scipy/scipy/pull/7616#issuecomment-321803978 do not exhibit this erroneous behaviour. Is there a need to experiment with netlib Lapack as well? I may find some time this weekend to do some debugging, lets see.

we have almost no windows. Just to blame original build scripts or small adjustments made for building w openblas, or well windows compilers you use.

OpenBLAS uses interface/lapack/potrf.c instead of original lapack's dpotrf.f. Using dpotrf.f instead, I have no problems regardless what version of mingw-w64 I'm using.

Guess we could add something like
#if defined(OS_WINDOWS) && (defined(__MINGW32__) && <gcc version below 7.1>)
(nothing)
#else
(code overriding *potrf.f)
#endif

in interface/lapack/potrf.c to work around the apparent miscompilation on affected platforms ?

Actually all logs come from -march=native builds. Probably omitting all -O99 series would complete the build without a single problem

I take it you are suggesting that compiling interface/lapack/potrf.c with -O0 instead of the default -O2 would solve the problem with older mingw versions ? Not sure how easy it would be to cater for that in the Makefiles (not sure if -march=native is actually what they are using or intending to use, if my understanding is correct they are preparing a distribution package of some sort).

-march=pentium4 -msse2 -fpmath=sse ...
It is miscompilation by C compiler, not something to work around. Since build logs/options are not around for each and every 'build' and 'gcc version' i would take gcc7 claim with a big grain of salt.

Once again I am not sure I can follow your cryptic messages. My suggestion was to omit compilation of the problematic potrf interface if there is reason to believe the compiler is not up to that task.

It compiles just fine with gcc 4.6 included with windows rtools (compilers for r packages).
I am quite certain aggressive/unpopolar compiler options lead to miscompilation in this case.

I'm not going to create a PR to OpenBLAS with a patch to something without further diagnosis and debugging. However, using mingw-w64 with gcc-7.1 seems to be a workaround to this issue right now,

You dont even have exact compiler options for each failed case.
Your PR will be wrong, as old gcc can compile OpenBLAS without any problems. Please find problematic compiler option and report a compiler bug first.

@brada4 alienating developers of other projects helps noone. Even if your gcc 4.6 from rtools happens to be identical to the mingw-w64 build of the same version number this does nothing to refute the claim that at least the 4.9 and 5.3 versions miscompile potrf.c . If we really want to get to the bottom of this I guess we would need the intermediate assembler (gcc -S) output for this file from both "good" and "bad" compilers and someone who is capable of spotting the relevant differences.
For now, adding a note to the wiki (and perhaps ensuring that any future pre-compiled binaries for win32 made available on the project page at sourceforge are built with a recent gcc cross-compiler "just in case the problem carries over to cross-compilations") may be sufficient ?

I dont have compiler on windows. I can try to cross-compile with old and new crosscompiler and run test case on 64bit windows...
My speculation is based on assumption that typical distribution compiler option sets (-O2 -march=early-i686 -msome-memory-protector ) are million times better tested in GCC than -march=better-cpu

Please note that this issue appears to be specifically about mingw-w64 on Windows 32bit then.

Yes, yes, 32bit dll+exe running on 64bit windows.
It is very important to have it running at top quality since all alternatives are fading away.

I'm willing to dig into this. However, This takes some time as there are some topics with higher priority for me right now.

You are not alone. As a minimum find a linux distribution with good and recent gcc that produces production quality 32bit DLL

Have there been any new insights since then ? I tried to track any seemingly related numpy/scipy issues but as far as I could tell the discussions there seem to have moved on to inadvertent use of the 80bit extended precision Intel FPU mode causing problems in cdflib. So should we add a warning in the wiki to use at least version 7.1 of the mingw gcc for 32bit builds on Windows, or are there any indications that the problem may be bigger and in OpenBLAS itself ?

It turns out that we were compiling with a non-standard toolchain called mingwpy. We decided to drop that tool train in favor of vanilla mingw. That seem to resolve the problems.


A command to opt-in for statistics collection

As discussed in #288, if TLC/Toolbox statistics is enabled, Apalache will also submit stats similar to TLC.
I have added a new command called config, which control statistics collection as follows:

config --submit-stats=false disables statistics collection for Apalache (and also for TLC, and Toolbox)
config --submit-stats=true enables statistics collection for Apalache (and also for TLC, and Toolbox)

By default, Apalache does not enable collection. However, if it is enabled by TLA+ Toolbox, Apalache will also submit stats.
Two kinds of messages are printed:
# Usage statistics is OFF. We care about your privacy.
# If you want to help our project, consider enabling statistics with config --submit-stats=true.

and
# Usage statistics is ON. Thank you!
# If you have changed your mind, disable the statistics with config --submit-stats=false.

This has to be documented in the manual, once it is restructured.

[ ] Tests added for any new code
[x] Documentation added for any new functionality
[x] Entry added to CHANGES.md for any new functionality

I have added a section in the manual. Will merge now.

I have added a section in the manual. Will merge now.


Project Status?

Greetings,
I am very interested in your project.  I am working on a project that could use a native CAT library.    My project is outlined at http://www.hambus.org however it isn't up to date as I have changed strategies on how the buses will communicate from using UDP to SignalR.  Also with this change, BusMaster is now the main hub that all other buses talk to with SignalR.
The idea behind HamBus is Any Radio, Any Computer, Any Application, Anywhere.
Right now I have a RigBus for Kenwood CAT protocol and a VirtualRigBus that also speaks as a Kenwood radio would.  The idea is until application authors can add HamBus Rig API to their application users will be able to point applications to a virtual rig which will send the commands to the real radio(s).
The code is in somewhat of a mess, I have been adding code trying to get something working for Field Day and it isn't as clean as I would like for it to be.
It seems like our two projects can really help each other.
You can contact me at "darryl at wagoner.me"
thanks and 73
Darryl DE WA1GON

I'd someday like to pick this back up or, at the least have it inspire somebody to carry it out. So far the forks haven't done anything and, well, you know what life has been like over the past year. :D


Document dev.okteto.com/skip-snapshot-if-same-namespace: "true" ann…

…otation
This is useful to avoid cloning data when redeploying the volumes in the namespace where the source snapshot is defined

@jmacelroy ie this included in 0.15?

@rberrelleza yes, it is included in 0.15


Add tests for pkg/cassandra/gocql/testutils

Which problem is this PR solving?
This PR addresses a part of the issue #5068 by adding tests for the pkg/cassandra/gocql/testutils package.
Description of the changes
The commit introduces tests for the pkg/cassandra/gocql/testutils package to ensure the correctness of the User Defined Type (UDT) functionality. These tests cover the MarshalUDT and UnmarshalUDT methods of the CustomUDT type.
How was this change tested?
The changes were tested by running the following command:
make test

Checklist

[x] I have read CONTRIBUTING_GUIDELINES.md
[x] I have signed all commits
[x] I have added unit tests for the new functionality
[x] I have run lint and test steps successfully

for jaeger: make lint test
for jaeger-ui: yarn lint and yarn test

please provide output of
go test -cover ./pkg/cassandra/gocql/testutils/

It needs to be > 95%

also, remove .nocover file from the package

please provide output of
go test -cover ./pkg/cassandra/gocql/testutils/

It needs to be > 95%

Getting only 86.7% Coverage

to increase the code coverage you'll also need to write test for error cases

Coverage is at 100% now.

Thanks!

Thanks!

No problem, there is one remaining package with a FIXME, but someone has already raised a PR for it. Do you want me to look into that and complete it, so that this issue can be closed?

I will wait a few days for that PR author to come back (feel free to ping them there to ask if they plan to finish).
The goal was not only fix the FIXME packages, ideally we'd add test to everything and then make this a failing linter rather than a warning.
Verifying that all packages have test files to count in coverage
Package excluded from coverage: ./cmd/anonymizer/app/query/
  reason: non-critical test utility
Package excluded from coverage: ./cmd/anonymizer/app/writer/
  reason: nobn-critical test utility
Package excluded from coverage: ./cmd/jaeger/internal/extension/jaegerquery/
  reason: 🔴 FIXME
Package excluded from coverage: ./pkg/es/config/
  reason: requires connection to Elasticsearch

I will wait a few days for that PR author to come back (feel free to ping them there to ask if they plan to finish).
The goal was not only fix the FIXME packages, ideally we'd add test to everything and then make this a failing linter rather than a warning.
Verifying that all packages have test files to count in coverage
Package excluded from coverage: ./cmd/anonymizer/app/query/
  reason: non-critical test utility
Package excluded from coverage: ./cmd/anonymizer/app/writer/
  reason: nobn-critical test utility
Package excluded from coverage: ./cmd/jaeger/internal/extension/jaegerquery/
  reason: 🔴 FIXME
Package excluded from coverage: ./pkg/es/config/
  reason: requires connection to Elasticsearch

Ohh okay, understood. Thanks!


Test data format for list of GPUs in CSA workflow

          There should be a test for the format

Originally posted by @wilke in https://github.com/JDACS4C-IMPROVE/IMPROVE/pull/107#discussion_r1750931308

@wilke do you mean we need a test that check that the params['available_accelerators'] is valid?

The 'available_accelerators' parameters has been defined with an "nargs":"+" option, allowing it to be a list.
https://github.com/JDACS4C-IMPROVE/IMPROVE/blob/priyanka/fixes/workflows/parsl_csa/csa_params_def.py
@wilke Do you mean we need specific tests to check this?

Not relevant anymore.


Nuitka segfaults in ld call on aarch64

Python3.6.3
Linux 4.4
GCC 7.2.0
Aarch64
trying to compile a simple 'hello world' with:
pipenv run nuitka --show-scons --verbose print.py
segfaults as per in a call to ld as per:
https://gist.github.com/itdaniher/6343be4097dd35e78df5df06b3f88c8b
note that my compiler / linker chain is tested-working, built python and the kernel from source.

Getting the same error, while compiling on Jetson Tx2 (aarch64)
@itdaniher did you find any workaround
gcc -o hello.dist/hello.exe -Wl,-R,'$ORIGIN' -Wl,--disable-new-dtags -Wl,-b -Wl,binary -Wl,hello.build/__constants.bin -Wl,-b -Wl,elf64-littleaarch64 -Wl,-defsym -Wl,constant_bin=_binary_hello_build___constants_bin_start hello.build/__frozen.o hello.build/module.__main__.o hello.build/__constants.o hello.build/__helpers.o hello.build/MainProgram.o hello.build/CompiledCellType.o hello.build/CompiledFunctionType.o hello.build/CompiledMethodType.o hello.build/CompiledGeneratorType.o hello.build/CompiledFrameType.o hello.build/CompiledCodeHelpers.o hello.build/InspectPatcher.o hello.build/MetaPathBasedLoader.o hello.build/fibers_gen.o -L/usr/lib -ldl -lpython2.7
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
scons: *** [hello.dist/hello.exe] Error 1
scons: building terminated because of errors.

How about adding more memory, or swap file? Since you are having this on 64 bits, I wouldn't think it's a 2GB limit hit.

@shubjain26 I did not. I just stopped using Nuitka as I could not get it to behave and @kayhayen just chalked it up to ld.

Just so you know, even with the latest binutils 2.32 the problem is still there. At no point RAM is exhausted and I have a 16 GB swap file. Very quickly reproducible if you have a TX2.

@benelgiac You do realize, that a segmentation fault of ld when used with Nuitka is not a bug of Nuitka, but of ld and your specific binary? There is no way, I will debug ld crashes. But if it's reproducible, turn it into a minimal test case of ld and take it to the binutils maintainers.

Of course I do, I am not blaming anyone or asking you to debug anything but please consider that it's already the third tx2 user reporting the same issue, so probably it's worth understanding what's going on. Even if it has nothing to do with Nuitka, I think it would be useful if we could find a solution on this thread.
Since I cannot, am not able and do not want to even start considering looking into ld, I have tried to overcome the problem by installing lld, which should be a drop-in replacement for ld. I have compiled it and installed on TX2 and got an error as well, slightly better than a crash at least:
ld: error: unknown -format value: elf64-littleaarch64 (supported formats: elf, default, binary)
collect2: error: ld returned 1 exit status

Maybe this tells you something more than it tells me (i.e. lld is not very much a "drop-in" replacement)
Facts:

ld version 1.30 segments on simple hello world nuitka compilation
ld version 1.32 segments on simple hello world nuitka compilation
lld version 9.0.0 gives error on simple hello world nuitka compilation
I can successfully link other complex projects (i.e. OpenCV) on TX2 using both ld and lld
I have successfully used the same version of nuitka on tx2 on previous version of TX2 linux (based on ubuntu 16.04 and supposedly with a different version of ld)

If I will be able to spend more time on this, I will try to make it reproducible without nuitka.

@benelgiac You might want to try and change SingleExe.scons so it doesn't use resource_mode = "linker" but instead value code. I can imagine that it makes it easier for ld, or that your lld will then work.
Should it be that, coming up with a bug report to the binutils people would be possible.
Yours,
Kay

Hi @kayhayen I have not yet been able to test your suggestion, but in the meantime I found a workaround. Just using clang instead of gcc "fixes" the problem. It must be that the ld/lld bug is triggered only when attempting to link object files generated by gcc.
I am happy with this at the moment. Thanks for you help!

I wonder, if we should get into the business of warning about using clang on aarch64, as this may be happening a lot.
Yours,
Kay

I wonder, if we should get into the business of warning about using clang on aarch64, as this may be happening a lot.
Yours, Kay

Hello,
It indeed does happen a lot. I tried compiling a Flask application on an aarch64 Oracle Cloud instance and faced the same issue. Installing clang then appending the --clang parameter to Nuitka solved the issue.

Dang, these things are tough to reproduce naturally, but I guess, catching -11 exit code from the C tools on at least Linux, and turning it to stating something that a C compiler bug was encountered, could be a thing.

If you would be willing to test it @oddmario I could make the change, and you confirm it to work for you, if that's something you would be willing to do for the project.

If you would be willing to test it @oddmario I could make the change, and you confirm it to work for you, if that's something you would be willing to do for the project.

Sure! I'd love to.

It is there now: https://nuitka.net/doc/factory.html

I see, this is gcc converting -11 from its used tool to 1 error exit. So, catching it in C compilation, but not linking, however there it's likely to happen with LTO. So, I am working around that by searching for  terminated with signal 11 and pretending to have exit code -11 then (unless it's somehow zero, don't want to make things fail that did not).
Please retry with factory. I am of course no sure if this is stderr really, worst case it's stdout and will still not work. Please retry with current factory code.

I see, this is gcc converting -11 from its used tool to 1 error exit. So, catching it in C compilation, but not linking, however there it's likely to happen with LTO. So, I am working around that by searching for  terminated with signal 11 and pretending to have exit code -11 then (unless it's somehow zero, don't want to make things fail that did not).
Please retry with factory. I am of course no sure if this is stderr really, worst case it's stdout and will still not work. Please retry with current factory code.

Turns out it's stderr :)
Nuitka-Scons:INFO: Backend linking program (no progress information available).

collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
Nuitka-Scons:INFO: Running gcc -o /root/test/main.dist/main -fuse-linker-plugin -flto=4 -fpartial-inlining -freorder-functions -O2 -z noexecstack -Xlinker -export-dynamic -rdynamic -s -Wl,-R,'$ORIGIN' -Wl,--disable-new-dtags -Wl,-b -Wl,binary -Wl,./__constants.bin -Wl,-b -Wl,elf64-littleaarch64 -Wl,-defsym -Wl,constant_bin_data=_binary_____constants_bin_start<EMAIL_ADDRESS>-L/usr/lib -ldl -lm /usr/lib/python3.8/config-3.8-aarch64-linux-gnu/libpython3.8-pic.a -lz -lm -lutil -lpthread -lexpat took 1030.86 seconds
FATAL: Error, the C compiler 'gcc' crashed with segfault. Consider upgrading it or using --clang option.
scons: *** [/root/test/main.dist/main] Explicit exit, status 1

Thanks for working with me here, this will turn out to be very useless, esp. once sysexit gains URL support.

Part of the 0.7 release.


WIP Makwa Documentation

I am just looking for a review of my documentation so far, I do not want to embed any huge errors.
Some of the docs are "complete:"

examples/regular_interaction.rb
examples/returning_interaction.rb
examples/rub_returning_interaction.rb
guides/01-why_interactions_tldr.md
guides/04-features_and_conventions_of_interactions.md
guides/06-conventions.md
guides/08-returning-interactions.md (might need more but unsure)

Some of the docs are incomplete with some content:

guides/03-when_to_use_interactions.md
guides/05-how_to_use_interactions.md
guides/07-regular_interactions.md

And some are still empty:

guides/02-why_interactions_full.md
guides/09-run_returning_interactions.md

@jennifersarahpaul All of your notes should be addressed now

Thank you @corduroyj ! I am still seeing lots of mentions of Niiwin and nw, could you do a project-wide search in your IDE for those things? cmd+shift+f

@jhund All yours now! Thanks for taking over!


Added gray images support for adjust_contrast

Description:

WIP on adding gray images support for adjust_contrast

Related to https://github.com/pytorch/vision/issues/4466
cc @vfdev-5 @datumbox

The failing CI is not related.


README.md

@Celia-Vinagre-Izquierdo Could you please expand the information of the objectives in the README.md file? Many thanks.

date
max
avg
min


Extension fails to load on remotes

The extension fails to load when connected to remotes. The extension's icon is missing in the extensions panel, and clicking the "repository" link in the extension's info panel crashes the panel.
I've tried reinstalling this extension and its dependants, tried older versions, reloaded the window, cleared the remote cache, but none of this seems to have helped.
Problem started immediately after updating my VSCode to the version listed below. Haven't yet had time to try with an older version, but let me know if you'd like me to!
About VSCode info:
Version: 1.58.0
Commit: 2d23c42a936db1c7b3b06f918cde29561cc47cd6
Date: 2021-07-08T06:54:17.694Z
Electron: 12.0.13
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 19.6.0

From the dev console:
workbench.desktop.main.js:2350 Activating extension 'ms-vscode.test-adapter-converter' failed: Unexpected token '??='.
$onExtensionActivationError @ workbench.desktop.main.js:2350

workbench.desktop.main.js:2350 Cannot activate the 'Test Explorer UI' extension because its dependency 'Test Adapter Converter' failed to activate

$onExtensionActivationError @ workbench.desktop.main.js:2350
workbench.desktop.main.js:2350 Cannot activate the 'Jest Test Explorer' extension because its dependency 'Test Explorer UI' failed to activate

From the Log (Remote Extension Host) output panel:
SyntaxError: Unexpected token '??='
	at wrapSafe (internal/modules/cjs/loader.js:979:16)
	at Module._compile (internal/modules/cjs/loader.js:1027:27)
	at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
	at Module.load (internal/modules/cjs/loader.js:928:32)
	at Function.Module._load (internal/modules/cjs/loader.js:769:14)
	at Function.s._load (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:103:27800)
	at Function.b._load (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:103:24471)
	at Function.l._load (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:93:59004)
	at Module.require (internal/modules/cjs/loader.js:952:19)
	at require (internal/modules/cjs/helpers.js:88:18)
	at Function.t [as __$__nodeRequire] (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/loader.js:5:101)
	at c._loadCommonJSModule (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:103:25877)
	at c._doActivateExtension (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:89:12556)
	at c._activateExtension (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:89:11657)
	at Object.actualActivateExtension (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:89:9202)
	at d._activateExtension (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:84:97724)
	at /home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:84:97406
	at Array.map (<anonymous>)
	at d._activateExtensions (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:84:97394)
	at d._activateExtensions (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:84:97459)
	at d.activateByEvent (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:84:94728)
	at c._activateByEvent (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:89:10141)
	at c._handleEagerExtensions (/home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:89:15538)
	at /home/usr/.vscode-server/bin/2d23c42a936db1c7b3b06f918cde29561cc47cd6/out/vs/server/remoteExtensionHostProcess.js:89:17891

Finally! I was trying to understand why Python Test Explorer was failing on remote SSH, and this is the first reference I see to this issue. My stack trace is identical, but has the following line after the last one in the report by @pcjmfranken:
	at processTicksAndRejections (internal/process/task_queues.js:93:5)

Seems this commit introduced a ??= https://github.com/microsoft/vscode-test-adapter-converter/commit/bde7cd8a38142c670521fe060a34bdbd958f1bf0#diff-e0392fa4619b116ba340f9e72dfe933824ca1ab383850366a3f8e8ff6431104dR17

We are hitting the same problem. I think the issue is that the ??= (nullish assignment) operator is kinda new (here's the PR to add it to Typescript)
https://github.com/microsoft/TypeScript/pull/37727
But the version on our servers, which I don't have much control over, is probably older. I have verified that changing back to doing the check and assignment longhand fixes the issue.

Thanks for the issue, this was a problem in our version of esbuild not downleveling the conditional assignment operator


[ RNN ] Add Skeleton Code for RNNLayer

This PR includes,
skeleton of RNN Layer
Self evaluation:

Build test:	 [X]Passed [ ]Failed [ ]Skipped
Run test:	 [X]Passed [ ]Failed [ ]Skipped

Signed-off-by: jijoong.moon<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.4.20191203. Thank you for submitting PR #1025. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.

:octocat: cibot: @jijoongmoon, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://nnsuite.mooo.com/nntrainer/ci/repo-workers/pr-checker/1025-202103171654110.047446012496948-3bfa2c5b69050179e0d44eac632b396b5696a7c7/.


DEV-13943 DEV-13952 - Sets more hbase configuration by default

https://datatamr.atlassian.net/browse/DEV-13943
https://datatamr.atlassian.net/browse/DEV-13952

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


A preprint on cryptography using AMX

This is to let you know that I and some colleagues published a preprint for a paper on using AMX for cryptographic applications:
https://eprint.iacr.org/2024/2
Your repository was an invaluable resource for accomplishing our results. Perhaps you'd like to add a link to your references page. We think it might a good resource to help others.

Oh that's neat; thanks for letting me know.


Support mouse button remapping.

Remap mouse buttons 3-31 to any other commands. Left/right/middle mouse
buttons cannot be remapped. The keyword for mouse button is "button#"
where # is the button number.

Hi, @koekeishiya. Do you think this patch is useful? Thanks in advance for any feedback you may have.

Seems like a useful enhancement, but I'd like to find the time to workout #23 before any additional changes are made.

Thanks for looking at this. That makes sense. Let me know if you've any feedback on this after #23 is resolved.

Is issue #23 now considered solved? This seems like a useful feature to have, especially with the cmd-[ and cmd-] mappings suggested.

Is there a reason why this implementation does not allow modifiers for mouse-button hotkeys?

I'm not really happy with how this implementation was done, so I went ahead and implemented this functionality myself. See #52

@nshi @dominiklohmann  I would appreicate if either of you could confirm that the functionaity after my changes on master, and the functionality this PR provided, both work the same for the end-user.
Thanks for bringing this to my attention.


⚠ ClamAV has degraded performance

In 5546573, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 80 ms

Resolved: ClamAV performance has improved in f4beba7.


auto-advance to "create a cloud server" screen on successful DO new account setup

quoting https://github.com/uProxy/uproxy/pull/2583#issuecomment-233019150

Note, when you click "Proceed to uProxy" in our DO overlay, you're taken back to uProxy which is still sitting on the "Create an Account" / "I have an account" (sign-up-or-sign-in) screen. Ideally we'd make it so clicking Proceed would auto-advance to the "Create a cloud server" screen. We can do that in the future, but for now I addressed this with a context hint in the overlay: "You can now go back to uProxy and choose the ”I have an account” option if prompted" text.

Closing as this is not a priority right now.


Feature/cu nqd0xk PauseMenuDifferentScreens Error

When Escaping Pause Menu with ESC in Level 1, while being in the Settings Menu, it wouldn't close the other Menus.

Task linked: CU-nqd0xk Escaping Pause Menu with ESC doesn't work if it's in another menu of the Pause


Stat bars displaying over other UIs

Can the priority of the stat bars be lowered or lowerable/configurable?

Can the priority of the stat bars be lowered or lowerable/configurable?

You must reach out to the creator of the plugin you are using there, he has to set his widget to display above all.
The priority on statbars is defined correctly.


Dev docker multi user

@gecage952 let me know how it goes... I just did a translation from what I had before as I'm not sure I can run it locally anyway.

The docker will still serve on / but if you want to server on /app you might be able to set -e TRAME_URL_PREFIX=/app.

Sorry, just to update. I will get to testing this as soon as I can. It's just been a little crazy with the holiday and then a conference for the first part of this week.

Ok, apologies for the delay. I tried out the docker image, and I'm getting an issue where the Trame startup animation is playing, but the app never loads. If I try to refresh, I get an error in the console along the lines of:
Traceback (most recent call last):
  File "/deploy/server/venv/lib/python3.10/site-packages/aiohttp/web_protocol.py", line 452, in _handle_request
    resp = await request_handler(request)
  File "/deploy/server/venv/lib/python3.10/site-packages/aiohttp/web_app.py", line 543, in _handle
    resp = await handler(request)
  File "/deploy/server/venv/lib/python3.10/site-packages/wslink/backends/aiohttp/launcher.py", line 97, in handle_post
    return await self._waitForReady(session, request)
  File "/deploy/server/venv/lib/python3.10/site-packages/wslink/backends/aiohttp/launcher.py", line 109, in _waitForReady
    if self.process_manager.isReady(session, count):
  File "/deploy/server/venv/lib/python3.10/site-packages/wslink/launcher.py", line 480, in isReady
    if not self.isRunning(id) and count < 60:
  File "/deploy/server/venv/lib/python3.10/site-packages/wslink/launcher.py", line 468, in isRunning
    return self.processes[id].poll() is None
KeyError: '8cbd5f5c-3ecf-11ef-bd1b-0242ac110002'

Do you know anything about this? All of the dependencies for this project are publicly available, so you should be able to build and run it yourself. When running without Docker, the app behaves as expected.

Yes please fix that. I used what was in the readme. I’m off computer till
August.
On Wed, Jul 10, 2024 at 16:23 Gregory Cage @.***> wrote:

@.**** requested changes on this pull request.
In dockerfiles/setup/apps.yml
https://github.com/PaNGalaxy/AppLauncher/pull/2#discussion_r1672507250:

@@ -0,0 +1,14 @@
+trame:

cmd:

python

-m

template_app.app

I believe this should be launcher_app.app
—
Reply to this email directly, view it on GitHub
https://github.com/PaNGalaxy/AppLauncher/pull/2#pullrequestreview-2169507887,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACH45V62KOKDERL4YOFGV3ZLVGW7AVCNFSM6AAAAABKJ4RKU2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCNRZGUYDOOBYG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Just an update for when you get back. Ok, so the app itself is running nicely. After testing with various nginx configs for our vms, I think we actually will need the EP_PATH parameter working. The url prefix flag doesn't seem to work, but the rest of the container is working after I fixed some issues with the app itself (Completely my fault haha).

Also, a question has popped up while testing this. Is there a way to guarantee that a specific user/browser gets the same application or at least the same state every time they connect. At the moment it seems that all of the state is lost on refresh, which causes issues with authentication as we are redirecting to a third party login form. I see that you added the session id to the redirect endpoint that is set up here, but we actually can't configure wildcard redirect urls in our oauth provider to be able to properly redirect to these dynamically generated session ids.

Yes, you just need to use the same sessionURL across request in the URL/cookie logic. Right now, we just use the URL path, but a cookie one could be added.

Side note, with the latest push on dockerhub, the TRAME_URL_PREFIX env variable should properly work now.

Side note, with the latest push on dockerhub, the TRAME_URL_PREFIX env variable should properly work now.

Nice. Thanks for the heads up.

So, the cookie method would be setting the cookie (let's say trame_launcher_session) in the trame app (probably main) and then adding something like this to the apache config:
RewriteCond %{HTTP_COOKIE} trame_launcher_session=([^;]+)
RewriteRule ^/(.*)$ http://${session-to-port:%1}/$1 [L]

I'm not super familiar with apache, so do you know what the rule would look like?

The cookie will be managed on the client side directly, no server change involved. We will need to update trame-client to add such support. Otherwise, right now, you can use the url.

Ok gotcha.

The cookie will be managed on the client side directly, no server change involved. We will need to update trame-client to add such support. Otherwise, right now, you can use the url.

Do you know what URL to navigate to to get a specific session? I was trying /api/{session_id} but that didn't seem to route properly. For a few attempts on Friday, I thought that using ?sessionid={some_id} worked, but as I'm trying it now, it seems to just be creating new sessions.

If you are asking to get back to the trame app, it will be ?sessionURL={session_id}.

If you are asking for API endpoint (your own route), it will indeed be /api/{session_id}/{your api path on trame process}

Hm, for some reason, it's just showing the trame loading animation when i try the sessionURL method.
Basically, with my host being localhost:8080, and my session id being d2b2998e-58d1-11ef-bcb7-0242ac110002 , I'm trying to navigate to: http://localhost:8080/?sessionURL=wss%3A%2F%2Flocalhost%3A8080%2Fproxy%3FsessionId%3Dd2b2998e-58d1-11ef-bcb7-0242ac110002%26path%3Dws

http:// => ws:// not wss://

Whoops, thanks for that. When I go to the correct url (http://localhost:8080/?sessionURL=ws%3A%2F%2Flocalhost%3A8080%2Fproxy%3FsessionId%3Dd2b2998e-58d1-11ef-bcb7-0242ac110002%26path%3Dws) it seems to open the websocket connection, but it's giving me the loading screen again. In the web console, I see Connection error {code: -32000, message: 'Authentication failed'}. Have you seen this before?

I see... So you need to add &secret={something_secret} to that url as well. Basically the app/process was started with --authKey something_secret to prevent anyone with the sessionURL to connect if he was not the creator of that process who know that something_secret.

You can get that something_secret from the process of trame directly. It is part of its cli args.

Ok. I'll work with that then.

Sorry that I forgot about it...

Ok. So we've got some things working, but a couple of issues you might have some insight into. For context, we are running the trame docker container at localhost:8080 and we are running our own proxy at localhost (it's just nginx). Navigating to either of those URLs properly creates a new session of the trame app. When I want to return to a specific session, if I navigate directly to localhost:8080?sessionURL=whatever, it works properly. However, when I try to go through our proxy ie localhost?sessionURL=whatever, we're running into issues. After checking the apache logs in the Trame docker container, our proxy is correctly sending the request to apache and gets the index file, however when the js script tries to open a websocket connection, it's trying to connect to localhost instead of localhost:8080.
I recognize that this is probably tough to follow in text, so I took a screenshot of the networking (not sure how much it will help either though, sorry)

The logs show that the initial request is correctly of the form:
localhost?sessionURL=ws%3A%2F%2Flocalhost%3A8080%2Fproxy%3FsessionId%3D41db9df6-5a4e-11ef-8b77-0242ac110002%26path%3Dws&secret=pbcGONjF1ursLAi8
And this is getting passed correctly to apache.
Here's the nginx config if it helps:
location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        if ($arg_state) {
            proxy_pass http://<IP_ADDRESS>:8080/api/$arg_state$request_uri;
            break;
        }
        if ($cookie_trame_launcher_session) {
            proxy_pass [http://<IP_ADDRESS>:8080?sessionURL=ws%3A%2F%2F<IP_ADDRESS>%3A8080%2Fproxy%3FsessionId%3D$cookie_trame_launcher_session%26path%3Dws&secret=$cookie_trame_session_key](http://<IP_ADDRESS>:8080/?sessionURL=ws%3A%2F%2F<IP_ADDRESS>%3A8080%2Fproxy%3FsessionId%3D$cookie_trame_launcher_session%26path%3Dws&secret=$cookie_trame_session_key);
            break;
        }
        proxy_pass http://<IP_ADDRESS>:8080/$request_uri;
    }

Sorry, I know this is kinda hard to follow. Let me know if you need more info.

If you want we can have a quick debug meeting together but I can also try to write a couple of things below.

So normally you should see a POST request on /paraview. The response of that request should give you both the secret and sessionURL.
If that fails, the system will fallback assuming you are not running a launcher and try to connect to /ws.
From what I see it seems like the launcher was not detected.

I think the problem is that we see POST request to Paraview every time. And every time it creates a new session, even if we provide sessionURL.

I think the problem is that we see POST request to Paraview every time. And every time it creates a new session, even if we provide sessionURL.

That is indeed an issue and will need investigation on why you can not reconnect to an existing process.

I think I'm just missing your email

Let me respond to the earlier meeting invite.

One thing I noticed:
after seemingly same requests to apache (one directly from browser, one via nginx proxy)
<IP_ADDRESS>:8080/?sessionURL=ws%3A%2F%2F<IP_ADDRESS>%2Fproxy%3FsessionId%3D99aa4c26-5a85-11ef-b55e-0242ac110003%26path%3Dws&secret=ish5Tmh2ZLMNsiLU"
I get different redirects to proxy:
this is via nginx:
<IP_ADDRESS>/proxy?sessionid=9e11ce06-5a85-11ef-b55e-0242ac110003&path=ws
and this is direct:
<IP_ADDRESS>/proxy?sessionId=99aa4c26-5a85-11ef-b55e-0242ac110003&path=ws
the first one has wrong value for session id i(only first part of it - 9e11ce06). Any ideas? Where exactly is sessionURL processed?

No, those are 2 different sessions. Like you said, you always start a new process for some reason.

I know that they are different, the question is why the two requests with the same sessionURL send to /proxy with different session ids

The reason of that discrepancy is due to the fact that the proxy use the cookie to do the routing rather than the URL.


Resize Animated GIF to WEBP - Error: vips2webp: unable to encode

Version<EMAIL_ADDRESS>const response = await fetch(`https://ipfs.atomichub.io/ipfs/${ipfsHash}`);
const buffer = await response.buffer();

try {
    await sharp(buffer, { animated: true })
    .resize(width, height)
    .toFile(`./ipfs/${ipfsHash}.webp`);
} catch (e) {
    console.log(e);
}

Error encountered:
Error: vips2webp: unable to encode
Expected behaviour:
Convert animated GIF to animated WEBP image.
Alternative options tried:
Using pages: -1 instead of animated: true leads to the same error.
Sample image:
https://ipfs.atomichub.io/ipfs/QmNWwPSTynhoGx6UR4SKZwykp5uEUhLq5mQ3dt9jtmVeh2
Output of running npx envinfo --binaries --system?
npx: installed 1 in 0.922s

  System:
    OS: macOS 11.2.3
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 25.84 GB / 64.00 GB
    Shell: 3.2.57 - /bin/sh
  Binaries:
    Node: 14.16.0 - ~/.nvm/versions/node/v14.16.0/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v14.16.0/bin/yarn
    npm: 6.14.11 - ~/.nvm/versions/node/v14.16.0/bin/npm

What are the values of width and height for the sample image?

@lovell
width: 700
height: undefined

If you're resizing a multi-page image then you'll need to update the output with the new page height, in this example 700.
.webp({ pageHeight: 700 })

https://sharp.pixelplumbing.com/api-output#webp
Please see #2275 for a future possible enhancement that relates to this.

If you're resizing a multi-page image then you'll need to update the output with the new page height, in this example 700.
.webp({ pageHeight: 700 })

https://sharp.pixelplumbing.com/api-output#webp
Please see #2275 for a future possible enhancement that relates to this.

the above + .resize(width, height * pages)resolved my problem!!
Thank you very much!


Devaddr got only 8bytes, wondering if it's enough

Devaddr  got only 8bytes and each nodes need a unique Devaddr,
what if 8 bytes is not enough for all the nodes？

sorry, typo
only 4 bytes

Hi,
It actually has less as some bits are used for netID. As far as I know, the LoRa alliance says that this is not a problem as the real identification of the end-device is not only by DevAddr, but also by NwkSKey, which greatly increases the number of possibilities. I hope this reassures you :)

@ivajloip
Do you mean that different nodes could have the same DevAddr?

That's my understanding. Note that currently the implementation does not support this.

@ivajloip , I agree with you.
@brocaar  In loraserver, we can see redis keys like "node_session_00983e58", if different nodes have same DevAddr then they'll have the same redis key, thus will cause problems.
Maybe only store infomation in keys like "node_session_DevEUI" could solve this confict?
DevEUI is a large number which is enough for all.

Possibly, you could have different neighbouring NetIDs. I think the NetID (and thus the DevAddr pool within that NetID) can repeat, as long as two neighbours don't have the same NetID. Note that this isn't currently supported yet, as you'll start LoRa Server with a fixed NetID. From reliable sources I've heard that roaming is now a discussion topic within the alliance, there might be overlap with this topic I think...
@yzk0281 I need the DevAddr in Redis as this is the only lookup key I have when receiving an uplink packet :-) One possible way would be to assign gateways to different network segments so that based on the gateway receiving the packet, I know to which segment it belongs. With this, I could create a key like nwk_segment_X_node_session_00983e58. But again, I think this requires roaming in place, as your node might move from NetID A to B.

@ivajloip
could you give me some link where "the LoRa alliance says that this is not a problem as the real identification of the end-device is not only by DevAddr, but also by NwkSKey" ? I want to have a good look into this.

@brocaar
So what is your opinion if DevAddr is not enough?

As long as the networks (with different NetIDs) are small enough so that each DevAddr pool will not exhaust, that could work. But again, it needs roaming in place as your node might move from one network to the other. I'm looking forward to hear if the LoRaWAN v1.1 specs will cover this. Before starting to work on this and implement my own solution, I'd rather wait for an "official" solution (given it is being worked on of course).

@brocaar @ivajloip
Thank you guys.
Currently I intend to ignore the NetID digits, thus I can have more than 4 billion different DevAddr.
If it still not enough, then I think I will make some modify to the LoRawan as follows:

I will take advantage of the extra 1 byte before FRMPayload for DevAddr, so that 40 bits in total for DevAddr, it is enough for all.
What do you think of it?

@yzk0281
I heard this during the All members meeting of LoRa Alliance in Munich, so I can not provide you with document that states this.
Second point, as long as no roaming is required for your network, you have no problem using all the 4 bytes (i.e. without netID) and this was also said during the Munich event.
@brocaar
To the best of my knowledge, the netID's are given by the LoRa Alliance and they will be very important for the roaming. There are some values that are left for test purposes only, but all other values will be given to some network operators (Orange, Deutsche telekom, etc).
Hopefully in a few months we will have access to the specification so that we can tackle those problems :) For now I agree that it is too early.

This document explains the NetID allocation, and roaming impact, although not clearing the extra use of NwkSKey to unequivocally identify nodes.
https://es.scribd.com/document/317164891/20160603-NetID-Alloc-Policy-Application-1178-1

By the way, I found something that confirms my understanding about DevAddr uniqueness

The network session key (NwkSKey) is used for interaction between the Node and the Network. This key
is used to check the validity of messages (MIC check). In the backend of The Things Network this
validation is also used to map a non-unique device address (DevAddr) to a unique DevEUI and AppEUI
(see the Address Space page).

Using the NwkSKey to map a non-unique device address (DevAddr) to a unique DevEUI is sufficient, if the NwkSKey is unique (as recommended).

On 05 Aug 2016, at 10:02, Ivaylo Petrov<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
By the way, I found something https://www.thethingsnetwork.org/wiki/LoRaWAN/Security that confirms my understanding about DevAddr uniqueness
The network session key (NwkSKey) is used for interaction between the Node and the Network. This key
is used to check the validity of messages (MIC check). In the backend of The Things Network this
validation is also used to map a non-unique device address (DevAddr) to a unique DevEUI and AppEUI
(see the Address Space page).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/brocaar/loraserver/issues/56#issuecomment-237782589, or mute the thread https://github.com/notifications/unsubscribe-auth/AD-3iCq_eCTomelwXHPS8w56_shrdbq7ks5qcu4RgaJpZM4JaNCs.

Regarding non unique DevAddr I already found a problem in current loraserver architecture. It is possible to have several nodes with same DevAddr but different DevEUI. If you delete on of nodes all records from Redis for appropriate DevAddr are deleted as well.

It should not be possible right now to have multiple nodes with the same DevAddr, as the DevAddr is part of the Redis key, so they would overwrite each other.

As you said they are overwrite each other without notice. And it look like this afterwards:

So after creation of second node with same DevAddr data is overwritten in first one as well and then when I click Edit on the first one it open Edit page for the second.

Thanks for reporting this bug 👍 Will look into a fix!

@iBrick your issue has been solved and released as 0.10.1 thanks for catching the bug :-)

Thank you very much for fixing!
I wanted to ask how do you build project. I'm new to Docker and what I do is build it with command 'docker-compose up --build'. It build the binary successfully but recipe for target 'server' fail. I can use the binary locally afterwards but it doesn't start inside Docker.
Looks like it doesn't start because of missing params in Makefile 'serve' target:
./build/loraserver
I've added it like this:
./build/loraserver --net-id 010203 --band EU_863_870 --postgres-dsn "postgres://loraserver:loraserver@postgres_test/loraserver?sslmode=disable"
but still no luck as I get these errors:
"loraserver_1     | time="2016-08-12T07:15:20Z" level=fatal msg="controller-backend setup failed: backend/controller: connecting to broker failed: Network Error : dial tcp [::1]:1883: getsockopt:
connection refused"
mosquitto_1      |<PHONE_NUMBER>: Socket error on client 97e8825b-19ad-4fc2-8047-eaf1ba7ec70d, disconnecting.
loraserver_1     | make: *** [serve] Error 1
loraserver_1     | Makefile:41: recipe for target 'serve' failed"
And what is the way to debug program inside Docker?

After #68 I'll look into changing the way how the DevAddr is matched against the DevEUI. I'm thinking about changing the DevAddr related Redis key into a set of DevEUI items and then storing the actual node-session date in a DevEUI related Redis key.

I think this can help
http://portal.lora-alliance.org/DesktopModules/Inventures_Document/FileDownload.aspx?ContentID=1302

Thanks! Given
 I think supporting multiple DevEUIs on a single DevAddr is the way to go.

I forgot to update this issue after the 0.12.0 release:
please note that the node-session api since 0.12.0 now uses the DevEUI as session identifier. This doesn't resolve this issue, but see it as pre-work for implementing node-sessions by DevEUI instead of DevAddr (making it possible to handle duplicated DevAddr in the database).

I'm currently working on refactoring the session storage so that a single DevAddr can map to a set of DevEUI items.

This has been implemented in LoRa Server 0.15.0. Please refer to the changelogs for details :-)


Bootstrap 4 & Font Awesome TreeView checkboxes do not work

Using Bootstrap 4 and Font Awesome, the tree view checkboxes do not work. The boxes are there, but clicking does not check them.
Example: http://esdi.excelsystems.com/scripts/sdr/bootstrap4CheckboxesNotWorking.html
Changing to use Material Design icons also does not work - there is some graphic disruption/mismatch of some type.

I can confirm this, I'm having the same issue: the checkbox appear, but cannot select any of them.
You can check by changing in http://gijgo.com/LiveEdit/Index/bootstrap-4-treeview.html?component=tree the imageUrlField: 'flagUrl' line to checkboxes: true and then click Run example.
Thank you,
Cosmin

+1 on this. It looks like the fontawesome icons are messing it up.
I've found a work around, maybe the maintainers can do something useful with this:
/* Set the checkbox icons manually via CSS */
    .gj-checkbox-material-icons input[type="checkbox"]:indeterminate + span:after {
      content: '\2796';
    }

    .gj-checkbox-material-icons input[type="checkbox"]:checked + span:after {
      content: '\2714';
    }

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/open-iconic/1.1.1/font/css/open-iconic-bootstrap.min.css" />

$('#tree').tree({
        uiLibrary: 'bootstrap4',
        // Set the Expand/Collapse Icons to something explicitly, instead of using fontawesome
        icons: {
          expand: '',
          collapse: ''
        },
        dataSource: '/api/v1/controls/tree',
        checkboxes: true
      });

Would be great to see a fix for this, instead of a hack like above.

We are going to fix that in the new version. The new version is coming soon. stay tuned

The fix is already avialable in the latest development build located at https://github.com/atatanasov/gijgo/tree/master/dist

@atatanasov Would you consider adding support for custom checkmark/indeterminate icons, like the expand/collapse icons have? I tested the BS4 fix on master and it works, but we are not using font-awesome and don't want to include it just for two icons.


Roll engine 3e10d92b2bbb..f4591a73a5c7 (2 commits)

git@github.com:flutter/engine.git/compare/3e10d92b2bbb...f4591a73a5c7
git log 3e10d92b2bbb..f4591a73a5c7 --no-merges --oneline
2019-08-19<EMAIL_ADDRESS>Roll src/third_party/skia 8566dda51b42..5f152f07455c (8 commits) (flutter/engine#11241)
2019-08-19<EMAIL_ADDRESS>Provide a placeholder queue ID for the custom embedder task runner. (flutter/engine#11062)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (stuartmorgan@google.com), and stop
the roller if necessary.

Auto-roller completed checks. About to merge.


Add OECD Income Distribution Database

Updates the (fairly old) OECD datasets on inequality, from https://github.com/owid/owid-issues/issues/646

Thank you very much @lucasrodes! It's much cleaner, indeed


Your code doesn't seem to be completely released , When will the remaining code be released

Your code doesn't seem to be completely released , When will the remaining code be released

Any Update

Any update

Sorry for the delay. We plan to update the code in this or next week.

@menyifang YES! Thanks!! Looking forward to it!

@menyifang Looking forward to it!

@menyifang any update?


Create diamondprint.cpp

Please star this repository to show your support, in the meantime I am reviewing your code.


How to add tooltip in MDX?

How do you pass in tooltip config? In the example is only using badges. Also facing same problem after upgrading to 1.0.1, downgrading back to 0.2.2 #4
import { Meta } from '@storybook/addon-docs/blocks';
import { BADGE } from '@geometricpanda/storybook-addon-badges';

<Meta title="Path/To/MyComponent" parameters={{ badges: [BADGE.BETA] }} />;

So as far as the tooltip config goes, you set that in your preview.js when configuring the badge
i'm just resolving the issue with the import path right now

This should be resolved now, please re-open if you're still experiencing issues


Public Token Incorrectly Referred To As "Access Token"

The Plaid link API returns a public token but within the plaid-ios-link code it is incorrectly referred to as an access token. This can cause confusion.

Yes, Did you get any clue on this, even using sdk but not getting access token as well.
func linkNavigationContoller(_ navigationController: PLDLinkNavigationViewController!, didFinishWithAccessToken accessToken: String!) {
}


MODE-2478 Updates ISPN to 7.2.4.Final

This fixes the problem of the marshalling artifact which is now contained in the ISPN AS artifact.

Simple enough.


Feature: Closeness Centrality Component based on DAWN

https://github.com/ining7/DAWN-An-Noval-SSSP-APSP-Algorithm/pull/31


Scrum 3045 - new topic entity tag db schema and functions

Updated models to reflect the latest class diagram:

main tag table now contains all columns related to the tag itself (no shared core tag data anymore)
redefined source to map a source object (what generated the tag - e.g., a script, tool, a curator through a specific interface, an author through acknowledge)
validation is not pre-computed anymore. Each tag now has a list of tags that validates it (validated_by field in the main tag model)
will need a separate story to return validation values for each tag

Thanks @sweng66! I removed the duplicate lines following your comments.
validated_by is a list of tags that validate the current tag and is based on the sqlalchemy design pattern for many-to-many relationships, plus some configuration for self-relationship (it's a list of tags related to a tag) and more config to make it work with sqlalchemy continuum (the version tables). This is the documentation I followed: https://stackoverflow.com/questions/1889251/sqlalchemy-many-to-many-relationship-on-a-single-table https://docs.sqlalchemy.org/en/13/orm/basic_relationships.html#many-to-many. Yes, exclude_unset=True removes None values and this is useful when patching an object. We use this in other patch methods. We should revisit all the error messages, but I think we have a separate story for that and I didn't want to make this one too complicated.

Cool. Thanks @valearna

Changing the db model and API following comments from today's metadata meeting and the new structure in the class diagram


I have proplem in network but my connection is right it didn't work never please help me

🐛 Bug Report

Expected behavior
Reproduction steps
Configuration
Version: 1.x
Platform:

[ ] :iphone: iOS
[ ] :robot: Android

Hi @alim93593,
I will be closing this issue due to lack of information. Without the requested information we are not able to help. If you are still experiencing problems using the Geocoding plugin feel free to create a new issue and make sure to provide all requested information.


Test Smell: it is not a good practice for writing return statement in test casr

Hi!
I notice that you write a test case with a return statement.

It is not a good idea to write the return statement in your test case.
So I would like to know if is it really a useful test case?
Maybe I think you should remove the @test annotation from this method ?

I cannot find this line of code, please provide more details

https://github.com/OpenGamma/Strata/blob/c802688d7a5e3ee328275a5e469c45059b648ace/modules/calc/src/test/java/com/opengamma/strata/calc/runner/DerivedCalculationFunctionTest.java#L289

Hi,
Created a PR for this issue.
PR #2589
Please assign this issue to me and please let me know if any other changes are required.

Hi @davyboyhayes ,
The https://github.com/OpenGamma/Strata/pull/2589 has been merged, can you please assign the issue to me and close this issue.
Please do let me know in case anything else is needed to close the issue. (new to open source)
Thanks

I'm afraid I'm not an author/owner, so I don't have access to assign anyone.


006 2 add logout auth attempt2

Added the logout functionality to the backend and also added a button on the frontend. See note concerning the Login O Auth button. It seems to be working.

I know you posted in the Discord some issues with this branch, but I'm going to merge it for now as I believe that it's unrelated to the code itself. We'll troubleshoot at the upcoming meeting.


Change link of TakeLesson

Please change link of Takelessons from Crushbase to Wikipedia.
Link–https://en.m.wikipedia.org/wiki/TakeLessons

Thanks, for sure this is a better reference! d106967


[test] Make sure the components can render with a default theme

The objective is to prepare the migration into the main repository as much as to avoid theme requirement regressions until we do.

There is one test that check if it work with the dark theme. I was hesitating to remove it because I have never seen a bug in this direction, but I figure you might have, so kept it.


Add localization support

Is your feature request related to a problem? Please describe.
Currently, the UI is only available in Canadian English. Users might be silly and want things in a different dialect, or less silly and want it in a completely different language.
Describe the solution you'd like
Codebase should be refactored to support localization and tools integrated to support it.
Additional context
https://doc.qt.io/qt-5/internationalization.html
https://doc.qt.io/qt-5/qtquick-internationalization.html

I never worked with QT much so I can't help much with the codebase, but hit me up when you start integrating translations. I can then add german to it.


Misc commands: Add links to !issue, !pr and others

[ ] Add link to issue page to !issue
[ ] Same for !pr
[ ] Update !merge to be not John anymore
[ ] Remove !blueshell?
[ ] Move !servers to read from config
[ ] #130 Add hyphens as alias as well as dashes

The first 3 can probably be part of a GitHub cog. I have one or two other ideas for that two, mainly linking to PRs/Issues with hashtags like #179


"TryDownloadPrefetchPacks (Start)" message is missing from prefetch logs

In the latest version of VFS4G, the prefetch log includes TryDownloadPrefetchPacks (Stop) but is missing TryDownloadPrefetchPacks (Start).
This may be a recent break (when I checked logs from older versions TryDownloadPrefetchPacks (Start) was present).
Example:
C:\scratch\testClone>gvfs clone https://gvfs.visualstudio.com/ci/_git/ForTests
Clone parameters:
  Repo URL:     https://gvfs.visualstudio.com/ci/_git/ForTests
  Branch:       Default
  Cache Server: Default
  Local Cache:  C:\.gvfsCache
  Destination:  C:\scratch\testClone\ForTests
Authenticating...Succeeded
Querying remote for config...Succeeded
Using cache server: None (https://gvfs.visualstudio.com/ci/_git/ForTests)
Cloning...Succeeded
Fetching commits and trees from origin (no cache server)...Succeeded
Validating repo...Succeeded
Mounting...Succeeded
Registering for automount...Succeeded

C:\scratch\testClone>type ForTests\.gvfs\logs\gvfs_prefetch_20191014_132313.log
[2019-10-14 13:23:13 -07:00] Prefetch (Start) {"Version":"1.0.19224.2","EnlistmentRoot":"C:\\scratch\\testClone\\ForTests","Remote":"https://gvfs.visualstudio.com/ci/_git/ForTests","ObjectsEndpoint":"https://gvfs.visualstudio.com/ci/_git/ForTests"}
[2019-10-14 13:23:13 -07:00] PerformPrefetch {"Commits":true,"Files":null,"Folders":null,"FileListFile":null,"FoldersListFile":null,"FilesFromStdIn":false,"FoldersFromStdIn":false,"HydrateFiles":false}
[2019-10-14 13:23:14 -07:00] RetryConfig_LoadedRetryConfig {"Area":"RetryConfig","Timeout":"00:00:30","MaxRetries":6,"Message":"RetryConfigLoaded"}
[2019-10-14 13:23:14 -07:00] NetworkResponse {"RequestId":4,"availableConnections":12,"CacheName":"","StatusCode":200,"ContentType":"text/html","connectionWaitTimeMS":"0.0010","responseWaitTimeMS":"62.3842"}
[2019-10-14 13:23:14 -07:00] DeserializePrefetchPacks (Start)
[2019-10-14 13:23:14 -07:00] DeserializePrefetchPacks (Stop) {"DurationMs":2}
[2019-10-14 13:23:14 -07:00] TryDownloadPrefetchPacks (Stop) {"Area":"GitObjects","Success":true,"Attempts":1,"BytesDownloaded":0,"DurationMs":70}
[2019-10-14 13:23:14 -07:00] Prefetch (Stop) {"DurationMs":1625}

C:\scratch\testClone>gvfs --version
GVFS 1.0.19224.2

I have confirmed the behavior is the same with a cache server configured as well.

I'm actually not sure when this started now, looking back at old logs it's a mix of working and not working, but now it's consistently broken.


[HowTo] Remove QuickSearch Entirely

I was wondering if there was a way to splice out or hide the QuickSearch bar entirely. Keeping the column picker and refresh button is important to me, but I want to get rid of QuickSearch.
Anyone have a solution?

Override createQuickSearchInput and do nothing.
        protected createQuickSearchInput() {
        }

Thank you, Volkan. This is exactly what I wanted.


[Auth] Use 'password' for Email/Password provider ID

Fix #1199

FYI I reviewed by running git grep @\"email\" at various points in the commit history


Using the 0.2.2 download from Releases - build only works for 5.4 what 5.2.x or 5.3.x?

Hello! Go ahead and select "yes", the plugin should work fine in 5.3.

And now we've released 0.2.4. Please give it a try. I'll close this but feel free to report again if you have issues.


Fix "warning: initialization from incompatible pointer type"

This pull request fixes the following error:
engine.c:97:2: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
  engine_log_message,          // Log Message
  ^~~~~~~~~~~~~~~~~~
engine.c:97:2: note: (near initialization for ‘engine_module.log_message’)

The extra parameter syslog_type_int was introduced in PHP 7.1, see this commit.

For PHP < 7.1.0, this is necessary:
diff --git a/engine.c b/engine.c
index d3a7ead..4c87203 100644
--- a/engine.c
+++ b/engine.c
@@ -63,7 +63,11 @@ static void engine_register_variables(zval *track_vars_array) {
        php_import_environment_variables(track_vars_array);
 }

+#if PHP_VERSION_ID < 70100
+static void engine_log_message(char *str) {
+#else
 static void engine_log_message(char *str, int syslog_type_int) {
+#endif
        engine_context *context = SG(server_context);

        engineWriteLog(context, (void *) str, strlen(str));

Thanks! I might drop PHP 5.x support at some point and have more granular tags, but until then we'll need to use constants like so.

It's time to drop support for PHP 5.x.


optgrowth_issue

fix #937

Thanks @Harveyt47 , that looks good for me.

Here are the outputs from the change I have made (on the left) to the unchanged lecture (on the right) on the website which will currently have the bug in #937 as version 1.4.1 of scipy (current version) has the bug.

Great PR @Harveyt47.  Please add the ready label when you think it's ready to merge.

hey @Harveyt47 I have just updated our travis specification for testing. Can I merge the latest master into this branch to use this PR as a test case for the travis updated?

thanks @Harveyt47 the new travis run shows these all building:
Starting notebook execution for website and html conversion(if set in config)...
1569(1/4)  index -- pass -- 1.12s
1570(2/4)  optgrowth -- pass -- 79.15s
1571(3/4)  index_dynamic_programming_grad -- pass -- 1.03s
1572(4/4)  index_dynamic_programming -- pass -- 0.90s
1573build succeeded, 3 warnings.


Markdown card and new editor render  differently

Issue Summary
When I use blockquote inside the new editor, the HTML output is rendered as follows:

This is a test. I am a quote

I am just a header

Disregard this text right now

[...]

When the Markdown card is used, then the same content has a different HTML output:

This is a test. I am a quote

I am just a header

Disregard this text right now

This messes with the CSS of my theme, so that blockquote looks "broken" when the Markdown card is used.

This is very unfortunate for people who are migrating to Ghost 2.x, since the importer uses the Markdown card to import 1.x blog posts by default.
I also posted this issue in the Ghost Forums.
To Reproduce

Create a new post
Use blockquote in the editor and in a Markdown card
See the different rendering in source code

Technical details:

Ghost Version: 2.2.2
Node Version: 6.11.2
Browser/OS: Mac/Windows and Chrome 69
Database: MySQL 5.7

@jbfriedrich this is expected behaviour. The markdown output has not changed between 1.x and 2.x and can't change for backwards-compatibility as it's how 1.x content is "migrated" to 2.x (in reality there's no real migration happening because 1.x already used the 2.x mobiledoc format).
If you are writing themes then your CSS should handle all valid forms of blockquote markup. The Markdown, Embed, and HTML cards all allow completely freeform HTML so there's no guarantee that a
 will have a specific format - you may have content which has multiple
 tags along with a  element for example.

@kevinansfield So, how can we handle the fact we have to add quotes on blockquotes tag only if there aren't p tags inside of it? If there are p tags into the blockquotes tag we have to add the quotes on the p tag to avoid the behavior exposed above and maintain the same behavior between 1.x content and 2.x content. This is not possible in CSS.
Also, semantically, when I want to quote many paragraphs, why does the 2.x editor not use p tags to separate my paragraphs?


Error npm run production windowns 11 - Laragon 6.0

Laravel Mix Version: #.#.# (3.0.0)
Node Version: 12.5.0
NPM Version: 6.9.0
OS:

Description:
I'm using Laravel 5.7.* with vue.js 2.5.7 and it's showing me this error after compiling with npm run production, I switched to Windows 11 and I'm getting this error, I'm using node v12.5.0.
TypeError: s is not a function
    at t (vendor.js?id=e8cab89c9a8ffca82662:1:72199)
    at i.__patch__ (vendor.js?id=e8cab89c9a8ffca82662:1:73088)
    at t._update (vendor.js?id=e8cab89c9a8ffca82662:1:45235)
    at i.o (vendor.js?id=e8cab89c9a8ffca82662:1:80179)
    at En.get (vendor.js?id=e8cab89c9a8ffca82662:1:29323)
    at En.run (vendor.js?id=e8cab89c9a8ffca82662:1:29966)
    at qe (vendor.js?id=e8cab89c9a8ffca82662:1:20678)
    at Array.<anonymous> (vendor.js?id=e8cab89c9a8ffca82662:1:24509)
    at fn (vendor.js?id=e8cab89c9a8ffca82662:1:23984)

These are my dependencies
{
    "private": true,
    "scripts": {
        "dev": "npm run development",
        "development": "cross-env NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js",
        "watch": "npm run development -- --watch",
        "watch-poll": "npm run watch -- --watch-poll",
        "hot": "cross-env NODE_ENV=development node_modules/webpack-dev-server/bin/webpack-dev-server.js --inline --hot --config=node_modules/laravel-mix/setup/webpack.config.js",
        "prod": "npm run production",
        "production": "cross-env NODE_ENV=production node_modules/webpack/bin/webpack.js --no-progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js"
    },
    "devDependencies": {
        "@fortawesome/fontawesome-free": "^5.14.0",
        "axios": "^0.18",
        "bootstrap": "^4.0.0",
        "cross-env": "^5.2.1",
        "laravel-mix": "^3.0.0",
        "lodash": "^4.17.19",
        "popper.js": "^1.12",
        "postcss-css-variables": "^0.17.0",
        "vue": "^2.5.7",
        "webpack-bundle-analyzer": "^4.4.0"
    },
    "dependencies": {
        "@ckeditor/ckeditor5-build-classic": "^23.1.0",
        "@ckeditor/ckeditor5-vue": "^1.0.3",
        "ajv": "^6.12.3",
        "animate.css": "^3.7.2",
        "aos": "^2.3.4",
        "apexcharts": "^3.23.0",
        "bootstrap-vue": "^2.21.2",
        "chart.js": "^2.7.3",
        "element-ui": "^2.4.8",
        "imagemin": "^6.0.0",
        "jquery": "^3.4.1",
        "moment": "^2.27.0",
        "node-sass": "^4.12.0",
        "simple-keyboard": "^2.29.72",
        "toastr": "^2.1.4",
        "vue-apexcharts": "^1.6.0",
        "vue-chartjs": "^3.4.0",
        "vue-clipboard2": "^0.3.3",
        "vue-router": "^3.3.4",
        "vue-touch-keyboard": "^0.3.2",
        "vuex": "^3.5.1"
    }
}

I compiled it with npm run dev it doesn't give me that error, what I want is to do it with production.
I also compiled the same project with a w10 pc and node v12.5.0 and I don't get that error, I use laragon 6.0
I would appreciate your support

please show your error message in dev mode

did you solve this? I've been having the same issue and I'm not getting anywhere with it.


bootstrap.php.cache is missing

While in the codebender instance the bootstrap.php.cache file lives in Symfony/app/ folder, in the forever-alone edition is missing and makes the automation script to fail.
It is required here: https://github.com/codebendercc/bachelor/blob/master/Symfony/app/console#L10

You need to download composer and run "pho composer.phar install" while in the Symfony folder. But the scipt should already do that, so it seems a bit weird to me :/

On 5 Mar 2015, at 19:11, Pavlos Ratis<EMAIL_ADDRESS>wrote:
While in the codebender instance the bootstrap.php.cache file lives in Symfony/app/ folder, in the forever-alone edition is missing and makes the automation script to fail.
It is required here: https://github.com/codebendercc/bachelor/blob/master/Symfony/app/console#L10
—
Reply to this email directly or view it on GitHub.

After running it in a clean VM the file was generated. I will keep it open till I finish my tests and I will close it as invalid if it is generated in my other testing instances too.


authlib-injector support

authlib-injector is a project that aims to provide an alternative to Mojang's authentication system, which is similar to ely.by. However, authlib-injector does not use a centralized authentication server. It provides specifications for implementing authentication APIs, and encourages people to create and deploy their own authentication servers. (some detailed description of this project)
I'm wondering if you can support authlib-injector.

I'd love authlib-injector support as manually installing the authlib files doesn't work on a PaperMC server.

@Carlosjrlu have you tried the latest version (<IP_ADDRESS>)?

@erickskrauch I deployed an authlib-injector authentication server elyby.yushi.moe, which forwards requests to Ely.by.
Source code: https://github.com/yushijinhun/elyby-proxy
But there are still some problems:

Ely.by's textures payload is not signed, but authlib-injector requires the payload to be signed with either Mojang's key or a customized key.

To workaround this issue, I add a signature to the response while forwarding. However, clients using authlib-injector still can't see other players' skins unless the server is using authlib-injector too.
This problem can be solved if Ely.by signs its textures payload with its own key.

Some sensitive data (passwords, tokens, ...) goes through my service. Though I will not collect or store them, others might still feel it's insecure.

If you host this service, there will be no security concern.

@turikhay Doesn't work with PaperMC server sadly, I get this on console.
Exception in thread "main" java.lang.NullPointerException
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:398)
        at io.papermc.paperclip.Paperclip.getMainMethod(Paperclip.java:227)
        at io.papermc.paperclip.Paperclip.main(Paperclip.java:51)```

Tested @yushijinhun forward server and it works on server and on client.
About the security concerns, I see ely.by server accepts login with Mojang API aswell, would my players that connect with their official accounts be on a security risk?

@Carlosjrlu Can't reproduce this error. Please check you've added commons-io 2.5 and
commons-lang3 3.5 libraries to server classpath. Tested with authlib <IP_ADDRESS>, Minecraft 1.16.5, Paper build 468

@yushijinhun, I think the moment has come and it's time to finally implement this functionality on the Ely.by :) I don't give any ETA, but I'll take care of this issue as soon as possible. Thanks for the example of implementation!

@Nik-mmzd
I got the authlib from https://ely.by/load
And based on the instructions on that page I drag and dropped the content from authlib to the patched jar from paper.
Probably that's not the way it was intended to be used, but worked fine with vanilla server jar.
Can you lead me to some documentation for the server implementation of ely.by auth server?
The ely.by proxy made by @yushijinhun works fine tho.

And based on the instructions on this page I drag and dropped the content from authlib to the patched jar from paper.

/*coughs*, we should translate this article into English/

@Carlosjrlu for newest Paper versions (1.16.4, 1.16.5) you should:

download latest authlib <IP_ADDRESS> as @turikhay asked, commons-io 2.5 and commons-lang3 3.5
drag and drop authlib, commons-io and commons-lang3 contents (except META-INF folder) to patched Paper jar (located in cache folder)
run patched Paper jar

@Nik-mmzd Thank you, it worked. Where did you get that info tho? How would I know if there is a new authlib version? I don't seem to find any repo for it.
Btw something to think about is that with the authlib-injector from @yushijinhun the patch is done automatically, so it is easier when updating PaperMC. So I'm looking forward to an official support.

@Carlosjrlu

Where did you get that info tho?

I'm member of Ely.by developer team

How would I know if there is a new authlib version?

Currently there is no official way to check authlib updates... 🤔 We definitely need to do something about it ...

@Nik-mmzd Sorry for asking in this issue but, I need to.
Is there any security concern for the players connecting to my server through their official Minecraft accounts?
Does the information sent in the payload to the elyby auth server contains password or something?

@Carlosjrlu

Is there any security concern for the players connecting to my server through their official Minecraft accounts?
No.
Does the information sent in the payload to the elyby auth server contains password or something?
If non-ely player will connect any server he'll send all auth request to his auth server, not Ely one, so Ely will never receive any sensetive data like access tokens from such players.

Hey, are the authentication servers currently down? Can't log on to the server.

@yushijinhun, after a long wait, this task has finally been released! You can specify the domain ely.by (preferred), account.ely.by or authserver.ely.by as the base domain.

Currently there is no official way to check authlib updates... 🤔 We definitely need to do something about it ...

It is possible to write a simple server that will monitor the update of the version list https://launchermeta.mojang.com/mc/game/version_manifest.json
And based on it, do the matching of the authlib version

Currently there is no official way to check authlib updates... thinking We definitely need to do something about it ...

It is possible to write a simple server that will monitor the update of the version list https://launchermeta.mojang.com/mc/game/version_manifest.json / https://launchermeta.mojang.com/mc/game/version_manifest_v2.json
And based on it, do the matching of the authlib version

I'm using GitHub Actions to monitor the version list (see yushijinhun/minecraft-version-json-history). But it doesn't seem to make sense any more, because 1.18 experimental snapshots are not included in the list.


How can I custom my own rule

Hey , thanks for build such a useful extension.
There is the question : How can i custom my own rules? Or modify same rules ?
I noticed there is a pexe file , how do you develop / get/ build this file? Is there any open source for the file ?
Thanks again~

The pexe file is built based on https://github.com/pagespeed/page-speed
There are some changes to that repo to build, I have not made the change upstream.
For customizing rules, what specific do you want to customize? Some rules are configurable, such as the image compression.

Would you mind telling me the detail steps / doc to build the pexe file ?
Here is what I'd like to do with customizing rules. For examples, I am trying to punish js files that are not compressed, and give less punishment to the files that do not use E-tag/last-modify or ignore the "SpriteImages" rule.
Could you tell me the way or document to customize the configurable rules ? And is there any way to customize the unconfigurable rules by changing some code in the pexe file source code ?

I have planed to upload all the steps to build the pexe to this repo, but have not had the time to do it. Stay tuned.
For those you mentioned above, if that is for your own use, you can just simply ignore them. However, if the un-compressed js file is not marked, then that is a bug. You can file a separate bug for that. All the computation of the rules are in https://github.com/pagespeed/page-speed. Take a look at https://github.com/pagespeed/page-speed/tree/master/lib/trunk/src/pagespeed/rules.


Is it possible to not render the module, if a part is hidden by the icon

Type of issue
[ ] Bug
[ x] Question (e.g. about handling/usage)
[ ] Request for new feature/improvement
Expected Behavior
When having an icon in the middle of the QR-Code, the modules of the Code are only rendered, when they are fully visible.
Current Behavior
When having an icon in the middle of the QR-Code, it is possible, that only a small part of the module is visible.
Your Environment

Version used:  1.3.5
NuGet package
Used payload generator:  url
Used ECC-level:  H
Used renderer class:  Base64QRCode
Environment: .NET 4.7.2

Hi @fluflo ,
can you provide a sample graphic of what you want to achieve. (An image that shows what is wrong + what you expect.)

Hi @codebude
I uploaded the 2 versions to imgur: QRCodes

Hi @fluflo ,
the expected behaviour (render blocks even partly) was already implemented by this commit/PR: https://github.com/codebude/QRCoder/commit/f6701c1e3b3c7c1342eecf7cd7b8d931b679cd3d I hope you're not mad if I do not merge your's then. (The optional parameters from your PR are obsolete, because we totally removed the "Region" part from the rendering.)


experimental.modularity breaks as-named infix type

Compiler version
3.5.0
Minimized code
// used only as phantoms
sealed trait JsString
sealed trait JsNumber

infix sealed trait as[J, S]
object as:
  case object Str extends (JsString as String)
  case object Num extends (JsNumber as Double)

def test[J, S](
  repr: J as S,
  value: S,
): Unit =
  ()

Output
Compiling without any compiler flags succeeds:
scala compile test.scala

Compiling with -source:future also succeeds:
scala compile -source:future test.scala

Compiling with -language:experimental.modularity fails:
% scala compile -source:future  -language:experimental.modularity test.scala
Compiling project (Scala 3.5.0, JVM (21))
[error] ./test.scala:7:37
[error] ',' or ')' expected, but identifier found
[error]   case object Str extends (JsString as String)
[error]                                     ^^
[error] ./test.scala:8:37
[error] ',' or ')' expected, but identifier found
[error]   case object Num extends (JsNumber as Double)
[error]                                     ^^
[error] ./test.scala:11:11
[error] ',' or ')' expected, but identifier found
[error]   repr: J as S,
[error]           ^^
Error compiling project (Scala 3.5.0, JVM (21))
Compilation failed

Expectation
The modularity feature should not break existing syntax.

Let's track this under https://github.com/scala/scala3/issues/21769


HSEARCH-2772 Add an elasticsearch-aws module

https://hibernate.atlassian.net//browse/HSEARCH-2772
Since it's now possible, I also made sure one can execute JGroups/WildFly tests against AWS.
Proof it works: http://ci.hibernate.org/view/Search/job/hibernate-search-master-elasticsearchAWS/40/

Jenkins, retest this please...

Could you briefly explain why it had to copy verbatim test resources from the aws-signer project?
I'm uncomfortable with copying the ASL2 License file as we would need to make it clear to what portion it applies, and which not ...

Could you briefly explain why it had to copy verbatim test resources from the aws-signer project?

I did not. The test suite is provided by AWS to test signer implementations. It's a TCK, kinda. You can get it there: http://docs.aws.amazon.com/general/latest/gr/signature-v4-test-suite.html
In any case, we need the official AWS test suite to make sure signing works as expected. Running our own test suite against AWS is not enough in my opinion, because some cases that could happen in the future are not covered. And in fact, when I introduced the AWS test suite, only about half of it passed even though all of our integration tests were already passing.
Regarding the license file, the easier option may be to move the whole signing stuff to a separate, ASL2-licensed project... ?
I feel some explanation is needed regarding the implementation:

The dependency I'm using is a community project available here: https://github.com/lucasweb78/aws-v4-signer-java ; crucially, this project is ASL2-licensed.
This implementation is not well tested. In particular it didn't go through the official AWS test suite.
Probably as a result, this implementation has quite a lot of bugs, that I had to circumvent. That's why we have our own AWSSigner class wrapping the other.
I searched a lot, and there is no better alternative. The official AWS SDK only provides signing for requests that were built using the SDK; we can't do that, so if we wanted to use it to sign our requests we'd have to use internals. Other community projects like https://github.com/inreachventures/aws-signing-request-interceptor are more mature, but have bugs that cannot be worked around, and they are not well tested either (they don't use the AWS test suite).

When we were only using aws-v4-signer-java for test, I didn't care enough to do much about. But now that we intend to use it in Hibernate Search, we may want to address its problems...
In the future, I see three options:

Either I contribute my fixes and tests to the aws-v4-signer-java project, and when it's released we use it.
Or we re-implement what is currently in the aws-v4-signer-java project in Hibernate Search, and get rid of the dependency. It wouldn't be that bad, really; there's only about 200 lines of meaningful code in aws-v4-signer-java, all of which are really only about following instructions published in the AWS documentation.
Or we do option 2 (re-implement AWS signing), but in a separate, ASL2-licensed project of our own.

The second and third options may be easier, because I had to use some Apache dependencies, and aws-v4-signer-java makes it very clear that "no dependencies" is an important feature it provides.

So, after our discussion, I opened a pull request here: https://github.com/lucasweb78/aws-v4-signer-java/pull/4
On our side, I created a branch that uses the hypothetical aws-v4-signer-java v1.3: https://github.com/yrodiere/hibernate-search/tree/HSEARCH-2772-aws-v4-signer-1.3 . Of course, you have to build and install aws-v4-signer-java for this to work.
Let's wait and see if the PR is accepted.

@Sanne My changes have been merged into aws-v4-signer-java and released. I updated this PR to simply use the new version of aws-v4-signer-java. On the bright side, this PR is now much smaller ;)

Excellent! Thanks

There is now a duplicated class org/hibernate/search/elasticsearch/testutil/JsonHelper.java .
I didn't check yet if/why this is necessary, but in case it's necessary to not depend on one (or the the other) might be best to change the name of one of them to make sure there's no confusion in the future?

Jenkins, retest this please

merged! Great work. I've added a follow up PR to propose two very minor changes: pr #1473


how can i display curl in VSCode.

how can i display curl in VSCode.

Did you add PrettyDioLogger to your dio interceptors and make canShowLog:true?


Add cleanDestinationDir & disableFastRender options.

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

Thanks,
These 2 are defined as flags and documented in the CI section. I'm pretty sure we don't duplicate other flags into the config section, even if most flags can also be set as config.
https://gohugo.io/commands/hugo/
Also, we try to keep docs change not directly related to code changes in the hugoDocs repo:
https://github.com/gohugoio/hugoDocs


Doc: Add css system explanation

[ ] Short explanation over Tailwindcss, postcss, etc.
[ ] Short explanation over css variables
[ ] Explanation over HSL colors
[ ] Explanation over color themes for Yearn (light, dark, macarena, next) (next is new default)
[ ] Naming convention for css classname (.yearn--[component]-[exta])

on it!

I did not prioritize this one properly in the past weeks but working on it now :)

wip here https://github.com/MarcoWorms/web-lib/tree/css-docs