deconvolution code

Ian, could you pull the add_deconvolution branch and see if it build correctly for you?   It builds for me, but I'm getting this mysterious error on macos:
[Pavlis-Macbook:cxx/build/python] pavlis% python
Python 3.6.5 (default, Mar 22 2019, 21:04:14)
[GCC 4.2.1 Compatible Clang 5.0.0 (trunk 306208)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ccore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dlopen(/Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so, 2): Symbol not found: __ZN6mspass3agcERNS_14CoreSeismogramEd
  Referenced from: /Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so
  Expected in: flat namespace
 in /Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so

It is complaining about the CoreSeismogram object, I think, as the other random characters are from name mangling.   Note I can confirm this in a more raw form from this low level approach.  Used
nm ccore.cpython-36m-darwin.so > nm.out
vi nm.out

With that If find this section in nm.out
00000000002101c0 t __ZN6mspass29compute_energy_concentrationsEPdidS0_i
00000000001e1c90 t __ZN6mspass2L2ERNS_7dmatrixE
00000000002afb60 t __ZN6mspass2trERKNS_7dmatrixE
0000000000211270 t __ZN6mspass3ERR6getmsgEPc
00000000002112a0 t __ZN6mspass3ERR6getmsgEv
0000000000211240 t __ZN6mspass3ERRC1EPKc
0000000000211210 t __ZN6mspass3ERRC2EPKc
                 U __ZN6mspass3agcERNS_14CoreSeismogramEd
00000000002ad7b0 t __ZN6mspass3degEd
00000000002ad790 t __ZN6mspass3radEd
00000000002f8ff0 s __ZN6mspass3wtfE
00000000001e1ba0 t __ZN6mspass4LinfERNS_7dmatrixE
00000000002f9008 s __ZN6mspass4nwtfE

Any ideas how to sort this out?   I'm going to try this on my ubuntu machine to see if that can give me some insight, but in any case it might be helpful to see if you reproduce this on your mac.

Update on this.   I pulled that branch to carbonate and after some hiccups with the gcc confusion (seems I still need the -CMake flag incantation - thought we had cured that) I got this message when it tried to link the ccore python library:
[ 80%] Linking CXX shared module ccore.cpython-36m-x86_64-linux-gnu.so
/bin/ld: ../gsl/lib/libgsl.a(fft.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/bin/ld: ../gsl/lib/libgsl.a(error.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/bin/ld: ../gsl/lib/libgsl.a(stream.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [python/ccore.cpython-36m-x86_64-linux-gnu.so] Error 1
make[1]: *** [python/CMakeFiles/ccore.dir/all] Error 2
make: *** [all] Error 2

This suggests we may have a linking configuration error, but I don't know how to track this down.   Any ideas you could give on this would be appreciated as I'm stuck on debugging the deconvolution code until we resolve this.

I think I know what it is. It is some weirdness of Python library's requirement. Let me try to fix it.

So I got it fixed with adding the -fPIC flag in https://github.com/wangyinz/mspass/commit/fa7188e26c4ba7792a03861eae8ed6096023b1ae. The issue is that the python libraries are shared objects so it requires all the static libraries being linked to be compiled with "position-independent code". The caveat here is that if you are using a GSL provided by the system, it may not be compiled with -fPIC, and you will see the same error. I guess the fix will be always use our own GSL builds in cmake.

Hmmm - this doesn't seem to have fixed the problem on any platform I've tested.   What I've tried is:

Pulled your changes to macos test version on my laptop.  It still produces the error about the CoreSeismogram  mangled name not being defined.
I get the same behavior on carbonate.
On my ubuntu machine trying to load the ccore module causes python to seg fault immediately.  i.e. import ccore causes a seg fault.
Tested pulling the master branch form mspass and building it. This confirmed that the problem  was created by something changed in the add_deconvolution branch.  i.e master works fine.

I am stumped.  Not sure what to do next.  Any tools you can think of the help us sort this out?   ldd doesn't show any difference between the master and add_deconvolution generated ccore module except for the expected line for gsl.   Did you actually test anything more than getting things to link without an error?   I'm passing the ball to you to solve this problem - not critical as I'm not planning on doing that much this weekend and next week I'm traveling to visit grandkids.

You are correct, I only fixed the issue at linking stage and did not test it in Python. The original issue is actually a combination of two: 1) failed at linking stage because of lack -fPIC in GSL, and 2) inconsistency between the algorithm.h header and the actual implementation. So, I have (1) fixed, but you can still see errors at linking stage probably because the machines you are testing has a system GSL library provided, and it is not compiled with -fPIC. This is likely what happened on Carbonate.
In the case it linked fine but failed when importing the module, the error message is like this:
>>> import ccore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /mspass/git/mspass/cxx/build/python/ccore.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN6mspass3agcERNS_14CoreSeismogramEd

As the mangled name suggested, it is  the agc function not defined. I looked at the difference with the master branch and found this. You have changed all TimeSeries and Seismogram to the CoreTimeSeries and CoreSeismogram. However, such changes do not appear to the implementations (e.g. agc.cc). I guess you probably have that locally but somehow missed to commit to the repo.

First, thanks for finding that fix so fast.   I'm impressed as I have no idea how you figured that out so quickly.  Please educate me if possible.
Bad news is we still aren't there, and I'm getting different, but similar behavior on three different platforms I've tested this.  I can only easy get details on two which are:

When I import ccore in macos on my laptop I get this:

[Pavlis-Macbook:cxx/build/python] pavlis% python
Python 3.6.5 (default, Mar 22 2019, 21:04:14)
[GCC 4.2.1 Compatible Clang 5.0.0 (trunk 306208)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ccore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dlopen(/Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so, 2): Symbol not found: __Z5dcopyiPdiS_i
  Referenced from: /Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so
  Expected in: flat namespace
 in /Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so

On the carbonate.uits.iu.edu cluster I get this:

[pavlis@h1 python]$ python
Python 3.6.1 (default, Jun 28 2017, 11:37:04)
[GCC Intel(R) C++ gcc 6.3 mode] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ccore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /geode2/home/u070/pavlis/Carbonate/src/mspass/cxx/build/python/ccore.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN4YAML6detail9node_data10set_scalarERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

In both cases there is a linking problem. Macos one is for dcopy, which is mysterious, and the carbonate error is a function in the yaml library.    I don't remember what I got for the ubuntu machine I tried all this on.
Any more great ideas?

Well... this is strange. So I went on Carbonate and compiled the code with these modules:
  1) intel/19.0.5       4) git/2.13.0         7) boost/gnu/1.72.0
  2) perl/5.24.1        5) core               8) python/3.6.8
  3) quota/1.2          6) cmake/gnu/3.8.0    9) gcc/9.1.0

and this command:
cmake .. -DCMAKE_C_COMPILER=gcc  -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran -DBOOST_ROOT=/N/soft/rhel7/boost/gnu/1.72.0

When everything is done, and I do the import ccore in Python3, I can only reproduce the error similar to the first on you listed complaining about the dcopy undefined.
I was able to get ride of that with:
diff --git a/cxx/src/lib/deconvolution/ShapingWavelet.cc b/cxx/src/lib/deconvolution/ShapingWavelet.cc
index d301ea7..6b177b1 100644
--- a/cxx/src/lib/deconvolution/ShapingWavelet.cc
+++ b/cxx/src/lib/deconvolution/ShapingWavelet.cc
@@ -7,8 +7,9 @@
 #include "mspass/deconvolution/ShapingWavelet.h"
 #include "mspass/deconvolution/wavelet.h"
 #include "mspass/deconvolution/FFTDeconOperator.h"
+#include "misc/blas.h"
 /* Temporary until we resolve the blas include issue */
