Updated community support PR

Hi everyone,
This is an updated 0-diff structural PR for changes that make MAPL buildable in external projects like GCHPctm (replacing #29, and #31). This PR make it possible for external project to use ESMA_cmake without modification, while preserving ESMA_cmake's existing functionality. Note that currently external projects that use MAPL have to implement equivalent functionality to use MAPL's build system.
The problem is that projects that depend on MAPL have to include(esma.cmake) to get the macros MAPL and its supporting infrastructure use in their CMakeLists, but include(esma.cmake) relies on FindBaselibs.cmake which assumes your environment was set up with ESMA-Baselibs (there are hardcoded paths to places where Baselibs installs things).
This problem is solvable though because one of the things CMake is best at is resolving dependencies through find_package() modules.
The feature of this PR are:

Dependencies are resolved with find_package() calls
The "requiredness" of dependencies can be modified from super-projects
Transitive usage requirements control compiler options, definitions, and link libraries.

A target called Baselibs is used to control "GMAO-wide" compiler options, definitions, link libraries, include directories, etc. (you can think of the Baselibs target as a property sheet).
This replaces the current method of using global functions like add_definition() and include_libraries() which is widely regarded as an anti-pattern in CMake.

As for testing, we test GCHPctm's build in >10 environments with combinations of CentOS, Ubuntu, Intel, GCC, OpenMPI, MVAPICH, MPICH, and Intel MPI. I haven't been able to test GEOSgcm's build, but I'm happy to help with any problems that are encountered.
Related issues: #50, #30, #28, #16
Accompanying PRs
Because of that 3rd point (above) there are some minor changes to MAPL and GMAO_Shared that are necessary (mainly "linking" the Baselibs target to compiler definitions, options, link libraries, etc. using its transitive usage requirements ). Below are the PRs that accompany this one. Note that these are also 0-diff structural.

https://github.com/GEOS-ESM/MAPL/pull/226
https://github.com/GEOS-ESM/GMAO_Shared/pull/74

Thanks! Let me know if there's anything I can do to make merging this PR easier!
Liam

@LiamBindle I'm mostly fine with this, but am debating with myself the merits of lumping all of baselibs into one pseudo target.    Isn' the long term strategy to have a find_package() fore each dependency and list the dependencies explicitly at each level.   (Only those that are directly used.  Implicit dependencies are through transitivity, of course.)
Please see my comments/questions in the PRs.

@tclune Sorry, I accidentally closed this PR while cleaning up branches on geoschem/ESMA_cmake.

I'm mostly fine with this, but am debating with myself the merits of lumping all of baselibs into one pseudo target.

Yeah, I'd agree—a single target isn't ideal. Perhaps a separating a base target (for GMAO-wide build properties e.g. compiler options which are set here) from the monolithic Baselibs target (whose transitive properties are inherited here) would be better?

Isn' the long term strategy to have a find_package() fore each dependency and list the dependencies explicitly at each level.

I think so. My thinking with this PR is the first step towards that goal though. I was worried breaking it up too much would lead to a diff that was too big (FindBaselibs.cmake would be removed and there would be more diffs to other GEOS-ESM repos). Maybe that's not right though? I guess axing Baselibs all together and then linking the individual dependency targets where I'm currently linking Baselibs would do the trick. What do you think?
This PR is aimed at being a minimal diff implementation of the functionality necessary for external projects to use ESMA_cmake (abstracting dependency resolution to find_package() calls, and controlling the scope of GMAO-wide build options through a base target) while still working for everything that's built on top of ESMA_cmake.

@tclune @mathomp4 Thanks for the comments. Below is a list of updates I noted

[X] Remove legacy FLAP variables (24097922a81f0a8e1d03ce658c6a8f0b4eedcfc1)
[ ] Readd OS X build logic
[ ] Remove the Baselibs interface target

Replace with an interface target with build properties (compiler options, and preprocessor definitions)
Explicitly link individual libraries

[X] Use NATIVE_COMMAND in separate_arguments() (cca5310e74780f5efea8988cc8c5d6ed436a354c)
[ ] Add cached variable controlling ESMF library that gets linked

Did I miss anything?
For the new interface target with build properties, I was thinking of something like
add_library(GEOS_BuildProperties INTERFACE)
target_compile_options(GEOS_BuildProperties INTERFACE
	$<$<COMPILE_LANGUAGE:Fortran>:
		$<$<OR:$<CONFIG:Release>,$<CONFIG:RelWithDebInfo>,$<CONFIG:MinSizeRel>>:${GEOS_Fortran_FLAGS_RELEASE}>
  		$<$<CONFIG:Debug>:${GEOS_Fortran_FLAGS_DEBUG}>
	>
	""
  )
target_compile_definitions(GEOS_BuildProperties INTERFACE
  HAS_NETCDF4
  HAS_NETCDF3
  H5_HAVE_PARALLEL
  NETCDF_NEED_NF_MPIIO
  HAS_NETCDF3
  )

And then this GEOS_BuildProperties gets "linked" into all the leaves in the dependency tree with the INTERFACE keyword? (INTERFACE keyword means the build properties will propagate up through the tree)
Let me know what you think. I'll make these changes and let you know when it's ready for review again.

@mathomp4 I just pushed some commits with the updates mentioned above.
Note that libraries in MAPL, GMAO_Shared, etc. have to "link" GEOS_BuildProperties to get the GEOS compiler options and definitions (this PR only provides the targets to be linked against). They also have to link their own external dependencies (e.g. MPI::MPI_Fortran, MPI::MPI_CXX, ESMF, OpenMP::OpenMP_Fortran, etc.; again this PR only provides the targets to be linked against).
Let me know what you think.

Friendly bump to keep this PR from getting lost at the bottom of the GH notification stack.
@mathomp4 @tclune

@LiamBindle Not to worry.   It is not forgotten so much as I fear limitations in my cmake knowledge.   I was hoping to have some quiet time this weekend to properly assess.  But managed to distract myself with other things.
I'll definitely jump on it by tomorrow morning.   Coronamuting is mostly freeing my time other than all the playing with MS Teams.  (NASA's approach to slack.)

@tclune Sounds good, no worries. Let me know if there's anything I can do.

@mathomp4 I've reminded myself of the various issues raised in this thread, and am fine performing the merge.   The caveat is that this has been tested with a build of GEOS.   Let me know if you have or can do quickly.  Otherwise, I can take that on (just less efficiently).

@mathomp4 I've reminded myself of the various issues raised in this thread, and am fine performing the merge. The caveat is that this has been tested with a build of GEOS. Let me know if you have or can do quickly. Otherwise, I can take that on (just less efficiently).

Something seems off. I just took our current GEOSgcm, merged in the branches from @LiamBindle for ESMA_cmake and MAPL. Note that since Liam's bits in MAPL went into release/2.0.0, I did another merge into current master.
The cmake step looks okay, but the model is not happy. It dies instantly with make install in CFIO:
Scanning dependencies of target MAPL_cfio_r4
[  0%] Building Fortran object<EMAIL_ADDRESS>/discover/swdev/mathomp4/Models/GEOSgcm-LiamBaselibs/GEOSgcm/src/Shared/@MAPL/MAPL_cfio/ESMF_CFIOBaseMod.f(3): error #5102: Cannot open include file 'netcdf.inc'
       include "netcdf.inc"
---------------^
compilation aborted for<EMAIL_ADDRESS>(code 1)
src/Shared/@MAPL/MAPL_cfio_r4/CMakeFiles/MAPL_cfio_r4.dir/build.make:62: recipe for target<EMAIL_ADDRESS>failed
make[2]: ***<EMAIL_ADDRESS>Error 1
CMakeFiles/Makefile2:1244: recipe for target<EMAIL_ADDRESS>failed
make[1]: ***<EMAIL_ADDRESS>Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2

@LiamBindle Do we need to explicitly add INC_NETCDF? You seemed to remove them in your MAPL branch. Well, you removed:
target_include_directories (${lib} PUBLIC ${INC_NETCDF} ${INC_ESMF})

@mathomp4 Yeah you'll have to add target_xxxx() calls to satisfy all libraries dependencies. This is what I was referring to here

Note that targets in other GEOS-ESM repos like MAPL, GMAO_Shared, etc. are going to have to "link" GEOS_BuildProperties to get the GEOS compiler options and definitions (this PR only provides the targets to be linked against). They are also going to have to link their own external dependencies (e.g. MPI::MPI_Fortran, MPI::MPI_CXX, ESMF, OpenMP::OpenMP_Fortran, etc.; again this PR only provides the targets to be linked against). This could be done transitively (with the PUBLIC keyword) or explicitly (with the PRIVATE keyword) depending on which paradigm you guys think is best.

So for most targets in GEOS you'll be able to fill their build properties (compiler options, preprocessor definitions, include directories, link libraries, etc.) by simple target_link_libraries() calls. For example if target libA depends on ESMF (note that FindESMF.cmake imports the target ESMF) you can resolve all of ESMF's usage requirements (include directories, link libraries, etc.) by doing
target_link_libraries(libA PUBLIC ESMF)