-void dcopy(int,double*,int,double*,int);
+//void dcopy(int,double*,int,double*,int);
 //
 using namespace mspass;
 namespace mspass{

This is just an issue created with a wrong blas interface. We should now use the misc/blas.h header to properly call those BLAS and LAPACK functions. After having that addressed, the error turns into:
>>> import ccore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /tmp/mspass/mspass/cxx/build/python/ccore.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN6mspass15sparse_convolveERKNS_14CoreTimeSeriesERKNS_14CoreSeismogramE

which is pretty much the same issue I mentioned earlier, I didn't get that fixed as I thought you have the modified code locally.

OK, I take that back. The last error is actually yet another bug... which can be fixed by:
diff --git a/cxx/src/lib/deconvolution/CMakeLists.txt b/cxx/src/lib/deconvolution/CMakeLists.txt
index 343d7ad..4982e28 100644
--- a/cxx/src/lib/deconvolution/CMakeLists.txt
+++ b/cxx/src/lib/deconvolution/CMakeLists.txt
@@ -6,6 +6,6 @@ include_directories(
   ${PROJECT_SOURCE_DIR}/include)

 add_library(deconvolution STATIC ${sources_deconvolution})
-target_link_libraries(deconvolution PRIVATE seismic utility ${BLAS_LIBRARIES} ${LAPACK_LIBRARIES} ${GSL_LIBRARIES} )
+target_link_libraries(deconvolution PRIVATE seismic utility algorithms ${BLAS_LIBRARIES} ${LAPACK_LIBRARIES} ${GSL_LIBRARIES} )

It is because the libdeconvolution is dependent on libalgorithms, and it is not linked at all. Bad news is, after fixing that, the errors turns into:
>>> import ccore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: generic_type: type "CNR3CDecon" referenced unknown base type "mspass::Base3CDecon"

Thank you for digging into this so quickly.   It is late and I would mess this up if I tried working on it now, but I can see exactly what is wrong creating your last error.   I messed up the wrapper for that new CNR3CDecon operator.   It relates to the obnoxious thing pybind11 requires they call a trampoline class.  As I understand it a trampoline class is required to get polymorphic classes to behave as they should.   Anyway, I can see I missed a step.   Hopefully I can make some progress this way.  Thanks again.

Well, problem mostly solved, but there is a residual problem I'll describe after documenting what I found and had to do.
The main issue that created the last problem you noted was something I honestly didn't completely solve.   There is some kind of oddity with multiple inheritance in pybind11 that I could not resolve to get the wrappers for the new CNR3CDecon operator to build.   I kept getting errors about ambiguous overloads, which seem to be traced to this construct:
class CNR3CDecon : public FFTDeconOperator, public Base3CDecon

I have lots of similar constructs, but this one kept generating this kind of error:
/N/u/pavlis/Carbonate/src/mspass/cxx/build/pybind11/include/pybind11/pybind11.h: In instantiation of 'Return (Derived::* pybind11::method_adaptor(Return (Class::*)(Args ...)))(Args ...) [with Derived = mspass::Base3CDecon; Return = mspass::Metadata; Class = mspass::CNR3CDecon; Args = {}]':
/N/u/pavlis/Carbonate/src/mspass/cxx/build/pybind11/include/pybind11/pybind11.h:1111:45:   required from 'pybind11::class_<type_, options>& pybind11::class_<type_, options>::def(const char*, Func&&, const Extra& ...) [with Func = mspass::Metadata (mspass::CNR3CDecon::*)(); Extra = {char [56]}; type_ = mspass::Base3CDecon; options = {PyBase3CDecon}]'
/N/u/pavlis/Carbonate/src/mspass/cxx/python/mspass_wrapper.cpp:893:108:   required from here
/N/u/pavlis/Carbonate/src/mspass/cxx/build/pybind11/include/pybind11/pybind11.h:1025:66: error: static assertion failed: Cannot bind an inaccessible base class method; use a lambda definition instead
 1025 |     static_assert(detail::is_accessible_base_of<Class, Derived>::value,
      |                                                                  ^~~~~
/N/u/pavlis/Carbonate/src/mspass/cxx/build/pybind11/include/pybind11/pybind11.h:1027:12: error: cannot convert 'mspass::Metadata (mspass::CNR3CDecon::*)()' to 'mspass::Metadata (mspass::Base3CDecon::*)()' in return
 1027 |     return pmf;

I decided that for this particular example polymorphism was not a high priority, so I dropped the Base3CDecon class completely.   If we need that capability later, we can deal with it then.
Now the residual problem.   There is clearly a configuration  difference in linux relative to macos related to a problem you and I know well from previous experience:  the traditional unix linker (ld) does not look at a library twice.   That is, if you need somthing like the math library it is common to see constructs like this:
g++ blah blah -lm -lseispp -lglcgrid -lm

The residual issue, I think, is related to yaml as I continue to get the same error noted above with node_data.   Any idea how to fix this?   The current version of add_deconvolution should generate the same error for you on carbonate or, I hypothesize, any linux implementation

Hmmm - not a linux issue.  When I tried the revision on my ubuntu test machine that problem does not appear.   Must be some peculiarity of the known but mysterious oddities of the way carbonate is configured.   My next development steps are all going to be done outside carbonate unless I run into something that requires totalview so this has gone to a very low priority.

I would like to ask your help on something I think you may be able to solve more easily than me beating my head against the wall on something I only marginally understand.  It fits this thread because it is the latest problem with what I think is a yaml library linking problem.   I base that on this error I get trying to run a test python script on carbonate:
[pavlis@i7 tests]$ python testcnr3c.py
Traceback (most recent call last):
  File "testcnr3c.py", line 16, in <module>
    from mspasspy.ccore import AntelopePf
ImportError: /geode2/home/u070/pavlis/Carbonate/src/mspass/python/mspasspy/ccore.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN4YAML6detail9node_data10set_scalarERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

Searching for "node_data" and I find a node_data.h file in the yaml library code.   Now that name may not be that unique so consider that only a hypothesis.   I had the same observation earlier in this thread.  The error is thrown when executing import AntelopePf, which references MetadataDefinitions that depends on yaml, so they hypothesis is probably correct.
I  do not get this error on my ubuntu machine.   I was pushing the testing to carbonate, however, because the algorithm being tested in this script (CNR3CDecon) is aborting with a memory corruption error.   I wanted to try to solve this issue with totalview as I have no tools on that machine I know how to solve that kind of problem.   It almost certainly means the program has some stray pointer away from the point that is actually aborting.  Totalview's memory debugger is pretty good at finding that kind of thing, although debugging a routine behind a python wrapper is adventure land.
I'm rambling.  What I'd like to ask you to do is pull the add_deconvolution branch on carbonate and build it.  You will need to manually (cp) install the ccore components in python/mspasspy unless you know how to install it more properly (if so please educate me).   Then cd to python/tests.   Again unless you know how to do this more properly edit the sys.path.append line to point at your version of ccore and execute the same line that is throwing the error above (python testcnr3c.py).  What to do next depends upon what happens.  If you get the same thing I do perhaps you can figure out what is causing the problem.  If you don't get this tell me your modules configuration as that has proven to be an issue with carbonate previously.

hmmm.... I can't reproduce that error on Carbonate. To build the code, I used exactly the same modules I listed earlier:
[wangyinz@h1 python]$ module list
Currently Loaded Modulefiles:
  1) intel/19.0.5       4) git/2.13.0         7) python/3.6.8
  2) perl/5.24.1        5) core               8) boost/gnu/1.72.0
  3) quota/1.2          6) gcc/9.1.0          9) cmake/gnu/3.8.0

Then, the compile list is like:
cmake .. -DCMAKE_C_COMPILER=gcc  -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran -DBOOST_ROOT=/N/soft/rhel7/boost/gnu/1.72.0

After calling make, I did:
[wangyinz@h1 build]$ cd python/
[wangyinz@h1 python]$ ls
CMakeFiles  ccore.cpython-36m-x86_64-linux-gnu.so
Makefile    cmake_install.cmake
[wangyinz@h1 python]$ python3
Python 3.6.8 |Intel Corporation| (default, Apr 12 2019, 17:34:58)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux
Type "help", "copyright", "credits" or "license" for more information.
Intel(R) Distribution for Python is brought to you by Intel Corporation.
Please check out: https://software.intel.com/en-us/python-distribution
>>> from ccore import AntelopePf
>>> from ccore import MetadataDefinitions

As you can see, there is no error from those import lines.
I think I came across this node_data related error before when I was trying to debug it on Carbonate. It seems to be that CMake incorrectly found a  yaml-cpp package installed somewhere else instead of from the current build. I was able to fix that issue by removing any previous builds. Maybe that's something you could try. If not, probably we will need to schedule a call to resolve this.

Well, that did it, but I don't know which of two things did it.  I was using a different cmake line but I also removed the build directory before running cmake.  I should have tried the later before - something that seems necessary sometimes.   Thanks for looking into this.

Would you please send me the .modules file you currently have on carbonate?   I'm now getting a weird collision with intel libraries where I think the python interpreter is incorrectly loading some needed library built with an incompatible library.
One more example of how helpful using a container will be for any user who isn't a developer.

Well, I don't really have one other than whatever the default is. I've been manually loading those modules when debug the issues above. What is that collision? Maybe I can try to reproduce it on my end.

I was not sure where I should insert this comment, but decided I'd put it here only because I encountered the problem trying to get some deconvolution python scripts I had running before the API changes.   It is actually a more generic problem with the python-C++ interfacing so could have put this lots of places.
Anyway, the version of ccore created by the current form of the branch add_deconvolution throws this error if you try to import ccore:
import mspasspy.ccore
Traceback (most recent call last):

  File "<ipython-input-2-d5eddcccb42f>", line 1, in <module>
    import mspasspy.ccore

ImportError: /home/pavlis/src/mspass/python/mspasspy/ccore.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN6mspass10WindowDataERKNS_10TimeSeriesERKNS_10TimeWindowE

I am pretty sure that is referencing this function:
CoreTimeSeries WindowData(const CoreTimeSeries& parent, const TimeWindow& tw);

defined in the pybind11 wrappers like this:
m.def("WindowData",&mspass::WindowData,"Reduce data to window inside original",
    py::return_value_policy::copy,
    py::arg("d"),
    py::arg("twin") )
  ;

I cannot understand why that is an undefined symbol?   Any ideas on how to sort this out?   It suggests the .so file is not properly built, but that is only a hypothesis.

Undefined symbol is usually something missing in the linking stage, but we have also encountered it before with inconsistent headers and implementations. Probably latter is more likely.

Well, if you look at the message, it says _ZN6mspass10WindowDataERKNS_10TimeSeriesERKNS_10TimeWindowE, which should correspond to a signature more like WindowData(TimeSeries& parent, TimeWindow& tw), but you referred a function with CoreTimeSeries. Maybe that is the inconsistency?

Thanks, I realized both of the above.   I have been trying to find any inconsistency and haven't been able to see any.   It is quite mysterious.  Tried commenting out the wrappers for WindowData and CNR3CDecon (which is only class presently defined in the wrappers that uses WindowData) and I still get the same error when it seg faults.
I did try this and it give us more data:
pavlis-home-linux:~/src/mspass/cxx/build/python> ldd -r ccore.cpython-36m-x86_64-linux-gnu.so
	linux-vdso.so.1 (0x00007ffdee1fb000)
	libboost_serialization.so.1.71.0 => /home/pavlis/src/mspass/cxx/build/boost/lib/libboost_serialization.so.1.71.0 (0x00007f2cb74f8000)
	libpython3.6m.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0 (0x00007f2cb6e48000)
	liblapack.so.3 => /usr/lib/x86_64-linux-gnu/liblapack.so.3 (0x00007f2cb65a8000)
	libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f2cb6338000)
	libgsl.so.23 => /usr/lib/x86_64-linux-gnu/libgsl.so.23 (0x00007f2cb5ed0000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2cb5b40000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2cb57a0000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2cb5588000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2cb5190000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2cb4f70000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f2cb4d38000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2cb4b18000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2cb4910000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f2cb4708000)
	libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f2cb4328000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2cb86c8000)
	libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f2cb40e8000)