This is a nice and clean way of bundling and passing on dependencies' usage requirements to higher-level targets. Using the PUBLIC keyword will mean targets that link libA automatically get all of ESMF's usage requirements too, and using the PRIVATE keyword will mean target that link libA also have to explicitly have the ESMF target in their list of link libraries.
Note that the GEOS_BuildProperties target is the target that bundles GEOS compiler options and definitions. This is why I usually put the work "link" in quotes--because the CMake terminology unfortunately used the word "link" even though it's really more of a dependency declaration.
Below is a list of targets that are imported by the find package calls in FindBaselibs.cmake and esma.cmake:

MPI::MPI_C, MPI::MPI_CXX, MPI::MPI_Fortran
ESMF
OpenMP::OpenMP_C, OpenMP::OpenMP_CXX, OpenMP::OpenMP_Fortran
FLAP::FLAP
fargparse, gFTL, and gFTL-shared are all config module so they import targets, but I'm not sure what the name of those targets are off the top of my head
Others I missed?

Unfortunately, the FindNetCDF.cmake module provided my ecbuild doesn't supply an imported target. Instead, you'll have to resort to calls like target_include_directories(${lib} PUBLIC ${NETCDF_INCLUDE_DIR}). The list of NetCDF variables are documented here but in summary:

${NETCDF_INCLUDE_DIRS}
${NETCDF_CXX_LIBRARIES} or ${NETCDF_F90_LIBRARIES} or ${NETCDF_LIBRARIES}

So in the specific case you asked about, you would add
# ESMF depends on NetCDFs, so "linking" ESMF fill also fills NetCDF include
#  dirs, link libraries etc. in ${lib}
target_link_libraries(${lib} PUBLIC ESMF)

The following lines are then redundent but optional
target_link_libraries(${lib} PUBLIC ${NETCDF_F90_LIBRARIES})       # redundant but ok
target_include_directories(${lib} PUBLIC ${NETCDF_INCLUDE_DIRS})   # redundant but ok

Does that make sense?

@LiamBindle I see. I was just confused as you removed the netcdf include bits from MAPL_cfio, so I figured the ESMF target would satisfy it. How did it build for you?

As a gentle reminder to myself and Matt:    We want to explicitly list all direct dependencies of a layer.   So even if target A gets netcdf via ESMF,  we want to put it in the target_link_libraries if A directly calls netcdf.   The ESMF target is missing NETCDF_INCLUDE_DIRS. I just pushed a commit which adds ${NETCDF_INCLUDE_DIRS} to the ESMF target's interface include directories.

As a gentle reminder to myself and Matt: We want to explicitly list all direct dependencies of a layer. So even if target A gets netcdf via ESMF, we want to put it in the target_link_libraries if A directly calls netcdf. (And not otherwise.)

Sounds good! You should use the PRIVATE keyword then (not PUBLIC) in target_link_libraries() then (and other calls like target_include_directories()). Also, every GEOS target should explicitly link GEOS_BuildProperties too then.

Good point about PRIVATE - I've been a bit sloppy about my thinking on that.    One side of brain reasoning as above, and the other thinking "make it PUBLIC so that components get access via transitivity".
There may be some caveats down the road.   E.g., NAG does some interesting transitivity things in their .mod files that CMake developers would not believe me when I reported.    So we may need to make .mod files (include_directories) PUBLIC  even when the dependence is only indirect.    Of course, we may never get to the point that we can actually build the model with NAG.    (Won't be surprised if Flang (F18) does something similar with their .mod files though.)

Next error, which might be due to not spreading the changes everywhere:
[  1%] Building Fortran object<EMAIL_ADDRESS>AbstractDataReference.F90(468): #error: can't find include file: templates/vector.inc
src/Shared/@MAPL/GMAO_pFIO/CMakeFiles/GMAO_pFIO.dir/build.make:842: recipe for target<EMAIL_ADDRESS>failed
make[2]: ***<EMAIL_ADDRESS>Error 1
CMakeFiles/Makefile2:1414: recipe for target<EMAIL_ADDRESS>failed
make[1]: ***<EMAIL_ADDRESS>Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2

Yes - this means there is a missing dependency on gFTL that was being inappropriately obtained via transitivity of a PUBLIC in the past.
OTOH, this is pFIO which is pretty much at the bottom of the food chain.  I'd have thought it would have the explicit mention.

@LiamBindle We haven't forgotten this. I'm going to do some tests today. Due to all the changes we've made recently there are conflicts, but I've made a first try at merging/resolving those with develop in the branch: feature/mathomp4/liam-baselibs-develop-merge
I'll keep you up to date.

And we have our first error on CMake step:
CMake Error in<EMAIL_ADDRESS>  Target "MAPL" INTERFACE_INCLUDE_DIRECTORIES property contains path:

    "/discover/swdev/mathomp4/Models/GEOSgcm-SLES12-LiamBaselibs/GEOSgcm/src/Shared/@MAPL/MAPL/"

  which is prefixed in the source directory.

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

I was able to sidestep the issue Matt encountered by commenting out an INCLUDE for a completely unrelated directory.
But then got lots of shell errors:
...
/bin/sh: unused: command not found
/bin/sh: -init=snan,arrays: command not found
/bin/sh: -save-temps: command not found
/bin/sh: -traceback: command not found
/bin/sh: SHELL:-assume: command not found
/bin/sh: -fpe0: command not found
/bin/sh: -fp-model: command not found

Apparently due to constructs like:
set (BYTERECLEN "\"SHELL:-assume byterecl\"")

Reverting Intel.cmake to make progress.

@LiamBindle The expedient solution might be to teach you how to build our GCM and let you trouble shoot.    But I'll give it a bit more effort before punting.

The next issue is that GEOS_BuildProperties is not propagating as expected.  E.g. , in MAPL_Base, I have updated the link to be:
target_link_libraries (${this} PUBLIC ${GEOS_BuildProperties} ${ESMF_LIBRARIES} ${MPI_Fortran_LIBRARIES})

(And ... I know the other 2 elements are now obsolete, but one thing at a time.)
I still find that H5_HAVE_PARALLEL is not being passed to the compiler and thus breaking the build.

The next issue is that GEOS_BuildProperties is not propagating as expected. E.g. , in MAPL_Base, I have updated the link to be:
target_link_libraries (${this} PUBLIC ${GEOS_BuildProperties} ${ESMF_LIBRARIES} ${MPI_Fortran_LIBRARIES})

(And ... I know the other 2 elements are now obsolete, but one thing at a time.)
I still find that H5_HAVE_PARALLEL is not being passed to the compiler and thus breaking the build.

My bad.  I had put "${}" around GEOS_...

I've resolved the "SHELL" issue.   Some of the DEBUG flags were not being guarded.

@LiamBindle Unfortunately this SHELL issue propagates into lots of other CMakeLists.txt files where we do things like:
set_property(SOURCE rsg3_vinterp.F APPEND_STRING PROPERTY COMPILE_FLAGS "${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE}")

Which now does not evaluate cleanly.     Why was this duplicate arguments issue not plaguing us before?

@tclune @mathomp4 Thanks for the updates. Sorry about this turning into a bit of a project.
I'm confused why the missing "SHELL:" prefixes didn't cause problems for you guys before as well. When we omit them we get errors because a lot of first words of multi-word arguments get removed. And currently, we aren't able to build GCHPctm in the Debug build type because these "SHELL:" prefixes haven't been added to all the multi-word debug arguments yet.
Perhaps the reason it didn't cause issues for you before is because the compiler flags were actually being set as one big string, rather than a list of strings. For example, this
set_property(SOURCE rsg3_vinterp.F APPEND_STRING PROPERTY COMPILE_FLAGS "${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE}")

Appends the string "${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE}" to rsg3_vinterp.F's COMPILE_FLAGS property—so rsg3_vinterp.F's COMPILE_FLAGS property is actually just one big string. And perhaps this is registered by CMake's de-duplicate filter as a single long argument (and hence, the de-duplicator doesn't do anything).
What's the problem with how
set_property(SOURCE rsg3_vinterp.F APPEND_STRING PROPERTY COMPILE_FLAGS "${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE}")

is being evaluated? Can separate_arguments() property parse and split rsg3_vinterp.F's COMPILE_FLAGS property?

Also, note that the other way to do what you did above would be
set_property(SOURCE rsg3_vinterp.F APPEND PROPERTY COMPILE_FLAGS ${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE})

which would append ${FREAL8},${BYTERECLEN},${EXTENDED_SOURCE} as elements to rsg3_vinterp.F's COMPILE_FLAGS property (which is a list here).

Also, note that the other way to do what you did above would be
set_property(SOURCE rsg3_vinterp.F APPEND PROPERTY COMPILE_FLAGS ${FREAL8} ${BYTERECLEN} ${EXTENDED_SOURCE})

which would append ${FREAL8},${BYTERECLEN},${EXTENDED_SOURCE} as elements to rsg3_vinterp.F's COMPILE_FLAGS property (which is a list here).

Ok - I'll try that.   At least it is cleaner than the kludge I came up with which was to have 2 vars for each such flag.

Spoke too soon.   The flags are passed through an ecbuild macro ...

OK - I was able to produce GEOSgcm.x which is a useful milestone.  The changes were few but generally undesirable.  Will discuss at the telecon this afternoon.
And ... it looks like something is wrong with the linkage for the libraries produced with F2PY.   Unfortunately the error message is short and useless.   Best guess is that it is related to the other wonkiness with NetCDF.

@LiamBindle @tclune The f2py business will be quite twitchy and might need help from both of you.
Essentially f2py is not good at...is not good. We already have a very fragile system for it. What I do right now is like this:
if (F2PY_FOUND)
   if (precision STREQUAL "r4")
   add_f2py_module(GFIO_ SOURCES GFIO_py.F90
      DESTINATION lib/Python
      ONLY gfioopen gfiocreate gfiodiminquire gfioinquire
      gfiogetvar gfiogetvart gfioputvar gfiogetbegdatetime
      gfiointerpxy gfiointerpnn gfiocoordnn gfioclose
      LIBRARIES GMAO_gfio_r4 ${NETCDF_LIBRARIES}
      INCLUDEDIRS ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/lib ${BASEDIR}/lib ${include_${this}} ${INC_NETCDF}
      USE_MPI
      )
   add_dependencies(GFIO_ ${this})
   endif ()
endif (F2PY_FOUND)

The main issue is I need something that looks like ${NETCDF_LIBRARIES} looked like before and what ${INC_NETCDF} looked like before. Staring at the file in ecbuild, it looks like we should still have ${NETCDF_LIBRARIES}, but ${INC_NETCDF} is now ${NETCDF_INCLUDE_DIRS}

Okay. f2py is not due to the include bits. It's a library issue. Before, f2py was seeing the -lfoo style:
-L/discover/swdev/mathomp4/Models/GEOSgcm-SLES12-stock/GEOSgcm/build-Debug/src/Shared/@GMAO_Shared/GMAO_gfio_r4 -L/discover/swdev/mathomp4/Models/GEOSgcm-SLES12-stock/GEOSgcm/build-Debug/lib -L/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib -L/discover/swdev/mathomp4/Models/GEOSgcm-SLES12-stock/GEOSgcm/build-Debug/include/GMAO_gfio_r4 -L/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/include/netcdf -lGMAO_gfio_r4 -lnetcdff -lnetcdf -lhdf5_hl -lhdf5 -lmfhdf -ldf -lsz -ljpeg -lgpfs -ldl -lcurl -lssl -lcrypto -lz -lm -L/gpfsm/dulocal/sles12/intel/2020/compilers_and_libraries_2020.0.166/linux/mpi/intel64/lib -lmpifort -L/gpfsm/dulocal/sles12/intel/2020/compilers_and_libraries_2020.0.166/linux/mpi/intel64/lib/release -lmpi -L/usr/lib64 -ldl -L/usr/lib64 -lrt -L/usr/lib64 -lpthread only: gfioopen gfiocreate gfiodiminquire gfioinquire gfiogetvar gfiogetvart gfioputvar gfiogetbegdatetime gfiointerpxy gfiointerpnn gfiocoordnn gfioclose

Now though, it's seeing full path static libraries:
-l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib/libnetcdf.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib/libnetcdff.a -loptimized -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib/libnetcdf.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib/libnetcdff.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib/libhdf5.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib/libsz.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib/libz.so -l/usr/lib64/libdl.so -l/usr/lib64/libm.so -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib/libhdf5.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib/libsz.a -l/discover/swdev/gmao_SIteam/Baselibs/ESMA-Baselibs-6.0.11-SLES12/x86_64-unknown-linux-gnu/ifort_<IP_ADDRESS>4-intelmpi_<IP_ADDRESS>/Linux/lib/libz.so -l/usr/lib64/libdl.so -l/usr/lib64/libm.so -L/gpfsm/dulocal/sles12/intel/2020/compilers_and_libraries_2020.0.166/linux/mpi/intel64/lib -lmpifort -L/gpfsm/dulocal/sles12/intel/2020/compilers_and_libraries_2020.0.166/linux/mpi/intel64/lib/release -lmpi -L/usr/lib64 -ldl -L/usr/lib64 -lrt -L/usr/lib64 -lpthread only: gfioopen gfiocreate gfiodiminquire gfioinquire gfiogetvar gfiogetvart gfioputvar gfiogetbegdatetime gfiointerpxy gfiointerpnn gfiocoordnn gfioclose

I think I have a first good shot at fixing the f2py biz.