undefined symbol: _ZN6mspass10WindowDataERKNS_10TimeSeriesERKNS_10TimeWindowE	(./ccore.cpython-36m-x86_64-linux-gnu.so)

I think the way this output works is  that the first lines are the standard output of ldd pointed at an so file.  The last line shows this symbol is not defined in the library for some reason.  That is mysterious because it most certainly is compiled (I can see that happen running cmake/make) and I can see the .o file in build:
pavlis-home-linux:~/src/mspass/cxx/build> ar -t src/lib/algorithms/libalgorithms.a
agc.o
seismogram_helpers.o
slice_and_dice.o
sparse_convolve.o
tseries_helpers.o

noting WindowData is in slice_and_dice.o.   I don't know where else to look.  Really stumped with this one.
Before wasting your time on this, let me try building it with clang and on carbonate.  Maybe one of them will turn up a difference we can use to diagnose this.

Well, I got exactly the same error with clang and a fresh copy on quakes (now rebuilt).  Got into the usual confusing compilations and stopped trying with carbonate as I don't expect a different answer there, only confusion with the complicated configuration issues there.
The quakes experiment does allow me to rule one thing out.  For some reason on my ubuntu machine here at home I have the link problem with boost I was patching with LD_LIBRARY_PATH.  That wasn't necessary on quakes, so I don' t think that is the issue.  I am out of ideas for now.   If you can think of anything please pass it along.

Let me give it a try. Is the add_deconvolution branch in sync?

I guess it is not the latest as I had to fix a pybind11 include path to get it to compile. Anyway, I just fixed the problem and committed it. Turns out it is exactly the WindowData defined in algorithm.h being inconsistent with the implementations.

Well, just to clarity, the problem is not in the pybind11 wrapper but really in the C++ code. So basically, if you write a test code that uses that problematic WindowData call will lead to the same error. I think when python imports the library, it will check whether all symbols imported are defined and that's how the error got triggered. That's why commenting out the related wrapper code does not help.

Well, I don't understand how I missed that.   I think this an example of how poor we humans are at seeing subtle differences in something.  Reminds me of an email I saw years ago where text was written with large numbers of words missing in a way that a native english speaker had difficulty even seeing the omissions.   Like many compiler errors I stared at for absurdly long and failed to see.  This one is especially glaring because I know for sure I cross checked that very thing 3 or 4 times and every time I was blind to the mistake.  Weird.
Thanks for finding that for me.  Why sometimes punting to someone else can help.  I owe you one

I saw you checked in a number of things.  Wonder if you caught this one with the pybind11 wrappers.  ProcessingHistory contains the ErrorLogger class referenced with the symbol elog.  I missed putting that in the wrappers.  Seems I should probably merge add_deconvolution into what you are doing to avoid collisions.   How should I proceed?

Yeah, it is always a good idea to have someone else to take a look.
I already merged API branch to master. You should be able to rebase the decon branch with master to get those fix.

Am working on a set of pure python wrappers for your scalar deconvolution code (as adapted by me to mspass).  I wanted to put part of this into the record as I think it is a model for how most processing algorithms should be built.   The issue in a parallel environment we want to guarantee is to reduce overhead in initiation of a process.   For the deconvolution code I am doing that by defining this class:
class RFdeconProcessor:
    def __init__(self,alg="LeastSquares",pf="RFdeconProcessor.pf"):
        self.algorithm=alg
        self.pfhandle=mspass.AntelopePf(pf)
        if(self.algorithm=="LeastSquares"):
            md=self.pfhandle.get_branch('LeastSquare')
            self.processor=mspass.LeastSquareDecon(md)
        elif(alg=="WaterLevel"):
            md=self.pfhandle.get_branch('WaterLevel')
            self.processor=mspass.WaterLevelDecon(md)
        elif(alg=="MultiTaperXcor"):
            md=self.pfhandle.get_branch('MultiTaperXcor')
            self.processor=mspass.MultiTaperXcorDecon(md)
        elif(alg=="MultiTaperSpecDiv"):
            md=self.pfhandle.get_branch('MultiTaperSpecDiv')
            self.processor=mspass.MultiTaperSpecDivDecon(md)
        elif(alg="GeneralizedIterative"):
            raise RuntimeError("Generalized Iterative method not yet supported")
        else:
            raise RuntimeError("Illegal value for alg="+alg)
    def loaddata(d,type="Seismogram",window=False):
    def loadnoise(n,type="Seismogram",component=2,window=False):
    def loadwavelet(w,type="Seismogram",component=2,window=False):
    def apply():
    def actual_output():
    def ideal_output():
    def inverse_filter():
    def QCMetrics():
    def change_parameters(md)

As you see the only thing I implemented yet is the constructor, but it is useful to show the idea for a polymorphic entity C++ processor.   All it does is define self.processor with the proper C++ constructor and it all should work (at least the books say so).  The method are little more than calls to the virtual methods defined in the base class for the supported operators.
The point is a job doing deconvolution should create one of these as a global thing to avoid the overhead of creation in a spark map call.  The map operation would then call this function:
def RFdecon(processor,d,wavelet=None,noisedata=None,wcomp=2):

Noting the processor is the global instance of RFdeconProcessor.   RFdecon would return a Seismogram object with the deconvolved data and actual output in component wcomp.   The function documentation states (written but not pasted in above) the user should call methods like actual_output, ideal_output, etc. after RFdecon returns successfully if those entities are needed. Also note the QCMetrics method will ALWAYS be called before return and the attributes it computes pushed to the output headers (Metadata).
I reiterate that I'm putting this in the record as a model for how to wrap C/C++ code to implement a map or a reduce algorithm.   With few exceptions setting up any processing algorithm has an overhead that cannot be neglected.   The model of defining the processor as a class and using that class as a required argument for map and reduce algorithms is what we need to stress to users.   I think we can and should use this implementation as a model for that concept.


Allow Json.Deserialize CamelCasing for Fields (ala Properties)

I created a forum post for this as well at https://forums.bridge.net/forum/community/help/4128-bridge-16-0-question-json-deserialize-camelcasing-for-fields - apologies if that's redundant, wasn't sure which is actively monitored / checked.
When we call Json.Deserialize I see that there is an option in JsonSettings for properties to be deserialized from the previous camelCasing style (lowercase for very first letter via CamelCasePropertyNames). However looking at the code I see that this is only checked for properties, and that fields are always deserialized under the assumption that they will use the exact casing of the class.
Our data that we deserialize has previously been direct-to-fields, and while we were able to convert all of those data classes to properties to get our codebase working in 16.0-beta, we see a performance hit from the property getter overhead (cfg.get) and it seems like it would be ideal to leave these as fields since are they pure data and the property overhead is unnecessary...
Is there a reason that we are only allowed to specify CamelCase for properties and not similarly for fields? Any chance of us getting that capability before 16.0 goes to final production build?
Thanks in advance!

Hi @cojo,
Welcome to Bridge.NET!
Thanks for informing us of this issue. We'll do some investigation, but I'm going to consider this a defect. We will try to fix right away.
You have perfect timing in reporting this issue as we're just about to do some other work related to Bridge.Json, so we'll batch it all together.

Awesome news, thanks guys!

The existing CamelCasePropertyNames will also control field behavior:
https://deck.net/31297b03c5a69804cddc122354edf06d
public class Program
{
    public static void Main()
    {
        var c = new Data { Field1 = 1, field2 = 2 };

        // CamelCasePropertyNames option
 		var json = Bridge.Json.Serialize(
            c,
            new JsonSettings { CamelCasePropertyNames = true });

        Console.WriteLine(json);

        var deserialized = Bridge.Json.Deserialize<Data>(
            json,
            new JsonSettings { CamelCasePropertyNames = true });

        Console.WriteLine(deserialized);

        // With no CamelCasePropertyNames option
 		json = Bridge.Json.Serialize(
            c,
            new JsonSettings { CamelCasePropertyNames = true });

        Console.WriteLine(json);

        deserialized = Bridge.Json.Deserialize<Data>(
            json,
            new JsonSettings { CamelCasePropertyNames = true });

        Console.WriteLine(deserialized);
    }
}

[Reflectable]
public class Data
{
    public int Field1;
    public int field2;
}


feat(status): added ellipsis for overflow

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 84.453%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
9551

Relevant Lines:
10449

💛  - Coveralls


add project checks to all modules

checks for pyproject file only if init is called, otherwise for box project and pyproject.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 98.92%. Comparing base (aaab401) to head (6920adb).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #13      +/-   ##
==========================================
+ Coverage   98.77%   98.92%   +0.14%
==========================================
  Files          19       19
  Lines         818      835      +17
==========================================
+ Hits          808      826      +18
+ Misses         10        9       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Problem Connecting to Private IPFS Network - swarm.key

I have a private network running with go-ipfs using a private swarm.key. How do I utilize the same network/swarm.key using js-ipfs?

Hi! This is where we track bugs and features for the IPFS webui. The discuss forum is the best place for getting help, as it's more visible to the rest of the community who may have the same question.
I see you've found it! https://discuss.ipfs.io/t/js-ipfs-swarm-key-for-private-network/3849


Move Envoy to v4alpha

#10355 provides v4alpha protos in the API tree, but doesn't migrate Envoy internally to v4apha. We should do this, ideally by Q4. The main challenge here is to perform API boosting and update the shadow generation technique in #10355 to support creation of hidden_envoy_deprecated_* fields in v4alpha that stretch back to v2 (currently they only work back to v3 as of #10355).

The likely conclusion of https://github.com/envoyproxy/envoy/issues/10943 is that v4 will not happen for a long time, so closing this for now, we've already eliminated v4alpha generation.