@mathomp4
I didn't realize this before, but it seems the deduplicator might only affect properties (i.e. not variables like CMake_Fortran_FLAGS; only the COMPILE_FLAGS property instead). IIUC the variables like CMake_Fortran_FLAGS are initialized by the FFLAGS environment variable and the similar flags for other languages (ref). IIUC the deduplicator is meant to prevent COMPILE_FLAGS from accumulating duplicate properties, and the SHELL: prefix was added to prevent the deduplicator from splitting multiword arguments (ref). I'm reading a bit between the lines here, but I think my interpretation is consistent with the documentation because add_compile_options' documentation mentions the deduplicator, whereas the CMAKE_<LANG>_FLAGS documentation doesn't.
Is there a reason the CMAKE_<LANG>_FLAGS variables have to be used? If not, you could prevent these variables from taking on their default values (i.e. CFLAGS, CXXFLAGS, FFLAGS) by setting them to an empty string. Doing this in your top-level directory would set it empty for the entire tree. This way, only the compile flags in targets' properties should be used.
If you guys would prefer to continue using the CMAKE_<LANG>_FLAGS variables, the goal of this PR can still be accomplished. But, each repo would have to set CMAKE_<LANG>_FLAGS variables itself (i.e. ESMA_cmake shouldn't set CMake_Fortran_FLAGS). If this were the case, no SHELL: prefixes should be used.

I'm not sure if my explanation of how I think target properties could be used to set compiler options was clear, so here's a more detailed explanation.

Compiler flags in ESMA_cmake should be stored as lists (i.e. in the semicolon separated format) with "SHELL:xxxx yyyy wrapping multiword arguments
In the top level directory, CMAKE_Fortran_FLAGS should be initialized to "" to prevent CMake from using the environment's FFLAGS
Compiler flags are specified with the target_compile_options() like so (note that common_Fortran_flags is a list; below it's expanded as multiple arguments (i.e. it isn't wrapped in "")

target_compile_options(targetA  PUBLIC|PRIVATE ${common_Fortran_flags})

Does that make sense? Let me know if I can clarify anything.

@mathomp4 @tclune I just learned this, and I think it might be of interest to you two. There's a generator expression, $<LINK_ONLY:...>, which can be used in target_link_libraries() calls to link a target but not use it's transitive usage requirements (ref). I just learned about this and thought it might be of interest to you guys because it allows for finer control over transitive requirements.

Thanks.   I recently went a bit deeper in this direction to enable a situation where my tests are linked with a mock library while the app itself is linked to a real library.   Cant's say I find the syntax intuitive though.
On a related front, I've had to start making more target_include_directories() use PUBLIC.   The latest Intel compiler is now chaining some interface information through secondary .mod files.   E.g., if package A produces a.mod, and Package B uses a.mod and produces b.mod, then if Package C uses b.mod it may need the include dirs for A.

Random query for @LiamBindle : is it possible this is now taken care of in MAPL/ESMA_cmake? All the changes and stuff we made for UFS/NOAA seemed to be aimed at "UFS doesn't use Baselibs".

@mathomp4 Yeah, I suspect so. I bet a lot of that work fulfills what we need---I haven't had a chance to rebase and try out all the new work, but coincidentally I am hoping to do that this afternoon.
Sorry, I didn't realize this PR was still open. I'll close it.
If new things arise, I will open new issues/PR, but I think the contents of this PR are outdated/redundant now.

@LiamBindle Sounds good. Though realize any "no-Baselibs" changes will now also need to work with UFS/NOAA. The "fun" of a multi-organization library! But we'll get there. Thanks for the patience


Faile to connect, secondary seems unresponsive

Hi,
as I am running Home-Assistant in Docker container I found this repository as a solution to use the Sonoff Dongle-E as RCP
I created the docker compose as especified in the description, but when I start I get the following log.
I get the error described in the last two lines then forever and the server is not available
Any ideas?
multipan    | WARNING in function 'main' in file /usr/src/cpc-daemon/main.c at line #186 : Running CPCd as 'root' is not recommended. Proceed at your own risk.
multipan    | [16:48:56:464782] Info : [CPCd v<IP_ADDRESS>] [Library API v3] [RCP Protocol v4]
multipan    | [16:48:56:464812] Info : Git commit: 133b29678b3d0bc7578e098d2f46b4d5bcd2ebb4 / branch:
multipan    | [16:48:56:464818] Info : Sources hash: ff8300587e7e4ab1def7a89a272c0baef32f9eb3bff9b0ba06b94e655d652367
multipan    | [16:48:56:464823] WARNING : In function 'main' in file /usr/src/cpc-daemon/main.c at line #186 : Running CPCd as 'root' is not recommended. Proceed at your own risk.
multipan    | [16:48:56:464849] Info : Reading cli arguments
multipan    | [16:48:56:464855] Info : /usr/local/bin/cpcd
multipan    | [16:48:56:465483] Info : Reading configuration
multipan    | [16:48:56:465490] Info :   file_path = /usr/local/etc/cpcd.conf
multipan    | [16:48:56:465494] Info :   instance_name = cpcd_0
multipan    | [16:48:56:465497] Info :   socket_folder = /dev/shm
multipan    | [16:48:56:465501] Info :   operation_mode = MODE_NORMAL
multipan    | [16:48:56:465504] Info :   use_encryption = false
multipan    | [16:48:56:465507] Info :   binding_key_file = /root/.cpcd/binding.key
multipan    | [16:48:56:465511] Info :   stdout_tracing = false
multipan    | [16:48:56:465514] Info :   file_tracing = false
multipan    | [16:48:56:465517] Info :   lttng_tracing = false
multipan    | [16:48:56:465520] Info :   enable_frame_trace = false
multipan    | [16:48:56:465524] Info :   traces_folder = /dev/shm/cpcd-traces
multipan    | [16:48:56:465527] Info :   bus = UART
multipan    | [16:48:56:465530] Info :   uart_baudrate = 460800
multipan    | [16:48:56:465534] Info :   uart_hardflow = true
multipan    | [16:48:56:465537] Info :   uart_file = /dev/ttyACM0
multipan    | [16:48:56:465540] Info :   fu_recovery_pins_enabled = false
multipan    | [16:48:56:465543] Info :   fu_connect_to_bootloader = false
multipan    | [16:48:56:465547] Info :   fu_enter_bootloader = false
multipan    | [16:48:56:465550] Info :   restart_cpcd = false
multipan    | [16:48:56:465553] Info :   application_version_validation = false
multipan    | [16:48:56:465557] Info :   print_secondary_versions_and_exit = false
multipan    | [16:48:56:465560] Info :   use_noop_keep_alive = false
multipan    | [16:48:56:465563] Info :   reset_sequence = true
multipan    | [16:48:56:465567] Info :   stats_interval = 0
multipan    | [16:48:56:465570] Info :   rlimit_nofile = 2000
multipan    | [16:48:56:465573] Info : ENCRYPTION IS DISABLED
multipan    | [16:48:56:465577] Info : Starting daemon in normal mode
multipan    | [16:48:56:476464] Info : Connecting to Secondary...
multipan    | [16:48:58:476687] Info : Failed to connect, secondary seems unresponsive
multipan    | [16:48:58:476713] Info : Connecting to Secondary...

Just downloaded it today and getting the same thing.

I updated to the latest firmware - https://github.com/NabuCasa/silabs-firmware/blob/main/RCPMultiPAN/beta/NabuCasa_SkyConnect_RCP_v4.3.1_rcp-uart-hw-802154_460800.gbl
And that got it running for me

I have the same issue @jfdzar mentioned above. i have the skyconnect usb dongle. I tried to flash the new firmware but i fail a this error message:
`2023-10-17T20:46:00.894955447Z Error: '/data/firmware/NabuCasa_SkyConnect_RCP_v4.3.1_rcp-uart-hw-802154_460800.gbl' does not appear to be a valid GBL image: ValidationError('Image is truncated: tag value is cut off')
2023-10-17T20:46:00.929952425Z s6-rc: warning: unable to start service universal-silabs-flasher: command exited 1
2023-10-17T20:46:00.931043400Z /run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.`

I found my mistake. My firmware download was not correct, therefore flashing failed. In the end it worked using: https://skyconnect.home-assistant.io/


mtPaint: 3.49.12 → 3.50.01

Motivation for this change

Version 3.50 released
Use GTK3 (GTK2 has reached end of life)
Enable i18n
Install .desktop, man files
Fix license

Things done

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

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

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

cc @vklquevs

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108729 run on x86_64-linux 1

1 package built:

mtpaint

This is a semi-automatic executed nixpkgs-review which does not build all packages (e.g. lumo, tensorflow or pytorch)
If you find some bugs or got suggestions for further things to search or run please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 108729 run on x86_64-linux 1

1 package built:

mtpaint


Implement travis.yml and build validation

We need some means of validating that a build or a PR is good in Travis CI.

I wonder if running tracegen against a zipkin cluster pulled up with docker would solve this?


Save transcript fix

As it stands, the transcript path for a conversation opened via url is incorrect when there is an active bot opened via .bot file. With https://github.com/Microsoft/BotFramework-Emulator/pull/1438 it enables this change to support saving transcripts in both .bot file conversations and conversations opened via url.

Pull Request Test Coverage Report for Build 2432

3 of 9 (33.33%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.05%) to 56.742%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/app/main/src/botHelpers.ts
0
6
0.0%

Totals

Change from base Build 2430:
-0.05%

Covered Lines:
5235

Relevant Lines:
8676

💛  - Coveralls

Closing in lieu of https://github.com/Microsoft/BotFramework-Emulator/pull/1440


soc: xtensa: intel_adsp: cavs: fix assert on L3_MEM_BASE_ADDR

The assert on L3_MEM_BASE_ADDR is incorrect, we need must convert to uncached before use.
Fixes: ffd2121c65d3 ("soc: xtensa: intel_adsp: cavs: fix power_down_cavs() signature")

Test results with SOF CI running at https://github.com/thesofproject/sof/pull/8136 , looks good (previously failing tests are now passing), so marking as ready for review.

This is my bad, the assert is not correct. The test plans I ran for the faulty PR actually caught the failure, but I made a human error in parsing the test results. The test plan that failed has been flaky in recent weeks, but I did not spot the actual failure on cAVS2.5 targets, so this slipped through.

Ok, all tests passed in https://github.com/thesofproject/sof/pull/8136 and CI is good here as well, so this should be good to go.


Remove incorrect statement about supported network devices with virtual machines

According documentation supported types with virtual machines are physical, bridged, macvlan, p2p, sriov

This pull request didn't trigger Jenkins as its author isn't in the whitelist.
An organization member must perform one of the following:

To have this branch tested by Jenkins, use the "ok to test" command.
To have a one time test done, use the "test this please" command.

Those commands are simple Github comments of the format: "jenkins: COMMAND"

Thanks!


check for IsScanner on slices

I've got a list type that I want to serialise to a single value (included below). With this change, gorm will check to see if a slice can be treated as a value, just as happens with structs below. The column in the database is like create table x (identifiers jsonb[]).
type Identifier struct {
	Use      Code          `json:"use"`
	Label    string        `json:"label"`
	System   URI           `json:"system"`
	Value    string        `json:"value"`
	Period   *Period       `json:"period"`
	Assigner *Organization `json:"assigner"`
}

type IdentifierList []Identifier

func (i IdentifierList) Value() (driver.Value, error) {
	bits := []string{}

	for _, v := range i {
		if d, err := json.Marshal(v); err != nil {
			return nil, err
		} else {
			bits = append(bits, strconv.Quote(string(d)))
		}
	}

	v := []byte("{" + strings.Join(bits, ",") + "}")

	return v, nil
}

func (i *IdentifierList) Scan(input interface{}) error {
	b, ok := input.([]byte)
	if !ok {
		return ErrInvalidInput
	}

	var bits []string
	if err := json.Unmarshal([]byte("["+string(b[1:len(b)-1])+"]"), &bits); err != nil {
		return err
	}

	for _, s := range bits {
		var v Identifier
		if err := json.Unmarshal([]byte(s), &v); err != nil {
			return err
		}

		*i = append(*i, v)
	}

	return nil
}

@deoxxa How about adding a unit-test to ensure correct behavior? ;)

I can definitely do that - I just wanted to push this when I wrote it so I wouldn't forget to push it later.

Hi @deoxxa
Thank you for that, will merge it after get your tests ;)

There's a test for it now. It doesn't use any advanced features of the database, unlike my example above, but it does test the functionality of gorm.

Nice @deoxxa, thanks for coming through on this.  LGTM.

Hi @deoxxa
Thank you for your pull request and test


Xml content inside  tag not parsed

Description
Hello, I am using HAP to parse custom xml (not actual html).
I've noticed that the latest versions can't parse the content in title tag - the content is parsed as HtmlTextNode.
Example code:
var htmlDocumnet = new HtmlDocument();
htmlDocumnet.LoadHtml("<bodyType> <title normalized-num=\"4\"> <num>ДЯЛ ЧЕТВЪРТИ</num> <heading>ПРИЛОЖИМ ЗАКОН</heading> </title> </bodyType>");

Expanding the DOM you will see that the child node of the <title> tag is single HtmlTextNode, where in previous versions the <num> and <heading> are parsed as child nodes.
The issue is not present in HAP 1.11.3.
In releases 1.11.7 and 1.11.8 there is a fixed issue which i think may be related
Further technical details

HAP version: 1.11.9
NET version (net471):

Hello @apis-bulgaria ,
I'm not sure but I believe it now work as intended.
If you put this code in an html file and open it, you will see the title is <num>ДЯЛ ЧЕТВЪРТИ</num> <heading>ПРИЛОЖИМ ЗАКОН</heading> so this is indeed a text node. the num and heading are not child nodes but part of the text.

Okay, thanks for the info.
I will use older version of HAP for now and at some point will try to migrate to System.Xml.Linq.


RN-10 Ability to search Posts

Summary
Functionality to search for posts, the search bar includes autocomplete for usernames and channels like the webapp.
Ticket Link
https://mattermost.atlassian.net/browse/RN-10
Checklist

[x] All new/modified APIs include changes to mattermost-redux
[x] Has UI changes
[x] Includes text changes and localization file updates

Device Information
This PR was tested on:

IOS 10.3 iPhone 6 (Simulator)
IOS 10.2.1 iPhone 6s
Android 6.0.1 Samsung J5
Android 7.0.1 Nexus 5 (Simulator)

@hmhealey changes made


fix(deps): remove all current vulnerability of loopback4-kafka-client

remove all current vulnerability of loopback4-kafka-client
GH-8
Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes #8
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Intermediate change (work in progress)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Checklist:

[ ] Performed a self-review of my own code
[ ] npm test passes on your machine
[ ] New tests added or existing tests modified to cover all changes
[ ] Code conforms with the style guide
[ ] API Documentation in code was updated
[ ] Any dependent changes have been merged and published in downstream modules

:tada: This PR is included in version 1.1.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Use @huacnlee/autocorrect and use format_for method.

The format_for method have built-in the Markdown parse to process the Markdown contents in safely.

Grateful for the reminder from the esteemed author. DONE: https://github.com/b-yp/obsidian-autocorrect/commit/2788c5d9c0fb3469cbacdb73c200e3c3552f9081


Usage

Hi, guys.
I just stumbled across this and was wondering how you're currently using it?
I've run into a situation where I need to be able to be able to essentially archive models for historical purposes and wondering if this addon might fit the bill. The situation is this:
The platform I'm building deals primarily with appointments. Each appointment has a service associated with it. Business owners may want to change details about their services from time-to-time, but I need to be able to retain the existing service before modifications are made so that a change to a service wouldn't reflect in a past appointment.
Any thoughts on whether or not your addon sounds like a good fit?
Thanks!
James

@jamesdixon sounds like a good application for bookshelf-history.

Hey @jamesdixon we aren't currently using bookshelf-history because we stopped needing to store historical records so bookshelf-paranoia was enough.
It sounds like this plugin might work well for you. Whenever a change is made to a model that is being tracked with a history table, the model will update and a row will be added to the history table so you have a historical reference. We made it pretty simple for you to revert back to a previous point in history.

@bsiddiqui @alanhoff thank you for the super-quick responses!


Image Posting Update on the Course Browsing Mode

I have uploaded an image and after posting the code and link of the image on the source page,
https://github.com/ebonsi/course-in-a-box/blob/gh-pages/modules/tutorial/_posts/2019-10-04-section2.md
...the image does not update or show up on the Course's Browsing Pages.
https://ebonsi.github.io/course-in-a-box/modules/tutorial/section2/

One day before the same happened with the image named: "Catch the Wave" post here
https://ebonsi.github.io/course-in-a-box/
Eventually, the image ends up to show up! This is not what I am expecting when doing development. If I post an image, the same should show up at the browsing site immediately.
... I am wondering if that is a bug or something that is missing in the newly created pages.
Thanks!
Ps: Sorry for the railing noise in the comments. The times where I am developing websites, I know the structure of elements and images and they show up as I reload the page. Unless there are some mistakes in the code.

This question has been answered at p2pu.org forum by https://community.p2pu.org/u/dirk,
https://community.p2pu.org/t/sharing-course-in-a-box-technical-issues/4110/5
Links on the Github structure development follows this code semantics,
You can solve this by using the fully qualified url: https://ebonsi.github.io/course-in-a-box/img/domain-host-registrar-01.png
or by pre-pending the URL in markdown with site.baseurl:
![image name]({{site.baseurl}}/img/domain-host-registrar-01.png)


[release-1.10] echotest: include namespace in subtest when service exists in multiple

This is an automated cherry-pick of #32121

@istio-testing: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-multicluster-tests_istio_release-1.10
21cd46bc2fd750d389ade1d6244a3e41c983b30a
link
/test integ-pilot-multicluster-tests_istio_release-1.10

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


Enable Sysprep for Windows 2016 LibVirt build

The Packer configuration for the LibVirt build of the Windows 2016 machine is missing the sysprep step to generalize the resulting image. This leads to the error described in #516 .

LGTM, thanks for correcting this with a PR @kithack !


System.Nullable stopped working with Npgsql 4.0

Hi,
I have experienced an issue after Npgsql upgrade from 3.2.7 to 4.0 saying

Can't write CLR type System.Nullable`1[System.Int64] to database type

This is clearly a Npgsql bug that should be solved in their 4.0.1 Milestone https://github.com/npgsql/npgsql/milestone/52, so just for you to know.

Thanks for the information!

You are most welcome.
Just an update and something to think about from
https://github.com/npgsql/npgsql/issues/1965#issuecomment-398001047
as it looks like it will take some time for nullables to be ready for your usage in Npgsql 4 from
https://github.com/npgsql/npgsql/issues/1965#issuecomment-398001170
The question is whether even consider handling DBNull.Value on your own.

Thanks for the follow-up!  I think it is acceptable to stay on PostgreSQLCopyHelper and Npgsql 3.2.7 until the Npgsql is officially released.

@wejto Forget my last comment. The fix was trivial. I will release it in a moment.

I have released Version 2.1.0 to NuGet which fixes the issue. Thanks for your support and the follow-up, which made it trivial to work around the issue until Npgsql has a fix in place. Please reopen the ticket, if the problem persists with version 2.1.0.

@wejto Great! Thanks for the feedback. 🙏


input: implemented gamepad simulation keyboard and mouse.

https://youtu.be/d3n1hb4OKmw

I haven’t written iOS code for a long time...😂
I will resubmit it after correcting the mistakes tomorrow...

I will resolve the conflicts and re-PR again today.

You know that you can git push --force origin gamepad without having to open a new PR right? That’s preferred as the comments and code review are preserved.

You know that you can git push --force origin gamepad without having to open a new PR right? That’s preferred as the comments and code review are preserved.

fatal: unable to access 'https://github.com/utmapp/UTM.git/': The requested URL returned error: 403
I think I have no access right to push

Please update and rebase on master: https://stackoverflow.com/questions/7244321/how-do-i-update-a-github-forked-repository#7244456
Also for the GitHub actions, you need to create a new secret XCODE_PATH with the value /Applications/Xcode_11.4.app  Thanks!


Feat: Request & Response streaming

The current interaction with SurrealDB wait for the entirety of the response to arrive before processing the JSON into a DOM and then allowing the user to access the received content.
This is a bad pipeline, because we wait at two separate instances for the remaining tasks.
This should be solved using a custom DataReader and DataWriiter, they can be interacted with on a document by document basis, similar to the SQLite driver.

Implemented with #68


Clean up 4xx and 5xx error schemas

Lets implement this properly.
we should return proper errors in a json format.

5xx errors still show html responses in the schema

not possible, please rebuild. I have completely removed 500 response


Update dependencies for Kubernetes v1.29

Update to Kubernetes v2.29.4 and related dependencies.

:+1:

👍


Let me use the version from the Flutter snap so I don't have to download twice.

I have a mobile internet connection that is metered and slow when I'm out of the plan. So I did a snap download flutter to download the futter snap package to local storage so I could go out to the park and have some fun with Flutter. But then I came to the park and just do a local snap install flutter.snap". Great. I was then told to run "fflutter config --android-studio-dir /snap/android-studio/current/android-studio", but then it suddenly starts downloading Flutter, which is going to take a long time and I'm guessing that if I abort, it'll start again.
Why does Flutter not simply rely on the Flutter snap package I have, instead of manually downloading it outside the packaging system? It is so damaging to the user experience to suddenly and without warning have to wait for over an hour on first run after installing a package and have to pay for the privilege to boot.
Please fix this. Also; am I running the risk every time I run Flutter that it may suddenly require hundreds of megabytes in downloads without warning?

Please file issues with the snap installation at https://github.com/canonical/flutter-snap/issues

Also; am I running the risk every time I run Flutter that it may suddenly require hundreds of megabytes in downloads without warning?

Flutter downloads binaries on demand to avoid downloading a lot of large files people may never need (e.g., the Flutter engines for all the target platforms they never target). The flutter precache command will let you get the parts you want in advance, and is designed for use cases like yours.