How can I use the trained biLM model to compute the probability of a sentence?

Hello,
I have generated some sentences using the GAN model, and I have trained a biLM language model on human dialogues. Now I want to use the biLM model to compute the score (e.g. probability) of each generated sentence. How can I do that?

See bilm.training.test to compute the perplexity  / probability of the sentence.


Postgres deadlock on write

Checklist

[X] I have looked into the README and have not found a suitable solution or answer.
[X] I have looked into the documentation and have not found a suitable solution or answer.
[X] I have searched the issues and have not found a suitable solution or answer.
[X] I have upgraded to the latest version of OpenFGA and the issue still persists.
[X] I have searched the OpenFGA Community and have not found a suitable solution or answer.
[X] I agree to the terms within the OpenFGA Code of Conduct.

Description
While executing 2-3 Write calls per second, we're observing a consistent low rate of 4000 internal server errors from OpenFGA. The logs indicate this is a SQL Deadlock: "internal_error":"sql error: ERROR: deadlock detected (SQLSTATE 40P01)". There are only 2 other processes writing to OpenFGA but they are competing to write the same tuples.
We're running on AWS RDS, using the official container image.
Given the consistency of the error, I believe it is pathological in the sql_common implementation. I suspect adding a "SELETE FOR UPDATE" clause would resolve this deadlock, as the current implementation in-deterministically locks rows on update.
Technically this behavior isn't incorrect but requires the client to continue to retry (i.e. pessimistic). Rather, it'd be probably more ergonomic to block on the lock and execute afterwards.
Expectation
Multiple writers can issue Write requests without erroring.
Reproduction

openfga v1.5.4 running via docker
Run multiple writer go routines to create "Write" traffic at a rate of 2-3 RPS.
Observe 4000 error codes, SQL deadlock logs.

Store data
No response
OpenFGA version
v1.5.4
How are you running OpenFGA?
As a binary
What datastore are you using?
Postgres
OpenFGA Flags
N/A
Logs
SQL Logs
2024-07-12 21:10:10 UTC:<IP_ADDRESS>(62770):user@openfga:[12549]:ERROR: deadlock detected
2024-07-12 21:10:10 UTC:<IP_ADDRESS>(62770):user@openfga:[12549]:DETAIL: Process 12549 waits for ShareLock on transaction 19518924; blocked by process 6065.
Process 6065 waits for ShareLock on transaction 19518923; blocked by process 12549.
Process 12549: INSERT INTO tuple (store,object_type,object_id,relation,_user,user_type,condition_name,condition_context,ulid,inserted_at) VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,NOW())
Process 6065: INSERT INTO tuple (store,object_type,object_id,relation,_user,user_type,condition_name,condition_context,ulid,inserted_at) VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,NOW())
2024-07-12 21:10:10 UTC:<IP_ADDRESS>(62770):user@openfga:[12549]:HINT: See server log for query details.

Hey @ben-mays-cs, I took a quick look at this and unfortunately I cannot reproduce it with this script that tries to write the same tuple in three goroutines. I have OpenFGA running 1.5.4 on Docker.
package main

import (
	"context"
	"encoding/json"
	"fmt"
	"time"

	"github.com/oklog/ulid/v2"
	openfgaSdk "github.com/openfga/go-sdk"
	"github.com/openfga/language/pkg/go/transformer"
	"github.com/sourcegraph/conc"
)

func main() {
	configuration, err := openfgaSdk.NewConfiguration(openfgaSdk.Configuration{
		ApiUrl:  "http://localhost:8080",
		StoreId: "01J34JT27KCN6V9CEWJZ371JVZ",
	})
	if err != nil {
		panic(err)
	}
	apiClient := openfgaSdk.NewAPIClient(configuration)

	writeModel(apiClient)
	writeTuples(apiClient)
}

func writeModel(apiClient *openfgaSdk.APIClient) {
	dslString := `
model
  schema 1.1
type user
type doc
  relations
    define viewer: [user]
`
	jsonString := transformer.MustTransformDSLToJSON(dslString)

	var model openfgaSdk.AuthorizationModel
	err := json.Unmarshal([]byte(jsonString), &model)
	if err != nil {
		panic(err)
	}

	_, _, err = apiClient.OpenFgaApi.
		WriteAuthorizationModel(context.Background()).
		Body(openfgaSdk.WriteAuthorizationModelRequest{
			SchemaVersion:   "1.1",
			TypeDefinitions: model.TypeDefinitions,
			Conditions:      model.Conditions,
		}).
		Execute()
	if err != nil {
		panic(err)
	}
}

func writeTuples(apiClient *openfgaSdk.APIClient) {
	var wg conc.WaitGroup
	for i := 0; i < 1; i++ {
		ulidId := ulid.Make().String()
		wg.Go(func() {
			writeOneTuple(apiClient, ulidId)
		})
		wg.Go(func() {
			writeOneTuple(apiClient, ulidId)
		})
		wg.Go(func() {
			writeOneTuple(apiClient, ulidId)
		})
		time.Sleep(1 * time.Second)
	}
	wg.Wait()
}

func writeOneTuple(apiClient *openfgaSdk.APIClient, ulidId string) {
	writeResp, _, err := apiClient.OpenFgaApi.
		Write(context.Background()).
		Body(openfgaSdk.WriteRequest{
			Writes: &openfgaSdk.WriteRequestWrites{
				TupleKeys: []openfgaSdk.TupleKey{
					{
						User:     fmt.Sprintf("user:%s", ulidId),
						Relation: "viewer",
						Object:   "doc:1",
					},
				},
			},
		}).
		Execute()
	if err != nil {
		fmt.Println(err)
	} else {
		fmt.Println(writeResp)
	}
}

The server logs
{
  "grpc_service": "openfga.v1.OpenFGAService",
  "grpc_method": "Write",
  "grpc_type": "unary",
  "trace_id": "f8b89d0d9f9f38dd5c5e5de65aad929d",
  "user_agent": "openfga-sdk go/0.3.4",
  "raw_request": {
    "store_id": "01J34JT27KCN6V9CEWJZ571JVZ",
    "writes": {
      "tuple_keys": [
        {
          "user": "user:01J33MPGKARP8998R82TK3RZRQ",
          "relation": "viewer",
          "object": "doc:1",
          "condition": null
        }
      ]
    },
    "deletes": null,
    "authorization_model_id": ""
  },
  "raw_response": {
    "code": "write_failed_due_to_invalid_input",
    "message": "cannot write a tuple which already exists: user: 'user:01J33MPGKARP8998R82TK3RZRQ', relation: 'viewer', object: 'doc:1': invalid write input"
  },
  "peer.address": "<IP_ADDRESS>:48674",
  "request_id": "f8b89d0d9f9f38dd5c5e5de65aad929d",
  "store_id": "01J34JT27KCN6V9CEWJZ571JVZ",
  "authorization_model_id": "01J33MP5V02VC7JX2F1PEGVQF6",
  "grpc_code": 2017,
  "error": "rpc error: code = Code(2017) desc = cannot write a tuple which already exists: user: 'user:01J33MPGKARP8998R82TK3RZRQ', relation: 'viewer', object: 'doc:1': invalid write input"
}

Is this an accurate representation of what your setup looks like and what you are trying to do?

This is approximately the same! We're doing bulk inserts so I suspect the issue is related to interleaved duplicate tuples; i.e. given inputs like this
        [{
          "user": "user:1",
          "relation": "viewer",
          "object": "doc:1",
          "condition": null
        }, {
          "user": "user:2",
          "relation": "viewer",
          "object": "doc:1",
          "condition": null
        }, {
          "user": "user:3",
          "relation": "viewer",
          "object": "doc:1",
          "condition": null
        }]

Two processes are pulling the same work tiem from our Kafka brokers and then writing the tuples directly to OpenFGA. Notably, the ordering of tuples may matter here -- if it corresponds to the Postgres process locking the rows in an order that allows another process to get a partial lock.
I haven't tried to recreate in a test but imagine if you order the first write as 1,2,3 and the second write as 3,2,1; executing from separate postgres sessions to avoid any internal buffering; it may recreate the issue.

I wonder if this is related to https://github.com/openfga/openfga/issues/1771. We consistently see test failures for MySQL about a bad connection error.


Fixes reversed ASTAR_DIAGONAL west east movements

Great project by the way! Came across a minor bug when using ASTAR_DIAGONAL movement - the sprites are backwards for moving east and west.

thanks @johnhamm


python311Packages.cryptoparser: 0.12.2 -> 0.12.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.cryptoparser is: Security protocol parser and generator
meta.homepage for python311Packages.cryptoparser is: https://gitlab.com/coroner/cryptoparser
meta.changelog for python311Packages.cryptoparser is: https://gitlab.com/coroner/cryptoparser/-/blob/v0.12.3/CHANGELOG.md
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.12.3 with grep in /nix/store/f1wjk11igy8l9nhy12m037z51wnhhghj-python3.11-cryptoparser-0.12.3
found 0.12.3 in filename of file in /nix/store/f1wjk11igy8l9nhy12m037z51wnhhghj-python3.11-cryptoparser-0.12.3

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath
python311Packages.cryptolyzer
python311Packages.cryptoparser
python312Packages.cryptolyzer
python312Packages.cryptoparser

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/f1wjk11igy8l9nhy12m037z51wnhhghj-python3.11-cryptoparser-0.12.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python311Packages.cryptoparser https://github.com/r-ryantm/nixpkgs/archive/844594d20c1bcc6bec207f6c5ffaff1e7f6c066d.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/844594d20c1bcc6bec207f6c5ffaff1e7f6c066d#python311Packages.cryptoparser

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/f1wjk11igy8l9nhy12m037z51wnhhghj-python3.11-cryptoparser-0.12.3
ls -la /nix/store/f1wjk11igy8l9nhy12m037z51wnhhghj-python3.11-cryptoparser-0.12.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