I don't understand. I do not. For me, three hours of waiting while I'm eager to do something, does not equal three hours of my computer doing downloads while I'm asleep. It took me two weeks to download Ubuntu 22.04, but now I have it on a 100Gbps connection, so when I did upgrade, I did not have to wait. I have every Ubuntu going back to 2006 stored, because disks are cheap, but time is not.
Is there a way for me to download the Flutter ecosystem that way, or some other way that I can install it on demand on different systems? This sense of not being in control is not appetizing at all. Do you remember when Bill Gates demonstrated Windows 98? I don't like that experience.
If this is open source, why can't I just download it in advance?

Oh, you just closed it. I see. It's just not for me then. Nothing wrong with that. It's the way of the MAGA I guess.

Is there a way for me to download the Flutter ecosystem that way

Please see my comment above: flutter precache is there for the exact purpose of pre-downloading everything you need so that you won't need to do on-demand downloads later.


Simplify and reduce main-bosh-docker image size

Switch main-bosh-docker to be an independent image (and simplify it a bit).
Avoids many unnecessary layers and packages, reducing to 0.6 GB (from 2.2 GB). If downstream users were relying on packages, they'll want to build their own images using this as the base image.
This significantly reduces the time and disk I/O required by Concourse for spinning up a new container. Unofficial times... on my cheap workers, it reduces start time from ~7 minutes to ~1 minute, and on regular workers, reduces start time from ~1 minute to <15 seconds.
You might care that it uses the brightbox/ruby-ng PPA to install ruby on the system. It seems like a well-known repository and avoids the chruby/rbenv mess since multiple versions aren't needed.
I built and pushed dpb587/bosh-main-bosh-docker:light with this code for testing.
Might want to change the CI pipeline.

Switched to ubuntu:xenial and removed ppa:brightbox/ruby-ng  and tested a couple things with it and it all seems to work well.
# ruby --version
ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]


Include v1.1.0-RC1 on releases page?

@sjrd https://github.com/scalacenter/scalac-profiling/releases/tag/v1.0.0  did something go wrong here?

sorry, I got confused


[Bug] Reusing a keyword is not possible anymore.

Regression: in previous versions, Beeftext allowed the user to reuse a keyword. When triggered, Beeftext would choose randomly a matching combo.
In the current version,  if the use tries to re-use a keyword in the editor window, There is no feedback when clicking the OK button and the dialog does not close.

Issue was caused by a bug with messages boxes with custom button. It had already been fixed by 6da757f1381f0d3dce7a1030dace565ac2404b23.
Test builds:

Beeftext-13.0-Installer.zip
Beeftext-13.0-PortableEdition.zip


Add itd

[X] I have checked that this app does not already have a pending request and has not previously been declined.
App Name: itd
Download URL: https://gitea.arsenm.dev/Arsen6331/itd/releases
Website URL: https://gitea.arsenm.dev/Arsen6331/itd
App Summary: InfiniTime Daemon

Will require Gitea integration.


[BUG] SharePoint Modernization Scanner tool missing workflow from SharePoint sites

Issue :
We have approx. 7000 SharePoint sites. Among them, we have successfully run all the sites but there are a couple of workflows missing from the sites in the report. We are using Azure ACS apps only for authentication.
Example:
The workflow that has been created in Feb 2020 missing in all version of reports and some of the Workflow which has been created in 2019 missed in version <IP_ADDRESS> but it does show up in version <IP_ADDRESS>.
Error:
We have not seen any error for missing workflow site collection or site into error reports.

2.18 fixed detection of workflows on list content types. Note that only custom workflows that have a subscription (so that are being used) are reported by the tool. Can you provide more details about the workflows you're not seeing when using version 2.18?

Closing per no response anymore

Closing per no response anymore


Release a new version with the Optional Fix

Please release a new version with the "Optional Fix", so that it can be used in other libraries. CocoaPods Podspec doesn't allow to specify a branch for a dependency.

Done 👍


Proxies do not work

What do you mean?

The proxies I receive from arq are dead and even the port is closed

Replace the IP with any address from this list, omit the port if you want, it will work.

Country
Location
Address

Australia
Sydney
syd.socks.ipvanish.com

Brazil
Sao Paulo
gig.socks.ipvanish.com

Canada
Toronto
tor.socks.ipvanish.com

France
Paris
par.socks.ipvanish.com

Germany
Frankfurt
fra.socks.ipvanish.com

Italy
Milan
lin.socks.ipvanish.com

Japan
Tokyo
nrt.socks.ipvanish.com

Netherlands
Amsterdam
ams.socks.ipvanish.com

Poland
Warsaw
waw.socks.ipvanish.com

Portugal
Lisbon
lis.socks.ipvanish.com

Singapore
Singapore
sin.socks.ipvanish.com

Spain
Madrid
mad.socks.ipvanish.com

Sweden
Stockholm
sto.socks.ipvanish.com

United Kingdom
London
lon.socks.ipvanish.com

United States
Ashburn
iad.socks.ipvanish.com

United States
Atlanta
atl.socks.ipvanish.com

United States
Boston
bos.socks.ipvanish.com

United States
Charlotte
clt.socks.ipvanish.com

United States
Chicago
chi.socks.ipvanish.com

United States
Dallas
dal.socks.ipvanish.com

United States
Denver
den.socks.ipvanish.com

United States
Los Angeles
lax.socks.ipvanish.com

United States
Miami
mia.socks.ipvanish.com

United States
New Orleans
msy.socks.ipvanish.com

United States
New York
nyc.socks.ipvanish.com

United States
Phoenix
phx.socks.ipvanish.com

United States
Seattle
sea.socks.ipvanish.com


Controllers not working when trying to target SteamVR & Oculus for different platforms

This could just be user error on my part.
For my project I'm attempting to target Steam VR for desktop, and Oculus for Android (Quest 1/2) but it seems that input fails to register when targeting OpenVR Loader for PC in XR Plug-in Management.
I started by testing Oculus in desktop mode, which worked. After that I then followed the SteamVR Plugin steps in the documentation but when playing with OpenVR Loader, the controller's don't work at all. No input tracking and no button presses.

If I then switch back to Oculus in XR Plug-in Management, everything works again.
Is there anything I can try to fix this? Or is there a limit to how many VR SDK's I can target at once?

Hello @CBerry22,
Oculus devices are currently only supported through the Oculus plugin but we plan to add SteamVR and OpenXR support really soon. Same for all other devices, we will gradually add OpenXR to those who support it.

SteamVR support for Oculus devices has been added in v0.9.6

Any updates on OpenXR support for Oculus devices?

We will review the current state of OpenXR support for all devices soon, see what features are missing and what is implemented. For now we recommend using either the Oculus or SteamVR integrations.


fix: add fidget filetype to exclude_filetypes

fidget.nvim is a popular Neovim plugin that describes itself as an "Extensible UI for Neovim notifications and LSP progress messages". The indent guides in its UI appear to be rendering, as shown in this image:

To address this, I added its filetype to the exclude_filetype table and enabled the exclusion by default, as this seems to be an error and could potentially harm performance.

Anyway, I have decided to stop using this plugin...

Don't worry man, your plugin is awesome, I just switched back to indent-blankline because almost all colorschemes support it and I like the way the indent highlighting looks better in contrast to the chunk. Add to that I'm not sure if I'm going to run into a problem in the future because the chunk selection seems very complex and language dependent. But as I said, it's still pretty awesome and it's more than I know how to do at the moment.
And a question if you know the answer, do you know if this plugin is significantly faster than indent-blankline?

From my own tests, it is like this, but I did occasionally encounter stuttering during use. as mentioned earlier, I currently do not have the energy to find the root cause of the issue. If you are interested, you can try to find some files to compare and test.

Now based on buftype to determine whether to render, possibly solving this issue.

Can confirm, it's fixed now 😁.


Feature Reservation Model and Controller

Description

Create reservation model
Create reservation controller
Create reservation endpoints
Include jwt helper function
Create associations between user and reservation model

Hi @78fatemanazari ,
Your ticket is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉

Highlights

No linter errors ✔
Correct GitFlow ✔
Good implementations ✔
Model, Controller and End points created properly  ✔

Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.


Add jest support for unit testing

This adds in jest unit testing following the instructions from quasar.
While this supports the ability to unit test Vue components, I think the best use case for unit testing in this application will be for a lot of the code written for invoices, mints, tokens, etc... (the "mission critical" code).
This should hopefully help increase the stability of the application as we add appropriate tests, and will also give confidence to new contributors that they aren't breaking anything.

This again is a fantastic contribution!

How do you actually run the tests?


phone-plugin for es v5.1.1

This work is based on the code from https://github.com/lars-n/elasticsearch-phone for elasticsearch v2, so the diff shown here includes changes between MyPureCloud/elasticsearch-phone and lars-n/elasticsearch-phone as well.

lets bump the project pom to match the ES version


Conditional Required in Schema form

I have to handle a scenario where I have some fields in my form if any of them is filled other all fields become required.
Is there any way by which we can mark conditional Required in such scenario?

Namaste Kritika ji,
Kindly check the contributing.md file before submitting a bug. This seems some logical problem not an issue in angular-schema-form. Kindly check stackoverflow for more relevant problems and solutions.

@sonikritika569 you can do this using the calculate add-on to set a value which you then add to the condition on all fields which you want to show to make them show.