8 packages built:

python311Packages.cryptolyzer
python311Packages.cryptolyzer.dist
python311Packages.cryptoparser
python311Packages.cryptoparser.dist
python312Packages.cryptolyzer
python312Packages.cryptolyzer.dist
python312Packages.cryptoparser
python312Packages.cryptoparser.dist

Maintainer pings
cc @Kranzes for testing.

Already on staging-next.


The win32 directory is missing.

The scintilla library needs the win32 directory,  otherwise the project solution will not be loaded correctly.

Added, thanks for noticing!


Fix build errors for new page

Pull Request Title
Fix build errors for new page
Description
There were some build errors in the deployment, which I fix here. I did not substantively adjust the content in any way.
A question: Would it be helpful for me to add an automation to test/dry-run this process for each pull request that is opened?
I see value in this: This way you could observe any issues before they land on the main branch, which is tied to the  production website 😊
Checklist

[x] I agree to the Code of Conduct.
[x] My contribution follows the project's coding style guidelines.

If we could introduce an automation for a try run before merging into main that would be fantastic and would make sure that we don't run into any unexpected issues. Would you be able to help with that?
Thanks so much!


Core2Text/Text2Core ignores sounds

Converting a core to text (and backwards), completely ignores engine/trusts sound effects.
PS: No idea if it's a bug or feature (AllSrv doesn't need sounds at all).
Imported from trac ticket #65,  created by pkk on 03-15-2010 at 08:24, last modified: 07-15-2010 at 06:50

future functionality was planned to support SOUNDDEF look ups so it can use file names in the csv as well as (less intuitive sounddef.ids)  As of now, sounds (ids) are completely unchecked.
Dump a core to text, copy over your artwork's sounddef.mdl and create a program which goes thru the CSV and reports and invalid (missing file) IDs?
Trac comment by anonymous on 03-15-2010 at 12:06

				if(colnum == 6)
					pPart->interiorSound = atoi(sdata.c_str());
				if(colnum == 7)
					pPart->exteriorSound = atoi(sdata.c_str());

this works, i was able to change the sound of the afterburner using text cores. albeit i had to use the id as explained above
Trac comment by Imago on 07-15-2010 at 06:50


Icon

Sorry, we forked this repo and I accidentally made a pull request back to the original master. Closed.


how do get into debug?

I tried pressing 7 I've beat all the songs and got a skins pets etc why can't I get into debug?

beat defeat 3 times 0/0 misses ghost tapping off

I tried pressing 7 I've beat all the songs and got a skins pets etc why can't I get into debug?

They disabled it for some reason
If you want to get it you'll have to compile it yourself and change some of the code

yea they disabled it but they forgot to disable the Character Editor

add a  -debug code to enable a debug build this will allow you to get into debug

I tried pressing 7 I've beat all the songs and got a skins pets etc why can't I get into debug?

They disabled it for some reason If you want to get it you'll have to compile it yourself and change some of the code

they disabled it because people were going to rechart the songs to make it easier.

they did it cause they didnt want people cheating ig

beat defeat 3 times 0/0 misses ghost tapping off

is that true?

beat defeat 3 times 0/0 misses ghost tapping off

is that true?

no lol


[oneDNN] Add oneDNN version of SparseMatrixMatMul

Adds _MklNativeSparseMatrixMatMul and its accompanying kernel, which uses oneDNN to multiply a CSR sparse matrix by a dense tensor. The op is enabled with an environment variable (TF_ENABLE_ONEDNN_SPMM), so is entirely opt-in. It also includes tests and a benchmark, which we've used below to measure its performance against the existing kernel.
The performance looks promising particularly for larger shapes, and is optimized to use the AVX2 and AVX512 ISAs. These results were collected using the new benchmark in tensorflow/core/kernels/mkl/mkl_sparse_matrix_matmul_op_benchmark.cc on an Intel Xeon Platinum 8480 with hyperthreading enabled. To minimize NUMA effects, we bound it to the first socket.

Configuration (NNZ_M_K_N)
Eigen Time (ns)
oneDNN Time (ns)
Ratio

128_8_512_1
15300
18598
0.82

128_16_512_1
14778
18551
0.80

128_128_512_1
18613
19165
0.97

128_4096_4096_1
151525
35904
4.22

1024_4096_4096_1
161593
37041
4.36

16384_4096_4096_1
163055
49355
3.30

128_8_1024_16
17307
18420
0.94

128_16_1024_16
17765
18678
0.95

128_128_1024_16
19247
19200
1.00

128_4096_4096_128
160341
140894
1.14

128_4096_4096_1024
181590
156980
1.16

1024_8_1024_16
24265
19502
1.24

1024_16_1024_16
24223
20448
1.18

1024_128_1024_16
26013
20396
1.28

1024_4096_4096_128
157612
139688
1.13

1024_4096_4096_1024
177549
160973
1.10

16384_8_1024_16
153005
36643
4.18

16384_16_1024_16
152853
36597
4.18

16384_128_1024_16
153600
31928
4.81

16384_4096_4096_128
166061
142494
1.17

16384_4096_4096_1024
244243
194536
1.26

16384_4096_4096_4096
654950
536546
1.22

100_1_1000000_100
18230
19991
0.91

200_1_2000000_100
20509
20818
0.99

400_1_4000000_100
23023
21638
1.06

400_4_1000000_100
22164
21349
1.04

800_4_2000000_100
26180
23374
1.12

1600_4_4000000_100
40538
28622
1.42

800_8_1000000_100
27015
23231
1.16

1600_8_2000000_100
39953
27894
1.43

3200_8_4000000_100
77708
42709
1.82

Nice

cool

Could you please help make more changes? There are some more errors.

Sure. Sorry, didn't see those errors in my local tests, and I didn't see which target in the CI threw those errors.

I think I've made all of the appropriate changes; @cantonios @penpornk does this look OK to you?

@cantonios Made that change, and I think the current "Presubmit" test failure is unrelated to this PR.

@cantonios I can see that some internal checks failed, but can't see what they are.

@cantonios I can see that some internal checks failed, but can't see what they are.

ERROR: tensorflow/core/kernels/mkl/BUILD:104:22: in cc_library rule //tensorflow/core/kernels/mkl:mkl_sparse_matrix_matmul_op: Visibility error:
target '//tensorflow/core/kernels/sparse:mat_mul_op.h' is not visible from
target '//tensorflow/core/kernels/mkl:mkl_sparse_matrix_matmul_op'

@cantonios I can see that some internal checks failed, but can't see what they are.

ERROR: tensorflow/core/kernels/mkl/BUILD:104:22: in cc_library rule //tensorflow/core/kernels/mkl:mkl_sparse_matrix_matmul_op: Visibility error:
target '//tensorflow/core/kernels/sparse:mat_mul_op.h' is not visible from
target '//tensorflow/core/kernels/mkl:mkl_sparse_matrix_matmul_op'

Is it possible to get a commandline reproducer for this error? Can't reproduce locally, so fixing it might be trial-and-error that spams this PR with commits and spams you with emails!

@cantonios I can see that some internal checks failed, but can't see what they are.

ERROR: tensorflow/core/kernels/mkl/BUILD:104:22: in cc_library rule //tensorflow/core/kernels/mkl:mkl_sparse_matrix_matmul_op: Visibility error:
target '//tensorflow/core/kernels/sparse:mat_mul_op.h' is not visible from
target '//tensorflow/core/kernels/mkl:mkl_sparse_matrix_matmul_op'

Is it possible to get a commandline reproducer for this error? Can't reproduce locally, so fixing it might be trial-and-error that spams this PR with commits and spams you with emails!

I'm not sure... I'm surprised bazel doesn't find the dependency issue.  Maybe Google's internal tooling is more strict?

@cantonios I can see that some internal checks failed, but can't see what they are.

ERROR: tensorflow/core/kernels/mkl/BUILD:104:22: in cc_library rule //tensorflow/core/kernels/mkl:mkl_sparse_matrix_matmul_op: Visibility error:
target '//tensorflow/core/kernels/sparse:mat_mul_op.h' is not visible from
target '//tensorflow/core/kernels/mkl:mkl_sparse_matrix_matmul_op'

Is it possible to get a commandline reproducer for this error? Can't reproduce locally, so fixing it might be trial-and-error that spams this PR with commits and spams you with emails!

I'm not sure... I'm surprised bazel doesn't find the dependency issue. Maybe Google's internal tooling is more strict?

All right, trying some things. Thank you for your reviews, by the way!

Thank you! Sorry for so many change requests! (It's from our internal checks.)

Hey, I get it -- totally fine! Thanks for bearing with me while I made them.

Any update on this? Is the next step in the process for @qqfish to review? Looks like the Copybara checks are passing now.

Any update on this? Is the next step in the process for @qqfish to review? Looks like the Copybara checks are passing now.

It's going through the internal battery of tests now.

Any update on this? Is the next step in the process for @qqfish to review? Looks like the Copybara checks are passing now.

It's going through the internal battery of tests now.

Oh, nice, sounds good.

Unfortunately I had to rollback this PR since it broke a oneDNN build on arm64. The error was:
In file included from tensorflow/core/kernels/mkl/mkl_einsum_op.cc:19:
In file included from tensorflow/core/kernels/mkl/mkl_batch_matmul_helper.h:25:
./tensorflow/core/kernels/mkl/mkl_matmul_ops_common.h:927:38: error: no member named 'csr' in 'dnnl::memory::desc'
  927 |       const auto tmp = memory::desc::csr(
      |                        ~~~~~~~~~~~~~~^

@matthew-olson-intel, can you create a new PR with this issue fixed?

@reedwm Sure. The new PR is in #63030.


Emote Inserting Error

It seems to be trying to insert a  image but seems to be sticking it into the middle of the message. I have seen this a couple times.

Thanks for the report. I did some changes to the function that does all the emote and link magic. If you could test the rewrite-emote-magic branch, that would be great.

Yep, seems to be fixed.


Intermittent failures at render time (cannot read property 'tags' of undefined

Hi, sorry for filing all the tickets. I'm really just playing around and stress testing it a bit 😄

More than once I've run into the following stacktrace while switching to preview:
2index.html:9045 Uncaught (in promise) TypeError: Cannot read property 'tags' of undefined
    at TagIndex.eval (eval at <anonymous> (app.js:1), <anonymous>:9045:31)
    at step (eval at <anonymous> (app.js:1), <anonymous>:68:23)
    at Object.eval [as next] (eval at <anonymous> (app.js:1), <anonymous>:49:53)
    at eval (eval at <anonymous> (app.js:1), <anonymous>:42:71)
    at new Promise (<anonymous>)
    at __awaiter (eval at <anonymous> (app.js:1), <anonymous>:38:12)
    at TagIndex.reloadFile (eval at <anonymous> (app.js:1), <anonymous>:9038:16)
    at eval (eval at <anonymous> (app.js:1), <anonymous>:8860:90)
    at step (eval at <anonymous> (app.js:1), <anonymous>:68:23)
    at Object.eval [as next] (eval at <anonymous> (app.js:1), <anonymous>:49:53)

Most recently it was while building the following dataview (not sure if it's related though):
task from ""
where file.day
sort file.day desc

Interesting. Looks like some files have no metadata in the Obsidian cache, so need to add a null check. Probably worth revisiting my index code and add some extra null safety pre-emptively. Will be fixed in 0.1.6.

I believe I've fixed most of these; it was an issue with how I parsed tags (I did it in different ways when a page was first indexed, and when it was later re-indexed due to a changed).


cmake: modules: add support for board extensions

Board extensions are board fragments that may be present in any board root folder, under ${BOARD_ROOT}/extensions/${BOARD}. The board extension directory may contain Kconfig fragments and/or devicetree overlays.  Board extensions are automatically loaded and applied on top of board files, before anything else. There is no guarantee on which order extensions are applied, in case multiple exist.
Board extensions may be useful in the context of Zephyr modules, such as example-application. In some situations, certain hardware description or choices can not be added in the upstream Zephyr context, but they do in a downstream project, where custom bindings or driver classes can also be created. This feature may also be useful in development phases, when the board skeleton lives upstream, but other board features are not yet present.
Fixes #49940

@tejlmand The main reason for this change is that there's no way to extend a board downstream. And sometimes this is needed, for example, if you have drivers for the board that are not upstream. Overlays are not always the option because they are, for example, applied later than shields, which can depend on DT nodes defined at board level. We currently have no solution for this, as detailed in https://github.com/zephyrproject-rtos/zephyr/issues/49940.

@tejlmand could you provide some guidance here? I was thinking to add a new optional key to module.yaml, so that a module can explicitly enable board extensions. Only in that case, they'd be used.

@tejlmand The main reason for this change is that there's no way to extend a board downstream.

I fully understand, and I completely agree that we need a functionality like this.
But as soon as we have such functionality, then we must also be prepared that multiple modules starts using this feature.
Imagine both https://github.com/teslabs/spinner and another project like NCS extending a board.
They both become part of same highlevel project, but their extensions are in conflict, then how to handle ?
One option could be to limit the board extension to only be active inside the module who defines it, but then what about a project which might like this to be active on all projects because it offers the use of another / better RNG.
And what about derived projects where you actual want the extension to also be active.
While at the same time there could be samples where you might actually not want such board extension to kick in.
A lot of open questions, which is also why I take careful steps atm.

From discussion, the following has been decided:

Provide a clear mechanism to opt-out of board extensions

must be possible to opt-out each Zephyr module board extension individually or all
the opt-out must be able to handle both devicetree and Kconfig, thus a CMake variable seems the best option.

Clear guidelines in Zephyr docs that this feature is intended for downstream users

No Zephyr hosted project are allowed to use the board extension feature, all adjustments to boards must be done in board folder in Zephyr repo.

@tejlmand please check latest revision

I've only scanned all the comments here, but has it been considered that the board extension is referenced through a new name? i.e. nrf52840dk_nrf52840 could be extended in your repo as teslabs_nrf52840dk, which pulls in the original board and applies the extensions as this PR currently does.
IMO this would solve the concerns around modules breaking upstream boards, while still retaining the advantages of reducing copy-paste.

Good point, I'll look into that, even though I wanted a simple solution.


support noTimestamp and noVersionStamp groovydoc flags

@eskatos Would you mind owning this pull request?

My pleasure @eljobe

Hi Paul,
I hope you're doing well.
As you already know, we want such changes to be described in a design document. Would you mind adding one? Maybe in a groovy-support.md file there.
Oh and by the way, I guess that the existing org.gradle.util.VersionNumber class could easily replace the Version class introduced in this pull-request.
Cheers

Hi Paul, I'm doing well. Good catch for Version. I changed that and added some doco. Let me know how that looks.
Cheers, Paul.

Excellent. I reviewed and tested the changes locally and they LGTM.
As the version of the Groovydoc that is used, is the one from the Groovy defined in the build script, I'd say the DSL doc of the associated task should mention that the two added properties work for Groovy >= 2.4.6 only. Let's merge, I'll do that on my side.
Cheers

Paul, thank you!
Your changes are now scheduled to be included in 2.13.
Cheers

Thanks Paul.


Accept options obj and pass to stateFromElement

This is a companion PR to https://github.com/sstur/draft-js-import-element/pull/3.
Support an options argument so user can pass options like custom elementStyles.

Thanks @coopy! I have pulled in the companion PR and bumped it's version on npm so I will likewise update the dependency here in package.json.


[Designer] Preserve page state upon refresh

I would love for the designer to preserve the page state on page refreshes. Currently you lose the card you are working on with no way to retrieve it.

thanks for the request, @mstniy -- @JeanRoca & @anna-dingler  FYI


Undefined symbols Carthage approach

[READ] Step 1: Are you in the right place?

For issues or feature requests related to the code in this repository
file a Github issue.

If this is a feature request make sure the issue title starts with "FR:".

For general technical questions, post a question on StackOverflow
with the firebase tag.
For general Firebase discussion, use the firebase-talk
google group.
For help troubleshooting your application that does not fall under one
of the above categories, reach out to the personalized
Firebase support channel.

[REQUIRED] Step 2: Describe your environment

Xcode version: 9.4.1
Firebase SDK version: 5.6.0
Firebase Component: _____ (Auth, Core, Database, Firestore, Messaging, Storage, etc)
Component version: _____

[REQUIRED] Step 3: Describe the problem
Having issues with building using Firebase with Carthage.

Steps to reproduce:
Output

Relevant Code:
Here is my Cartfile
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAuthBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseInvitesBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseFirestoreBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseCrashBinary.json"

Hi @aabanaag
MeasurementNanoPB.framework should be added to the included frameworks.

Thanks! But if there is a document stating which frameworks should be included might be great.


Update Store.md

Hotlinks fixed under Store Methods section.

@reyou I think your solution can fix the official website anchor but will break the anchor for github README.md, you can check https://github.com/reyou/redux/blob/patch-1/docs/api/Store.md

Yeah, in-page anchors seem to be broken as a result of the upgrade to the new Gitbook version (#2837 ).  We're waiting for an update to Gitbook that will fix those.


Increase the timeout to 60 Minutes

related to https://issues.redhat.com/browse/ISV-1711

Both changes look good to me.

@Mitulsharma123 @atiwary91 we have a duplicate pull request in https://github.com/redhat-openshift-ecosystem/operator-pipelines/pull/254. Please refer to the comments on the PR and close one of these.

Closing in favor of #256.


[DX] Exception error page improvements

In dev mode, stack traces displayed on the web have a nice template showing the exception message, http status code, exception class and a stack trace, along with a code excerp.
In many cases, I would posit most cases, the code excerp is in a vendor included library. This isn't usually because a problem with those packages, but because of code you did earlier in the trace.
Looking at a stack trace I had recently when I had a typo in an Entity name for doctrine, it is 21 items deep, and only 2 are in my application.
Unknown Entity namespace alias 'MyDatabaseBundle'.

in vendor/doctrine/orm/lib/Doctrine/ORM/ORMException.php at line 271   -
     */
    public static function unknownEntityNamespace($entityNamespaceAlias)
    {
        return new self(
            "Unknown Entity namespace alias '$entityNamespaceAlias'."
        );
    }
at ORMException ::unknownEntityNamespace ('MyDatabaseBundle')
in vendor/doctrine/orm/lib/Doctrine/ORM/Configuration.php at line 196   +
at Configuration ->getEntityNamespace ('MyDatabaseBundle')
in vendor/doctrine/orm/lib/Doctrine/ORM/Query/Parser.php at line 965   +
at Parser ->AbstractSchemaName ()
in vendor/doctrine/orm/lib/Doctrine/ORM/Query/Parser.php at line 1702   +
at Parser ->RangeVariableDeclaration ()
in vendor/doctrine/orm/lib/Doctrine/ORM/Query/Parser.php at line 1557   +
at Parser ->IdentificationVariableDeclaration ()
in vendor/doctrine/orm/lib/Doctrine/ORM/Query/Parser.php at line 1292   +
at Parser ->FromClause ()
in vendor/doctrine/orm/lib/Doctrine/ORM/Query/Parser.php at line 874   +
at Parser ->SelectStatement ()
in vendor/doctrine/orm/lib/Doctrine/ORM/Query/Parser.php at line 843   +
at Parser ->QueryLanguage ()
in vendor/doctrine/orm/lib/Doctrine/ORM/Query/Parser.php at line 268   +
at Parser ->getAST ()
in vendor/doctrine/orm/lib/Doctrine/ORM/Query/Parser.php at line 351   +
at Parser ->parse ()
in vendor/doctrine/orm/lib/Doctrine/ORM/Query.php at line 281   +
at Query ->_parse ()
in vendor/doctrine/orm/lib/Doctrine/ORM/Query.php at line 293   +
at Query ->_doExecute ()
in vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php at line 969   +
at AbstractQuery ->executeIgnoreQueryCache (null, '1')
in vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php at line 924   +
at AbstractQuery ->execute (null, '1')
in vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php at line 727   +
at AbstractQuery ->getResult ()
in src/AppBundle/Controller/AlarmController.php at line 85   +
at AlarmController ->indexAction (object(Request))
at call_user_func_array (array(object(AlarmController), 'indexAction'), array(object(Request)))
in vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php at line 148   +
at HttpKernel ->handleRaw (object(Request), '1')
in vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php at line 66   +
at HttpKernel ->handle (object(Request), '1', true)
in vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php at line 169   +
at Kernel ->handle (object(Request))
in web/app_dev.php at line 35   +

My suggestion is that instead we only display non-vendor code by default, and include a link at the bottom of the trace to "include vendor code" to show it. Don't need to renumber, just hide any items in vendors/. It would look like this:
Unknown Entity namespace alias 'MyDatabaseBundle'.

at AbstractQuery ->getResult ()
in src/AppBundle/Controller/AlarmController.php at line 85   -
            throw new \RuntimeException('invalid order filter: '.$order);
        }
        $query = $em->createQuery($dql);
        $results = $query->getResult();
        // set state
        $state = 'active';

at Kernel ->handle (object(Request))
in web/app_dev.php at line 35   +

This shows me the two items in my app, from where the app came in at app_dev, to where the error is, in AlarmController. It's true in this case because the $dql variable is a bit above, the excerp wasn't useful, but it often will.
This would make the exception page much more useful to people using the symfony standard edition, and make the errors much easier to understand.
In my opinion, an error that is hard to understand is a bug, and should be treated as such.

While we are talking about the exception page, how is the logs section useful?
INFO - Matched route "{route}".
DEBUG - Read existing security token from the session.
DEBUG - User was reloaded from a user provider.
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
CRITICAL - Uncaught PHP Exception Doctrine\ORM\ORMException: "Unknown Entity namespace alias 'MyDatabaseBundle'." at /opt/telephony/myapp/vendor/doctrine/orm/lib/Doctrine/ORM/ORMException.php line 271
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".
DEBUG - Notified event "{event}" to listener "{listener}".

Shouldn't the {route} {event} and {listener} lines show more useful information?

@ofbeaton I agree with your first feature request. Exceptions should focus first on your own code. Our intention is to redesign the exception pages soon to match the new Symfony style, so we'll try to make it more modern and more useful.

Regarding the second question, are those the entire log messages you get? For example, in the Symfony Demo with Symfony 3.1 I get these:
[2016-06-05 21:53:18] request.INFO: Matched route "{route}". {"route":"blog_post","route_parameters":{"_controller":"AppBundle\\Controller\\BlogController::postShowAction","_locale":"en","slug":"lorem-ipsum-dolor-sit-amet-consectetur-adipiscing-elit","_route":"blog_post"},"request_uri":"http://symfony-demo.dev/app_dev.php/en/blog/posts/lorem-ipsum-dolor-sit-amet-consectetur-adipiscing-elit","method":"GET"} []

[2016-06-05 21:53:18] security.INFO: Populated the TokenStorage with an anonymous Token. [] []

[2016-06-05 21:53:18] request.INFO: Matched route "{route}". {"route":"_wdt","route_parameters":{"_controller":"web_profiler.controller.profiler:toolbarAction","token":"3b3b9e","_route":"_wdt"},"request_uri":"http://symfony-demo.dev/app_dev.php/_wdt/3b3b9e","method":"GET"} []
[2016-06-05 21:53:18] security.INFO: Populated the TokenStorage with an anonymous Token. [] []

I see the same useless Matched route "{route}" thing ... but I also get the additional information after it.

@javiereguiluz yes I copy+pasted the entirety of the "logs" section found on the exception page. There is no additional informational as shown in your paste, which would indeed be the extra information I am missing. I am using Symfony 3.1 as well, displayed in Chrome using a nginx web server. Perhaps I have something misconfigured then?

@ofbeaton I'm not sure about the misconfiguration. This is the monolog config we're using in the config_dev of the demo app: https://github.com/javiereguiluz/symfony-demo/blob/eba83d9436addbb3fdef5244aa65a4ad56b01267/app/config/config_dev.yml#L20-L28

Yes, the {route} placeholder does not make any sense. That should be the route name. I guess that's a bug.

It changed again? I downloaded 3.1@dev on May 9th,
monolog:
    handlers:
        main:
            type:   stream
            path:   "%kernel.logs_dir%/%kernel.environment%.log"
            level:  debug
            channels: [!event]

        console:
            type:   console
            channels: [!event, !doctrine]

I'll re-download now and make the appropriate changes.
Anyways, {event} could be the event name, and {listener} could be the listener name too.

@ofbeaton I showed you the config of the Symfony Demo app. The Symfony Standard is a different thing. I only showed the config to you in case you can try it to see if you get different results :)
And yes, all the placeholders seem to be missing in log messages.

I'm :+1: on "hiding" the non-vendor code in exception pages as long as the full stack trace is available with a single "Hide/show" button.
For the logs part, it depends on your monolog config

I'm closing this issue because we'll take care about your first request and I've opened #981 to discuss about the second issue that you mentioned. Thanks!

Great to hear @javiereguiluz and very appreciated, though aren't tickets usually closed when the issue is actually resolved?

Should I open a new ticket just for the stack trace improvement then?

Since you broke out the 2nd issue into it's own ticket, I renamed the ticket to only reflect the first request. Can it be re-opened now?

@ofbeaton yes, let's reopen it. Thanks!

Closing as there is nothing specific to the standard edition. It should be moved to symfony/symfony insteas.

@ofbeaton The changes proposed in symfony/symfony#23144 may be of interest to you.


generate diagram as part of the cli

Would be indeed nice, anything specific in mind ? like e.g. simple barplots https://github.com/LAION-AI/CLIP_benchmark/blob/main/benchmark/results.ipynb?


[Documentation] The letter 'c' is omitted in the word 'description'

Documentation issues
Omission of Letter 'c' in the word 'description'
The letter 'c' is missing in the word 'description' in the sentence "Please delete the instructions below and replace with PR description".
Platform
No response
Anything else?

https://github.com/project-chip/connectedhomeip/blob/master/.github/PULL_REQUEST_TEMPLATE.md

Consider creating a PR to fix this, should be an easy fix.

Well noted Andy.
That will be my first pull request on an open source project.
I will let you know when I am done.
Thank you for giving me this opportunity.

Hello @andy31415
Done with the pull request.
It is opened yet to be closed.
Thank you.

Hello @andy31415,
I created a PR and now the issue is fixed and closed.
Thank you for the encouragement.


When I try to use with android v10, can't resolve reference Xamarin.Android.Support.Compat

I cant seem to determine what Xamarin.Android.Support.Compat nuget package to use to make it link without an error.

Most likely because Android X support isn't in there #123

@davefxy Do you get the same error if you replace Xamarin.Android.Support.Compat with Xamarin.Android.Support.v7.AppCompat v<IP_ADDRESS> ?
I'm using PancakeView v<IP_ADDRESS>4 alongside AndroidX with <TargetFrameworkVersion>v10.0</TargetFrameworkVersion> without any issues in my GitTrends app: https://github.com/brminnick/GitTrends/blob/94b4f836369ebbcc18867a41a494766cffaee8c6/GitTrends.Android/GitTrends.Android.csproj#L87-L108

That appears to solve the issue. Thank you.
Sent from Mail for Windows 10
From: Brandon Minnick
Sent: Thursday, September 24, 2020 11:46 AM
To: sthewissen/Xamarin.Forms.PancakeView
Cc: Davefxy; Mention
Subject: Re: [sthewissen/Xamarin.Forms.PancakeView] When I try to use withandroid v10, can't resolve reference Xamarin.Android.Support.Compat (#135)
@davefxy Do you get the same error if you replace Xamarin.Android.Support.Compat with Xamarin.Android.Support.v7.AppCompat v<IP_ADDRESS> ?
I'm using PancakeView v<IP_ADDRESS>4 alongside AndroidX with v10.0 without any issues in my GitTrends app: https://github.com/brminnick/GitTrends/blob/94b4f836369ebbcc18867a41a494766cffaee8c6/GitTrends.Android/GitTrends.Android.csproj#L87-L108
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Do give <IP_ADDRESS>2-beta a try @brminnick @davefxy :)

@sthewissen To close this Issue and resolve the Xamarin.Android.Support.Compat build error, could you release a NuGet package that is exactly the same as v<IP_ADDRESS>4 and only adds the dependency to Xamarin.Android.Support.v7.AppCompat?
Xamarin.Forms.PancakeView v<IP_ADDRESS>2-beta includes additional internal changes which has a regression causing my GitTrends app to crash. I'll open a reproduction sample demonstrating the crash in another Issue.

I'll happily remove the IBorderElement implementation, which is causing this. However, I've also recently removed some properties that were deprecated (and don't work anymore at this point). I feel like keeping these properties removed should not hurt.

Thanks for the work on the lib. Do you have an estimation on when the lib will move from beta to prod?

#145


python3Packages.latexify: init at 0.2.0

Description of changes

new package

Things done

Built on platform(s)

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

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

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Please add pytestCheckHook to checkInputs.

When I do so, I hit the following issue which I am unable to fix :-/

Try cd src in preCheck.

Try cd src in preCheck.

Thanks, that did the trick: added in 1cd546a22b6506156087e4b4d5bc2508223f72e2


fix(tests): do not send test GET requests with an HTTP request body

It's simply weird to send GET requests that have a Request Content-Type and a body. It also means if there is anything before the WAF that checks conformity of HTTP protocol the test could fail because of that.
Also, there are WAFs simply removing the HTTP body from GET requests, meaning if you run these tests against them, the test would always fail.

sure thing, I changed that


Add a workflow to publish to central

Description:
Currently jaeger module no longer packed with ballerina-distribution and we need a seperate workflow to publish jaeger to ballerina dev and stage centrals.
Suggested Labels:

Suggested Assignees:

Affected Product Version:
OS, DB, other environment details and versions:
Steps to reproduce:
Related Issues:

Need to add the following secrets to the repository
BALLERINA_CENTRAL_ACCESS_TOKEN
BALLERINA_CENTRAL_DEV_ACCESS_TOKEN
BALLERINA_CENTRAL_STAGE_ACCESS_TOKEN

Currently jaeger module doesn't have the option to give a gradle parameter to enable publish-to-central (e.g., In other repos, they have the option to give -PpublishToCentral=true). Usually when jaeger module is released, jaeger module will be published to ballerina-central since bal push command is included inside the release task in build.gradle. But we cannot push to dev-central or stage-central. We may need to add a separate task to push to ballerina-central when the publishToCentral parameter is given.


Kiota 1.5.1 fails to generate client (but 1.4.0 could)

Hi,
In July I did a spike to use Kiota v1.4.0 to generate a C# client for Firecracker micro-vm management API swagger definition
via
kiota generate -l CSharp -c FireClient -n Firecracker.Client -d "c:\temp\firecracker\firecracker.yaml" -o "c:\temp\firecracker\client"
and it worked, but generated the following warning:
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/MmdsConfig/properties/ipv4_address - The format 169.254.([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-4]).([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]) is not supported by Kiota for the type string and the string type will be used.

I've just upgraded to the latest version of Kiota (v1.5.1) and now the client fails to generate, with the following message:
warn: Kiota.Builder.KiotaBuilder[0]
      OpenAPI warning: #/components/schemas/MmdsConfig/properties/ipv4_address - The format 169.254.([1-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-4]).([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]) is not supported by Kiota for the type string and the string type will be used.
crit: Kiota.Builder.KiotaBuilder[0]
      error generating the client: The element FirecrackerVersion could not be found in the class FirecrackerVersion

Thanks for your interest in kiota and for reporting this.
It seems the regression introduced with 1.5.1 is already fixed by the upcoming 1.6.0.
Please go ahead and try with the preview version dotnet tool update -g Microsoft.OpenApi.Kiota --prerelease
Also the URL of the description (to use as argument is) https://raw.githubusercontent.com/firecracker-microvm/firecracker/main/src/api_server/swagger/firecracker.yaml

Perfect! Can confirm it works again with 1.6.0-preview.202308240001

OK - If I generate the client, using the following command:
kiota generate -l CSharp -c FirecrackerManagementClient -n Firecracker.Management -d https://raw.githubusercontent.com/firecracker-microvm/firecracker/main/src/api_server/swagger/firecracker.yaml -o "c:\temp\firecracker\client"

I get the following issues:
Firecracker.Management.Models.MachineConfiguration has a compile error on line 29:
CpuTemplate = CpuTemplate.None;
As the enum type is not properly referenced, because the correct namespace / alias is missing.
Firecracker.Management.FirecrackerManagementClient has a missing using statement using Microsoft.Kiota.Serialization.Multipart; - I'm not sure if we're missing a matching preview nuget package. Which leads to a missing type (`MultipartSerializationWriterFactory) on line 104:
`ApiClientBuilder.RegisterDefaultSerializer();
I have the following nuget packages installed:
<PackageReference Include="Microsoft.Kiota.Abstractions" Version="1.3.1" />
<PackageReference Include="Microsoft.Kiota.Http.HttpClientLibrary" Version="1.1.1" />
<PackageReference Include="Microsoft.Kiota.Serialization.Form" Version="1.0.1" />
<PackageReference Include="Microsoft.Kiota.Serialization.Json" Version="1.0.8" />
<PackageReference Include="Microsoft.Kiota.Serialization.Text" Version="1.0.3" />

Thanks for the additional information. Have you tried to run kiota info -l CSharp to know which dependencies you should be installing?
The enum thing is a bit more concerning. Can you check whether #3228 sounds like the same issue and provide the additional details there please? Otherwise please go ahead an create another issue so we can keep things focused.

Thanks! If I had my reading glasses on, I would have seen the HINT recommending running that command - although from a UX perspective I don't understand:
a) why we don't get a .csproj file with all the required packages
b) why the required packages aren't just included in the output message rather than the hint
Although this scenario was a bit of a gotcha as the Microsoft.Kiota.Serialization.Multipart package was a new dependency, as I re-generated into a project I created with v1.4.0
Enum - I think it's a different problem than #3228 and I'll raise another issue.

Done: #3233

Not touching the project files is a design decision. Projects are structured in really different ways, there can be multiple project management tech for any language (e.g. gradle and maven for java), lots of project management tech don't have a CLI or object model to edit dependencies (gradle or maven), versioning is also a constraint.... And you might want different dependencies (eg different authentication provider)
So rather than mess up with the project file and take on a massive maintenance matrix, we leave that to the user who knows better.
As for showing the dependencies right away, we might consider it. I think the thinking was one command for one thing, and also generate can produce a lot of logs, so having a separate command seemed like better UX.

closing since the initial bug was already addressed and we can follow up on a different issue for the dependencies aspect.


Handle new encodings

GLMM
Freq encoding
Ordinal encoding
Datetime encoding

Unit tests are passing, did some manual testing for each of them as well :)


The ollama parameters in the modelfile do not support num_beams

Thanks very much for a great product
I am using a modelfile to create a SqlDecoder2 custom model.
The num_beams parameter improves the accuracy of the model by a lot.
However, this parameter is not yet supported.
Is there any intention of including this parameter in the future?
Many Thanks
Garth

Thank you so much

Hi @garth-waters num_beams isn't something supported in Ollama's API today, and may not be something easy to expose in the future as Ollama's inference engine evolves. May I ask what you are looking to use it for? Feel free to shoot me an email (email in profile :)


Implement Handler for Big Five Comparison

Build back end code for comparing users based on their big five personality traits

Modified personality comparison methods to compare hashtag results instead

Need to refactor code to handle storing users and tweets first, then run analysis after the fact


Tell the kernel where the stack and heap begin in rust_start.

This is an alternative implementation of #406 which keeps all the changes in Rust.
Pros relative to #406: This does not add any more assembly code. It also allows the debug calls to be removed entirely via a feature flag.
Cons relative to #406: Adds 8 bytes to the code size to compute the address of rt_header (same size on ARM and RISC-V).
There is one more way to implement the debug syscalls, which is to add a single mv instruction to each entry point to move rt_header's address into a0 so that rust_start does not need to compute its address. That saves a a few bytes in the common case, but that instruction is not removable and it more tightly couples the entry point assembly with rust_start.
I also updated start_prototype to work with the new RawSyscalls trait, and ran rustfmt on it.

bors r+


TODO [ENGINE]: Fix a bug when loading textures that are missing for a specific graphics quality preset

I have noticed that if you are on a preset < "High" and don't have an original texture or a texture for that preset (i.e., for "Low" you ideally want a texture with "_lq" postfix, etc.) you automatically fail the loading and load a fallback texture. However, you might still have higher quality versions of that textures on disk (i.e. "_mq" or "_hq") which are ignored.
How to fix: Upon failure, we need to traverse upwards, too, and load the first texture available (i.e. for low it would be a mid-quality texture and so on). A similar traversal is already active but for another direction: downwards (i.e. when we are on a high preset and there is no high-quality texture, we start trying anything < high down to the original texture  and only if none of them are on disk, we load a fallback).

fixed under af1d7f3


Adding Stats FAQ

Description of the change: Added two more FAQs re PMM request.
Reason for the change: Because I said so.
Link to original source:
@ksigler7

Hello @Whatthefoxsays,Thanks again for the PR! It's HACKTOBERFEST! We want to show our appreciation by sending                                              you some special Hacktoberfest swag. If you have not already, could you please fill out                                              this form so we can send it to you? Thanks!                                             Team SendGrid DX


Update test checking ownership of /etc/prometheus

/azp run

There were few things we discover checking available options. I will create PR (Prometheus part3) and will verify and compare them. For now, we decided to adjust our tests and leave the owner as it is.


Update not working

Hi,
I have a problem when I just make following comand on my Server (Ubuntu 14.04.5 LTS):
cd /opt/factorio-updater
python update_factorio.py -l
Message I get:
/usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/util/ssl_.py:79: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Traceback (most recent call last):
  File "update_factorio.py", line 138, in <module>
    main()
  File "update_factorio.py", line 106, in main
    j = get_updater_data(args.user, args.token)
  File "update_factorio.py", line 47, in get_updater_data
    raise DownloadFailed('Could not download version list.', r.status_code)
__main__.DownloadFailed: ('Could not download version list.', 404)

Do you know how I can fix it? I am kind of a beginner in Linux-Usage.
Greetz
Muardin

You got a HTTP 404 status from the Factorio API; I can only assume someone was changing something, and the updater API went down (possibly for only a short time). Trying it just now on my machine showed it working.
For reference, the URL it was trying to reach was https://www.factorio.com/updater/get-available-versions.

Worth noting that, while I'm not having this issue, the URL for the updater API did change -- #10 updates this script to use the new endpoint. Please give it another try with the new version and see if that changes anything for you.

It works now, thank you. Now my co-admin has to fix the Python-Warnings I don't understand ;)