Pinned tabls close

If I have pinned tabs and I open another tab that is not pinned, closing this last tab removes the pinned tabs from the list.

Hi @PedroGrimalt ,
are you able to record this behavior?
When I try on my installation this works correctly, but I found bug when using Close All function, then pinned tab was removed.
It would help a lot in reproducing the issue.
Perfect would be recording of opening the 1st tab, pinning, then opening the 2nd tab and closing.

Sorry but I think github has cut the attachment. Can you come into this issue and attach file manually?

Ok
https://github.com/fidley/VerticalTabs/assets/62426885/a317f078-d07d-47ff-ac11-fdba74e835cc

Thanks! Now it's clear.

Sorry, was automatically closed by pull request. Please restart Eclipse and update the plugin. Should be corrected.

Fantastic!
Good job, works perfectly!

Thanks :)


Is it possible to let luacheck know about/find imported files?

When using something like the Playdate SDK, a given Lua file will import others like so:
import 'CoreLibs/graphics'
import "CoreLibs/string"
import "CoreLibs/strict"

but it seems like luacheck doesn't support/know about the import statement and therefore those files are ignored. This generates incorrect warnings like so:
    Source/main.lua:44:5: accessing undefined variable assert
    Source/main.lua:79:22: accessing undefined variable string

What is the best way to make luacheck aware of what those import files contain?

Luacheck doesn't evaluate code. In order to do what you are suggesting it would have to be a Lua VM and run the code — there would be no other way to effectively catch all the ways code could be loaded. This isn't going to happen.
The way to deal with these warnings in your project is to define an allowed list of globals in your .luacheckrc. That being said it is a bit surprising that your are getting warnings for string, and assort as those are standard Lua builtins. Are you using any Lua presets at or do you have them cleared for use with Playdate? Or do we perhaps need a default configuration that covers Playdate variables by default?

Luacheck doesn't evaluate code. In order to do what you are suggesting it would have to be a Lua VM and run the code — there would be no other way to effectively catch all the ways code could be loaded. This isn't going to happen.

That makes sense. I was thinking more of a parsing solution where luacheck could be told to parse those files first so that it has context before parsing the code using the SDK.

The way to deal with these warnings in your project is to define an allowed list of globals in your .luacheckrc.

That's the direction I was heading in.

Are you using any Lua presets at or do you have them cleared for use with Playdate? Or do we perhaps need a default configuration that covers Playdate variables by default?

I simplified the case but just running luacheck from the cmdline without any config file and you are correct those are not causing warnings anymore. So my .luacheckrc is what is causing the problem here. User error :)
std = {
    globals = { "playdate" }, -- these globals can be set and accessed.
    read_globals = { "import" } -- these globals can only be accessed.
}

Try not overwriting the std declaration:
std = "min",
globals = { "playdate" }, -- these globals can be set and accessed.
read_globals = { "import" } -- these globals can only be accessed.

Change min to suite the version equivalent the Playdate SDK uses as a base, for example lua52 or lua45 or luajit.
If there are more things in the SDK that aren't covered by those presets, rather than you adding the whole SDK to a preference file lets setup a custom set of standards. For example we have existing ones for LÖVE and NGX as well as a busted mixing to add to any of the above. See the src/luacheck/builtin_standards/ directory for where these names are coming from.
Also luacheck --help has information about things you can use as std in your RC file or --std from the command line.

The "follow imports" issue is basically the same as #36 and won't be addressed.
Adding a set of defaults for Playdate is definitely something we'd consider. I'd be happy to facilitate a PR that added support similarly to the way LÖVE or others are handled. Feel free to open a tracking issue specific to that and/or submit a PR.

Adding a set of defaults for Playdate is definitely something we'd consider. I'd be happy to facilitate a PR that added support similarly to the way LÖVE or others are handled. Feel free to open a tracking issue specific to that and/or submit a PR.

I'd be happy to look into that. Thanks for the help and keep up the great work.

On the subject, be sure to see #53 about operators and the recent PR to add them in #66. You might find people interested in helping collaborate on a set of presets for Playdate as well.


Separating Statements of Lemmas and the Rewrite Rules they represent

Lemma hadamard_color_change_Z : forall nIn nOut α,
    (ZX_semantics (Compose (nH nIn) (Z_Spider nIn nOut α))) =
    Cexp (PI / 4 * (INR nIn - INR nOut))) .* ZX_semantics (Compose (X_Spider nIn nOut α) (nH nOut))

becomes two statements, a Definition which defines the function which swaps colors, and a lemma which proves that it works the same as hadamards.

Maybe this would be better written as some sort of optimization pass, which tries to apply some change we know holds by a rule we have proven?


[BUG]: UNAVAILABLE: Internal: onnx runtime error 7: Load model from /models/triton-model-repo/log-parsing-onnx/1/model.onnx failed:Protobuf parsing failed.

Version
23.07.02-runtime
Which installation method(s) does this occur on?
Docker
Describe the bug.
I just want to run this example: Example cyBERT Morpheus Pipeline for Apache Log Parsing
But keep getting:
base) nyck33@nyck33-ubuntu2204:/media/nyck33/StorageSSD/cybersecurity/Morpheus$ docker run --rm -ti --gpus=all -p8000:8000 -p8001:8001 -p8002:8002 -v $PWD/models:/models nvcr.io/nvidia/tritonserver:23.06-py3 tritonserver --model-repository=/models/triton-model-repo --exit-on-error=false --model-control-mode=explicit --load-model log-parsing-onnx

=============================
== Triton Inference Server ==
=============================

NVIDIA Release 23.06 (build 62878575)
Triton Server Version 2.35.0

Copyright (c) 2018-2023, NVIDIA CORPORATION & AFFILIATES.  All rights reserved.

Various files include modifications (c) NVIDIA CORPORATION & AFFILIATES.  All rights reserved.

This container image and its contents are governed by the NVIDIA Deep Learning Container License.
By pulling and using the container, you accept the terms and conditions of this license:
https://developer.nvidia.com/ngc/nvidia-deep-learning-container-license

I0915 12:39:29.184291 1 libtorch.cc:2253] TRITONBACKEND_Initialize: pytorch
I0915 12:39:29.184324 1 libtorch.cc:2263] Triton TRITONBACKEND API version: 1.13
I0915 12:39:29.184331 1 libtorch.cc:2269] 'pytorch' TRITONBACKEND API version: 1.13
I0915 12:39:29.305838 1 pinned_memory_manager.cc:240] Pinned memory pool is created at '0x7f802e000000' with size 268435456
I0915 12:39:29.306165 1 cuda_memory_manager.cc:105] CUDA memory pool is created on device 0 with size 67108864
I0915 12:39:29.310915 1 model_lifecycle.cc:462] loading: log-parsing-onnx:1
I0915 12:39:29.311971 1 onnxruntime.cc:2530] TRITONBACKEND_Initialize: onnxruntime
I0915 12:39:29.311983 1 onnxruntime.cc:2540] Triton TRITONBACKEND API version: 1.13
I0915 12:39:29.311988 1 onnxruntime.cc:2546] 'onnxruntime' TRITONBACKEND API version: 1.13
I0915 12:39:29.311993 1 onnxruntime.cc:2576] backend configuration:
{"cmdline":{"auto-complete-config":"true","backend-directory":"/opt/tritonserver/backends","min-compute-capability":"6.000000","default-max-batch-size":"4"}}
I0915 12:39:29.321810 1 onnxruntime.cc:2641] TRITONBACKEND_ModelInitialize: log-parsing-onnx (version 1)
I0915 12:39:29.323132 1 onnxruntime.cc:692] skipping model configuration auto-complete for 'log-parsing-onnx': inputs and outputs already specified
I0915 12:39:29.323509 1 onnxruntime.cc:2702] TRITONBACKEND_ModelInstanceInitialize: log-parsing-onnx (GPU device 0)
I0915 12:39:29.328852 1 onnxruntime.cc:2754] TRITONBACKEND_ModelInstanceFinalize: delete instance state
I0915 12:39:29.328869 1 onnxruntime.cc:2682] TRITONBACKEND_ModelFinalize: delete model state
E0915 12:39:29.328881 1 model_lifecycle.cc:626] failed to load 'log-parsing-onnx' version 1: Internal: onnx runtime error 7: Load model from /models/triton-model-repo/log-parsing-onnx/1/model.onnx failed:Protobuf parsing failed.
I0915 12:39:29.328890 1 model_lifecycle.cc:753] failed to load 'log-parsing-onnx'
I0915 12:39:29.328953 1 server.cc:603]
+------------------+------+
| Repository Agent | Path |
+------------------+------+
+------------------+------+

I0915 12:39:29.329000 1 server.cc:630]
+-------------+-----------------------------------------------------------------+------------------------------------------------------------------------+
| Backend     | Path                                                            | Config                                                                 |
+-------------+-----------------------------------------------------------------+------------------------------------------------------------------------+
| pytorch     | /opt/tritonserver/backends/pytorch/libtriton_pytorch.so         | {}                                                                     |
| onnxruntime | /opt/tritonserver/backends/onnxruntime/libtriton_onnxruntime.so | {"cmdline":{"auto-complete-config":"true","backend-directory":"/opt/tr |
|             |                                                                 | itonserver/backends","min-compute-capability":"6.000000","default-max- |
|             |                                                                 | batch-size":"4"}}                                                      |
+-------------+-----------------------------------------------------------------+------------------------------------------------------------------------+

I0915 12:39:29.329041 1 server.cc:673]
+------------------+---------+---------------------------------------------------------------------------------------------------------------------------+
| Model            | Version | Status                                                                                |
+------------------+---------+---------------------------------------------------------------------------------------------------------------------------+
| log-parsing-onnx | 1       | UNAVAILABLE: Internal: onnx runtime error 7: Load model from /models/triton-model-repo/log-parsing-onnx/1/model.onnx fail |
|                  |         | ed:Protobuf parsing failed.                                                                                |
+------------------+---------+---------------------------------------------------------------------------------------------------------------------------+

I0915 12:39:29.355165 1 metrics.cc:808] Collecting metrics for GPU 0: NVIDIA GeForce GTX 1650
I0915 12:39:29.355437 1 metrics.cc:701] Collecting CPU metrics
I0915 12:39:29.355615 1 tritonserver.cc:2385]
+----------------------------------+----------------------------------------------------------------------------------------------------------------------+
| Option                           | Value                                                                                |
+----------------------------------+----------------------------------------------------------------------------------------------------------------------+
| server_id                        | triton                                                                                |
| server_version                   | 2.35.0                                                                                |
| server_extensions                | classification sequence model_repository model_repository(unload_dependents) schedule_policy model_configuration sys |
|                                  | tem_shared_memory cuda_shared_memory binary_tensor_data parameters statistics trace logging                          |
| model_repository_path[0]         | /models/triton-model-repo                                                                                |
| model_control_mode               | MODE_EXPLICIT                                                                                |
| startup_models_0                 | log-parsing-onnx                                                                                |
| strict_model_config              | 0                                                                                |
| rate_limit                       | OFF                                                                                |
| pinned_memory_pool_byte_size     | 268435456                                                                                |
| cuda_memory_pool_byte_size{0}    | 67108864                                                                                |
| min_supported_compute_capability | 6.0                                                                                |
| strict_readiness                 | 1                                                                                |
| exit_timeout                     | 30                                                                                |
| cache_enabled                    | 0                                                                                |
+----------------------------------+----------------------------------------------------------------------------------------------------------------------+

E0915 12:39:29.355639 1 tritonserver.cc:2394] Invalid argument: load failed for model 'log-parsing-onnx': version 1 is at UNAVAILABLE state: Internal: onnx runtime error 7: Load model from /models/triton-model-repo/log-parsing-onnx/1/model.onnx failed:Protobuf parsing failed.;

I0915 12:39:29.356564 1 grpc_server.cc:2445] Started GRPCInferenceService at <IP_ADDRESS>:8001
I0915 12:39:29.356707 1 http_server.cc:3555] Started HTTPService at <IP_ADDRESS>:8000
I0915 12:39:29.398514 1 http_server.cc:185] Started Metrics Service at <IP_ADDRESS>:8002
W0915 12:39:30.357324 1 metrics.cc:573] Unable to get power limit for GPU 0. Status:Success, value:0.000000
W0915 12:39:31.357703 1 metrics.cc:573] Unable to get power limit for GPU 0. Status:Success, value:0.000000
W0915 12:39:32.359668 1 metrics.cc:573] Unable to get power limit for GPU 0. Status:Success, value:0.000000

so tried to check the onnx's integrity with
morpheus) nyck33@nyck33-ubuntu2204:/media/nyck33/StorageSSD/cybersecurity/Morpheus/models/triton-model-repo$ python3
Python 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import onnx
>>> onnx_model = onnx.load("triton-model-repo/log-parsing-onnx/1/model.onnx")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/nyck33/miniconda3/envs/morpheus/lib/python3.10/site-packages/onnx/__init__.py", line 169, in load_model
    s = _load_bytes(f)
  File "/home/nyck33/miniconda3/envs/morpheus/lib/python3.10/site-packages/onnx/__init__.py", line 73, in _load_bytes
    with open(typing.cast(str, f), "rb") as readable:
FileNotFoundError: [Errno 2] No such file or directory: 'triton-model-repo/log-parsing-onnx/1/model.onnx'
>>> onnx_model = onnx.load("log-parsing-onnx/1/model.onnx")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/nyck33/miniconda3/envs/morpheus/lib/python3.10/site-packages/onnx/__init__.py", line 170, in load_model
    model = load_model_from_string(s, format=format)
  File "/home/nyck33/miniconda3/envs/morpheus/lib/python3.10/site-packages/onnx/__init__.py", line 212, in load_model_from_string
    return _deserialize(s, ModelProto())
  File "/home/nyck33/miniconda3/envs/morpheus/lib/python3.10/site-packages/onnx/__init__.py", line 143, in _deserialize
    decoded = typing.cast(Optional[int], proto.ParseFromString(s))
google.protobuf.message.DecodeError: Error parsing message
>>> onnx_model = onnx.load("media/nyck33/StorageSSD/cybersecurity/Morpheus/models/triton-model-repo/log-parsing-onnx/1/model.onnx")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/nyck33/miniconda3/envs/morpheus/lib/python3.10/site-packages/onnx/__init__.py", line 169, in load_model
    s = _load_bytes(f)
  File "/home/nyck33/miniconda3/envs/morpheus/lib/python3.10/site-packages/onnx/__init__.py", line 73, in _load_bytes
    with open(typing.cast(str, f), "rb") as readable:
FileNotFoundError: [Errno 2] No such file or directory: 'media/nyck33/StorageSSD/cybersecurity/Morpheus/models/triton-model-repo/log-parsing-onnx/1/model.onnx'
>>> onnx_model = onnx.load("/media/nyck33/StorageSSD/cybersecurity/Morpheus/models/triton-model-repo/log-parsing-onnx/1/model.onnx")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/nyck33/miniconda3/envs/morpheus/lib/python3.10/site-packages/onnx/__init__.py", line 170, in load_model
    model = load_model_from_string(s, format=format)
  File "/home/nyck33/miniconda3/envs/morpheus/lib/python3.10/site-packages/onnx/__init__.py", line 212, in load_model_from_string
    return _deserialize(s, ModelProto())
  File "/home/nyck33/miniconda3/envs/morpheus/lib/python3.10/site-packages/onnx/__init__.py", line 143, in _deserialize
    decoded = typing.cast(Optional[int], proto.ParseFromString(s))
google.protobuf.message.DecodeError: Error parsing message
>>> import onnx
>>> print(onnx.__version__)
1.14.1
>>> import google.protobuf
>>> print(google.protobuf.__version__)
4.24.3
>>> pip install --upgrade onnx
  File "<stdin>", line 1
    pip install --upgrade onnx
        ^^^^^^^
SyntaxError: invalid syntax
>>> pip install --upgrade onnx
  File "<stdin>", line 1
    pip install --upgrade onnx
        ^^^^^^^
SyntaxError: invalid syntax
>>> pip install -U onnx
  File "<stdin>", line 1
    pip install -U onnx
        ^^^^^^^
SyntaxError: invalid syntax

But that didn't work either.
Minimum reproducible example
See above, maybe the onnx is getting corrupted when I clone the repo?  Or it's bad to begin with?

Relevant log output
Click here to see error details
[Paste the error here, it will be hidden by default]

Full env printout
Click here to see environment details
[Paste the results of print_env.sh here, it will be hidden by default]

Other/Misc.
No response
Code of Conduct

[X] I agree to follow Morpheus' Code of Conduct
[X] I have searched the open bugs and have found no duplicates for this bug report

Hi @nyck33!
Thanks for submitting this issue - our team has been notified and we'll get back to you as soon as we can!
In the mean time, feel free to add any relevant information to this issue.

@nyck33 Is this issue occurring when using WSL2? Or a native Ubuntu installation?

@exactlyallan  actually I got tihs working on Native Ubuntu by first running an morpheus container with the dev null appended to the docker run command so that it persists, then exec into the container, then git clone the Morpheus rrepo to the root of the container, then running the script to get the models and examples, then running a Trition inference server on the host and then running the command listed in the log parsing example.  So it works but this feels a bit convoluted.  It may have occurred on WSL2 but now am solely working on native Ubuntu.

@exactlyallan I maybe should have made a new issue but please take a look here for a different problem I faced: https://github.com/nv-morpheus/Morpheus/issues/1187#issuecomment-1722375151


[FLINK-13505][docs-zh] Translate "Java Lambda Expressions" page into Chinese

Capitalized all the "lambda".
PTAL @klion26 @wuchong

@YngwieWang thanks for your contribution, I left some comments

Thanks for your review very much. I made some changes. PTAL


Alerts not closing

Could be wrong (maybe I've messed up my end), but seems clicking the x on alerts no longer closes the alert box.
Best wishes
Lee

Must remember to inc app.js :)