time: provide a complete RFC3339 time format parse function

The W3C profile of the ISO 8601 format, that the IETF formalized in RFC3339, specifies two timezone formats

"Z", meaning that the time is given in UTC, without local timezone info
with the local time offset to UTC, allowing to compute both UTC time and local time. The offset can be either positive or negative

The two timezone formats are clearly specified both in the W3C and the IETF document.
W3C:
TZD  = time zone designator (Z or +hh:mm or -hh:mm)

IETF RFC3339 ABNF:
time-zone       = "Z" / time-numoffset
time-numoffset  = ("+" / "-") time-hour [[":"] time-minute]

/ means OR in ABNF, as is evident from the time-numoffset definition, that tells you that ISO 8601 timezone offset can be positive or negative.
The golang RFC3339 time format is non conformant, first because it tries to use "Z" in conjunction with timezone offsets (when the meaning of "Z" is that no timezone offset was provided), and second, because it only allows positive offsets, when the W3C ISO 8601 profile and RFC3339 are both very clear offsets can be negative.
As a result, go is unable to parse  RFC3339 compliant date times such as the ones outputed by date --iso-8601=seconds
$ TZ="America/Los_Angeles" date --iso-8601=seconds
2019-03-28T08:14:26-0700
$ TZ="Europe/Paris" date --iso-8601=seconds
2019-03-28T16:15:04+0100

parsing time "2019-03-28T08:14:26-0700" as "2006-01-02T15:04:05Z07:00": cannot parse "-0700" as "Z07:00"

Please fix the RFC3339 time format in Go or, if the mistake is too old to be easily removed, add a new RFC3339std format that is conformant to the RFC 3339 and ISO 8601, as used by other software in IJSON, XML, etc.

The constant time.RFC3339 has a colon in the timezone offset. Your example input does not. That seems to be the only problem here.
I don't see a way to make the current time.Parse format parse timezones with both colons and without colons.

Ok, thanks, the error was clear as mud
Nevertheless RFC 3339 ABNF do specify that the colon is optional
time-numoffset  = ("+" / "-") time-hour [[":"] time-minute]

So timestamps without the colon are conformant to  RFC 3339 (and the date command, for example, will omit them by default)

The documentation says RFC3339, RFC822, RFC822Z, RFC1123, and RFC1123Z are useful for formatting; when used with time.Parse they do not accept all the time formats permitted by the RFCs.  I'm not sure there is anything to do here.

Well, there's a missing semicolon in that string. That's worth a quick CL.

While I agree the optional parts of RFC3339 are a major PITA (the W3C was much smarter than the IETF when it defined a single canonical form that only varied depending on the precision of the desired timestamps), those optional parts do exist, and people do write software with their own understanding of the options to include or exclude, and this software outputs timestamps, that Go software can consume later, so the Go parsing part of RFC3339 timestamps at least should accept all the variations defined in the RFC.
Because if the parsing is not as permissive as allowed by the spec, individual Go devs will have to reinvent separately timestamp normalising rules, which is not efficient, and what the RFCs are supposed to avoid.
And please not I am not talking about all the time RFCs here. Only the most recent, that represents the state of the art in writing interoperable time. Telling projects to upgrade to RFC3339 to be sure their time stings are parsed by Go and other software stacks is perfectly fine. But the RFC3339 support needs to be solid and complete to do that.

@nim-nim If I understand you correctly, you are asking for something that time.Parse is unable to implement.  There is certainly nothing wrong with writing a function that can parse all valid RFC3339 time strings.  But that function probably shouldn't live in the time package.  The definition of RFC3339 in the time package is a minor convenience for use with time.Time.Format, not time.Parse.

Just as info: The date version 8.28 on my system prints the colon in the offset with --iso-8601=seconds. So the format may have changed between versions.
Format with the  RFC3339 constant creates a correct RFC3339 time stamp, but Parse is not able to process all valid time stamps according to section 5.6 of the RFC or the ABNF in the appendix. (Mainly because ABNF strings are case-insensitive and so lower-case t and z must be supported.) It also cannot parse all valid ISO8601 extended format time stamps since the time stamp may omit the time zone or use only a time offset providing hours.
I agree with @ianlancetaylor that Parse cannot support all variants of RFC3339 and a special parse5r function for that purpose would be required.

@ulikunitz @ianlancetaylor Then a suppose a separate function is needed to Go can consume RFC3339-compliant outputs produced by other software :(

It looks like if you want to parse an RFC3339 time without a colon, you can use:
RFC3339NoColon = "2006-01-02T15:04:05Z0700"

The broad claim in the initial report, that Go cannot parse RFC3339 times, is clearly wrong.
If you want to parse any one of a variety of possible formats, call time.Parse with each format
you want to accept.
I don't see much to do here.

But that requires to make every Go software, that consumes things with RFC3339 timestamps, to be aware of all the RFC3339 dialects, or to hope all the other software is works with keeps to a single RFC3339 variant. The second option is unrealistic: different software will output different RFC3339 timestamps, and even the same software can change its RFC3339 options depending on the deployed version.

What's the recommended pattern for 2019-04-09T16:38:44.743+0000?  (timezone could be negative offset as well).  Does this have an "out-of-the-box" solution?  (serendipitiously relates to linked issue a few hours ago)

@nim-nim I believe you are mistaken about RFC 3339 saying the colon is optional in the timezone. If you look at section 5.6 (https://tools.ietf.org/html/rfc3339#section-5.6), where the ABNF is defined for RFC 3339, it says the colon is mandatory:
time-numoffset  = ("+" / "-") time-hour ":" time-minute

I think the section you pulled from was Appendix A (https://tools.ietf.org/html/rfc3339#appendix-A), which describes the ABNF of ISO8601. ISO8601 is more permissive, and does not require colons anywhere.
time-numoffset    = ("+" / "-") time-hour [[":"] time-minute]

Re-reading the RFC, I think you're right, I was tricked by the double ABNF in the document.
Thanks a lot for the verification.


[qhull] Fix target cannot be found by cmake

When we using find_package(Qhull CONFIG REQUIRED) to find Qhull, it will always use QhullTargets-debug.cmake and all the targets are not found.
Since before exporting targets, all libs are added suffix -d if build debug type.
I remove the suffix -d  and also do the related changes.
Related issue #9836
Note: No feature needs to test.

Ran into this issue today. Any news when it could be fixed? Thank you!

@jafrado thanks for your feedback.
I'm so sorry that I missed to add new patch. Have updated now.
Could you please update and try it again?

@NancyLi1013 - thank you for your fix, looks good. However, now VTK with QT and OpenGL Is broken. Let me raise a separate PR for that one and send you the fix for VTK- target is PCL+QTOpenGL...

Hi @jafrado
Could you please help confirm if you have updated to the latest commits?
I noticed that there are still some targets that contain the suffix -d in above error info.
I can confirm you used old ***targets.cmake file.
Please double check this.
Thanks.

@NancyLi1013 Thanks for looking into it.
It seems that when I configure PCL it find, but find the release version as both release and debug:
QHULL found (include: D:/libraries/vcpkg/installed/x64-windows/include, lib: optimized;D:/libraries/vcpkg/installed/x64-windows/lib/qhull_p.lib;debug;D:/libraries/vcpkg/installed/x64-windows/lib/qhull_p.lib)
My small test project only find the includes - investigating how to add the libraries as well.

@larshg - thank you so much for finding this first; I'm now trying to build all PCL packages using vcpkg as well. Running into the same issue.
@NancyLi1013 - thanks, yes, I did update my repo and include all of your changes. If you have the time, could you test the sample qhull test application which is representative of what Lars and I are trying to get working. I did test this with the PCL pre-installed (1.9.1) and I also tested this both on Linux and Windows with my build. If we can get the QHull to work correctly with vcpkg, we could use vcpkg for everything!
Here is my test app, I just added it: https://github.com/jafrado/qhulltest

@NancyLi1013 - just tried from current master, same thing:
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:9 (set_property):
set_property could not find TARGET Qhull::qhullcpp_d.  Perhaps it has not
yet been created.
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:10 (set_target_properties):
set_target_properties Can not find target to add properties to:
Qhull::qhullcpp_d
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:19 (set_property):
set_property could not find TARGET Qhull::qhullstatic_d.  Perhaps it has
not yet been created.
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:20 (set_target_properties):
set_target_properties Can not find target to add properties to:
Qhull::qhullstatic_d
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:29 (set_property):
set_property could not find TARGET Qhull::qhullstatic_rd.  Perhaps it has
not yet been created.
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:30 (set_target_properties):
set_target_properties Can not find target to add properties to:
Qhull::qhullstatic_rd
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:39 (set_property):
set_property could not find TARGET Qhull::qhull_rd.  Perhaps it has not yet
been created.
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:40 (set_target_properties):
set_target_properties Can not find target to add properties to:
Qhull::qhull_rd
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:103 (set_property):
set_property could not find TARGET Qhull::qhull_d.  Perhaps it has not yet
been created.
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:104 (set_target_properties):
set_target_properties Can not find target to add properties to:
Qhull::qhull_d
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:113 (set_property):
set_property could not find TARGET Qhull::qhull_pd.  Perhaps it has not yet
been created.
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets-debug.cmake:114 (set_target_properties):
set_target_properties Can not find target to add properties to:
Qhull::qhull_pd
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:140 (include)
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
CMake Error at C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake:150 (message):
The imported target "Qhull::qhullcpp_d" references the file
 "C:/msft/vcpkg/installed/x64-windows/share/qhull/../../debug/lib/qhullcpp_d.lib"

but this file does not exist.  Possible reasons include:

The file was deleted, renamed, or moved to another location.

An install or uninstall procedure did not complete successfully.

The installation package was faulty and contained
"C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullTargets.cmake"

but not all the files it references.
Call Stack (most recent call first):
C:/msft/vcpkg/installed/x64-windows/share/qhull/QhullConfig.cmake:1 (include)
CMakeLists.txt:25 (find_package)
The version I compiled works fine, but with my app and the test app I just sent you. Please try my test app after doing:
vcpkg install qhull --triplet x64-windows
vcpkg install pcl[opengl] pcl[qt] pcl[pcap] pcl[tools] pcl --triplet x64-windows
It should compile and run as in the example I provided here:
https://github.com/jafrado/qhulltest

Hi @NancyLi1013 - could you take a look? Thanks.

@jafrado you wrote you used latest master, but have you explicitly merged this PR as well?

@larshg - I pulled master last Friday and tried to build the sample. No joy. However, if I build qhull by hand (manually via cmake-gui) and use this instead, it works fine. Did you get it working? Maybe there is some trick  :)

Hi @jafrado and @larshg
thanks for your info about this.
I will check this again and test the issue you provided above. But in fact, there should be no the suffix -d in debug mode. Since I have removed it.

Hi @NancyLi1013,
Some good news, I think I figured out what was wrong. On my system, I had two installs of vcpkg, one in c:\vcpkg and the other in c:\msft\vcpkg - now to answer your question and that from @larshg - I did patch my local vcpkg build in both, with your changes, however, I got the strange errors you see above.
Now here is where it gets interesting. I deleted my c:\msft\vcpkg (and there is another issue with that in that you can't remove wildcards), but alas I wrote a .bat file and deleted everything. I then went back and rebuild EVERYTHING from c:\vcpkg and when completed, I did the usual "vcpkg integrate install"
Guess what! It works now ... I am sorry for any confusion this caused, but it seems like there are now a couple mroe issues - 1) you can't have two copies of vcpkg on your system (even if you only did vcpkg integrate install it somehow gets screwed up) 2) reg-ex doesn't work.
To recreate my whole dev environment from scratch, here is what I use to build:
vcpkg install eigen3 flann gtest qhull --triplet x64-windows
vcpkg install vtk[qtopengl] --triplet x64-windows
vcpkg install pcl[opengl] pcl[qt] pcl[pcap] pcl[tools] pcl --triplet x64-windows --recurse
vcpkg install opencv --triplet x64-windows

Then, to build PCL app and configure the qhulltest I listed above:
C:\src\qhulltest\build>cmake .. -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake cmake .. -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_APPLOCAL_DEPS=ON -DPCL_BUILD_WITH_BOOST_DYNAMIC_LINKING_WIN32=ON -DPCL_BUILD_WITH_FLANN_DYNAMIC_LINKING_WIN32=ON -DPCL_BUILD_WITH_QHULL_DYNAMIC_LINKING_WIN32=ON -DBUILD_global_tests=ON -DBUILD_tools=OFF -DBUILD_surface_on_nurbs=ON
C:\src\qhulltest\build>devenv /rebuild Release qhull_gpf_test.sln

It works and generates an exe in:
Release\qhull_gpf_test.exe

Regarding the debug postfix:
I use CMAKE_DEBUG_POSTFIX="d" for my build options. In most cases, applications correctly set the suffix for debug builds to include "d" at the end. When you set this CMake variable it ensures that everthing works. I guess you're saying I don't need that.
Anyhow, if you could test out the above and build the app; please commit the changes and sorry for any confusion this caused. Thank you very much!

@larshg - yes, I did patch it. I found out you can't have more than one vcpkg in your system and I could build today with a clean vcpkg install - I guess there can be only one, thank you!

@NancyLi1013  yes, I noticed that the library names are the same, but paths as well.
Shouldn't the debug library find the one on debug\lib folder instead?

@jafrado thanks for your so detailed description and test about this issue.
First, it is possible to clone two vcpkgs. When you used the library in different directories, you need to update toolchain to new directory.
I am testing the app you provided above. I will tell you the result once the test is end.
@larshg as you said, the debug library should find the one on debug\lib folder. If not like this, please post the error info or describe it more clearly. I also will check this later.
Thanks.

Well, there is no error per se. Only that it find the same folder path as I posted earlier.
It adds the same path to both debug and release.

@NancyLi1013 - thank you for looking into this; well, I have not had any success with two copies of vcpkg, that sent me out in the wrong direction so I will wait until this issue is fixed before I try that again.
Today I tried testing what I built yesterday. A few things to mention:

you only need to build the sample app (https://github.com/jafrado/qhulltest) as below:

C:\src\qhulltest\build>cmake .. -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake
C:\src\qhulltest\build>devenv /rebuild Release qhull_gpf_test.sln
C:\src\qhulltest\build>devenv /rebuild Debug qhull_gpf_test.sln

That builds everything from scratch with your patch now and links correctly.
However, NEITHER THE RELEASE OR DEBUG VERSION RUNS!
In Debug build, it does not find lz4.dll, or libpng16.dll; however, both lz4d.dll and libpng16d.dll are in the Debug directory. Copying the non-debug versions it is looking for (lz4.dll and libpng16.dll) gives the runtime error:
The procedure entry point inflateValidate could not be located in the dynamic link library C:\src\qhulltest\build\Debug\libpng16.dll

See below images:

In Release mode, the app simply crashes with a back-trace that makes no sense. See image below:

So as @larshg said earlier, the debug mode is broken; and unfortunately it seems I still cannot build pcl/qhull with vcpkg.  Looking forward to your findings (and fix) for qhull with the sample app.
Thank you very much!

Hi @jafrado
Sorry for the late reply.
I have tested the sample app you provided above.
Of course, I found something wrong too. lz4 and libpng can't be found when execute *.exe.
This only happened when building debug type.
But I don't agree with that this is related with qhull.
Since pcl depends on qhull ,vtk, libpng. vtk depends on lz4, libpng. it doesn't mater with qhull.
It might be the way that is to use lz4 and libpng  in pcl or vtk is not correct.
Could you please check it again?

Hi @NancyLi1013,
No problem; thank you for your reply. Well, I did check it again this morning, it doesn't make sense that the release build fails, and I realized I had my command line argument wrong in the debug arguments (it requires a PCD file as in the documentation) and also, I missed the VC Runtime DLL's, these somehow do not get copied with devenv:

C:\src\qhulltest\build\Release>dumpbin /dependents qhull_gpf_test.exe
Microsoft (R) COFF/PE Dumper Version 14.24.28314.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file qhull_gpf_test.exe

File Type: EXECUTABLE IMAGE

  Image has the following dependencies:

    vtkRenderingOpenGL2-8.2.dll
    vtkInteractionStyle-8.2.dll
    vtkRenderingFreeType-8.2.dll
    vtkCommonCore-8.2.dll
    pcl_io_release.dll
    pcl_common_release.dll
    KERNEL32.dll
    ADVAPI32.dll
    MSVCP140.dll
    VCRUNTIME140.dll
    VCRUNTIME140_1.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll

  Summary

        4000 .data
        4000 .pdata
       13000 .rdata
        1000 .reloc
        1000 .rsrc
       4E000 .text

The files below were missing so I copied them into the release directory:

    KERNEL32.dll
    ADVAPI32.dll
    MSVCP140.dll
    VCRUNTIME140.dll
    VCRUNTIME140_1.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll

And now when you run from command line:

C:\src\qhulltest\build\Release>qhull_gpf_test.exe c:\src\qhulltest\countertop\1.pcd
Planar segmentation:101279 points
Convex hull:18 points
Prism:93461 points

C:\src\qhulltest\build\Release>

(Press 'r' to resize and recenter the point cloud in PCL Viewer, and then 'q' to quit)
So the issue is exactly as @larshg mentioned, the path to the debug libraries is incorrect.
To demonstrate that, all you need to do is issue these commands in your debug directory:

C:\src\qhulltest\build\Debug>xcopy C:\vcpkg\installed\x64-windows\debug\bin\libpng16d.dll libpng16.dll
Overwrite C:\src\qhulltest\build\Debug\libpng16.dll (Yes/No/All)? y
C:\vcpkg\installed\x64-windows\debug\bin\libpng16d.dll
1 File(s) copied

C:\src\qhulltest\build\Debug>xcopy C:\vcpkg\installed\x64-windows\debug\bin\lz4d.dll lz4.dll
Overwrite C:\src\qhulltest\build\Debug\lz4.dll (Yes/No/All)? y
C:\vcpkg\installed\x64-windows\debug\bin\lz4d.dll
1 File(s) copied

C:\src\qhulltest\build\Debug>qhull_gpf_test.exe c:\src\qhulltest\countertop\1.pcd
Planar segmentation:101279 points
Convex hull:18 points
Prism:93461 points

C:\src\qhulltest\build\Debug>

I think it might be worth testing to see if you add the below flags, it fixes the problem, or at least if we force this then we're guaranteeing that the correct flavor of debug library is built:

C:\src\qhulltest\build>cmake .. -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_DEBUG_POSTFIX=d

Could you check this issue? I just added command line checking to the test app; and just did a commit. I also added an ifdef where you can link with just PCL and VTK and do RANSAC and no Pyramidal extraction/Qhull operations.
Thank you very much!

Hi @NancyLi1013
I think that PCL has a bug in how it finds qhull - after I added qhull like this
its properly added with correct paths to both release and debug version.
@jafrado You can try link to qhull using Qhull::qhull_p or the version that you now would like, ie static version depending on how you build it with PCL.
regards, Lars

Hi @larshg
thanks for your test and info.
I also noticed that the values of QHULL_LIBRARIES  linked are like this:
QHULL_LIBRARIES:optimized;E:/vcpkg/installed/x64-windows/debug/lib/qhull_p.lib;debug;E:/vcpkg/installed/x64-windows/debug/lib/qhull_p.lib
Either in debug type or release type, it seems that both of them target at debug/lib. This is also a bug in the test app that provided by @jafrado .
So could you help check it again to confirm if you used qhull successfully?

@NancyLi1013, @larshg - I use
target_link_libraries(${PROJECT_NAME} ${PCL_LIBRARIES} ${QHULL_LIBRARIES})

and the line that @larshg provided uses:
target_link_libraries(TestQhull Qhull::qhull_p)

It doesn't matter if you use either line, the behavior is the same as my last post and status report. I just confirmed the same.

@NancyLi1013 I think this patch works fine with my minimal example using both dynamic or static linking.
However is there a reason to remove the "d" from debug libraries? Then you can't have both debug and release side by side if it is removed?
As of PCL there needs to be some update for PCL to properly find the correct libraries. Supporting both the old way and the new way with CONFIG.

@NancyLi1013 Can we maybe revive this one, as we have a pending PR at PCL to find qhull with a new method and now we get the above mentioned errors again.
See https://github.com/PointCloudLibrary/pcl/pull/3741 for reference.

@larshg
Sorry for the delay for this PR.
I will check this PR today.

Is there some way to only limit to build only whats required/asked for - right now it build all the different versions, dynamic and static, qhull/qhull_p, qhull_r and tools?

If you have the requirements, it might be better to bring up this to the upstream.

Ah yes, it should probably be part of their CMake script, to enable/disable wanted libraries. Just wanted to reduce required time/cpu/power.

Has there been any progress towards merging this?

The current solution is not suitable. So it cannot be merged now.

Should we close this PR then?

Thanks for your kindly reminder. It might be better to open a new PR to fix this in the future. So I'm closing this PR now.


Allow announcing of synthetic patterns

Some machines are very stubborn/hard to automate (example: Industrial Foregoing's Dissolution Chamber).
While a crafter facing a chest would allow the computer to query RS about active crafting tasks to find out which recipe to use on the machine, this doesn't allow using fluids directly from RS as is possible with normal processing patterns.

I'm not really sure what you're asking for.
If you've created a pattern and put it into a crafter, then it will be visible via the getPattern/getFluidPattern calls etc.
If you're trying to query the status of the machine itself, you can treat it as a separate peripheral and read its inventory and/or tank contents through the standard peripheral APIs.

I'm not really sure what you're asking for.
If you've created a pattern and put it into a crafter, then it will be visible via the getPattern/getFluidPattern calls etc.
If you're trying to query the status of the machine itself, you can treat it as a separate peripheral and read its inventory and/or tank contents through the standard peripheral APIs.


User testing interview questions

what would go in a "disaster post"
what information needs to be broadcasted to the community

How are people currently getting information about current disasters
how accessible is that information, what is the process for finding that information

What are the most important pieces of information you want to know when it comes to disasters?
What is a disaster? (what do you think is a disaster)
(floods, landslides, extreme heat, tsunami, unsafe water, lightning?, earthquake, fire, sinkholes?)
What do you know about the Office of Emergency Management for your city?

Interviewed Mollie for bunch more details and find we are on the right track, keep on trecking! closing for now.


C++ implementation

There is no example for C++. The critical headache in C++ is lack of documentation for the header files to access these functions. Worse, some of these methods appear to be supported in C#. That needs to be clearly stated if that is indeed true.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: f050bab3-2598-d27a-ee77-51db6c8be504
Version Independent ID: 10b526d7-df3c-979a-d654-72c573c03d15
Content: DeviceInformation Class (Windows.Devices.Enumeration) - Windows UWP applications
Content Source: https://cpubwin.visualstudio.com/DefaultCollection/windows-uwp/_git/winrt-api-build?path=%2fwinrt-api-build%2fwindows.devices.enumeration.deviceinformation.yml&version=GBlive&_a=contents
Product: uwp
Technology: winrt-reference
Git Login: mcleanbyron
Microsoft Alias: mcleans

Thanks for taking the time to share your feedback and I sincerely apologize for the delayed response. We are in the process of trying to add C++/WinRT code examples to as many articles as possible to provide equivalence with C#, and I will make sure this article is added to our list.


FileNotFound error when running the scenario runner

Hello,
I was tried to run the run_experiment.py with this command, and it gave me the error output below, (I used this fork for scenario runner https://github.com/harplab/scenario_runner/commits/DReyeVR-0.9.13,)

However I checked my data folder and found that the all_route_signs.json did exist

same thing happened when using conda environment
(carla12) C:\VR_testbed\scenario_runner>python run_experiment.py --title name_of_experiment --route srunner/data/routes_debug.xml srunner/data/all_towns_traffic_scenarios1_3_4.json 0 --output --reloadWorld
Starting scenario runner
Recording on file: C:/Users/ascc_/AppData/Local/CarlaUE4/Saved/exp_name_of_experiment_05_29_2023_22_24_20.rec
INFO:  Found the required file in cache!  Carla/Maps/TM/Town02.bin
Preparing scenario: RouteScenario_0
WARNING: Cannot spawn actor vehicle.diamondback.century at position Location(x=185.695465, y=257.345886, z=1.210000)
Skipping scenario 'Scenario4' due to setup error: 'NoneType' object has no attribute 'set_simulate_physics'
Traceback (most recent call last):
  File "C:\VR_testbed\scenario_runner\scenario_runner.py", line 419, in _load_and_run_scenario
    self.manager.load_scenario(scenario, self.agent_instance, config.scenario_number)
  File "C:\VR_testbed\scenario_runner\srunner\scenariomanager\scenario_manager.py", line 123, in load_scenario
    route_signs_list = RouteParser.parse_direction_signs_file(signs_file, self.single_route)
  File "C:\VR_testbed\scenario_runner\srunner\tools\route_parser.py", line 55, in parse_direction_signs_file
    with open(signs_filename, 'r') as f:
FileNotFoundError: [Errno 2] No such file or directory: '..\\data\\all_routes_signs.json'
[Errno 2] No such file or directory: '..\\data\\all_routes_signs.json'
No more scenarios .... Exiting
Stopped scenario runner, Result: False
Stopping recording, file saved to C:/Users/ascc_/AppData/Local/CarlaUE4/Saved/exp_name_of_experiment_05_29_2023_22_24_20.rec

Does anyone have any good suggestion on this problem? Thank you for your patience!

Not sure, it is probably something with the relative paths being messed up for some reason. You can try to fix this by using an absolute path for the file.
But also, instead of using this file (which hardcodes all the sign positions, for routes that have been hand-curated) we'd recommend you instead to use the automatic sign placement that was introduced into the scenario-runner DReyeVR branch recently. If you are on the latest (DReyeVR-0.9.13) branch of our ScenarioRunner fork then it should be used automatically and you can completely ignore the direction-sign file (just comment it out if its giving you trouble).

The error happens because The scenario cannot be loaded for some reason. Are you sure this scenario configuration you have is valid? (route srunner/data/routes_training.xml srunner/data/all_towns_traffic_scenarios.json 9)

If you try this command, does it work or fail similarly?
python scenario_runner.py  --route srunner/data/routes_training.xml srunner/data/all_towns_traffic_scenarios.json 10 --output --timeout 1000 --reloadWorld --sync

I was able to pull this scenario from an existing comment thread, which seemed to work for others.

It still failed and throw the previous errors.
(carla12) C:\VR_testbed\scenario_runner>python scenario_runner.py  --route srunner/data/routes_training.xml srunner/data/all_towns_traffic_scenarios.json 10 --output --timeout 1000 --reloadWorld --sync
scenario_runner.py:98: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
  if LooseVersion(dist.version) < LooseVersion('0.9.12'):
INFO:  Found the required file in cache!  Carla/Maps/TM/Town03.bin
Preparing scenario: RouteScenario_10
Spawning (static.prop.dreyevr_sign_straight) sign 21 at Transform(Location(x=-20.366112, y=210.581940, z=2.000000), Rotation(pitch=360.000000, yaw=89.857056, roll=0.000000))
Spawning (static.prop.dreyevr_sign_left) sign 365 at Transform(Location(x=246.653214, y=80.986641, z=2.082980), Rotation(pitch=359.527618, yaw=1.393250, roll=0.000000))
Spawning (static.prop.dreyevr_sign_straight) sign 432 at Transform(Location(x=185.645752, y=54.999397, z=2.000000), Rotation(pitch=0.000000, yaw=269.852600, roll=0.000000))
Spawning (static.prop.dreyevr_sign_straight) sign 516 at Transform(Location(x=105.771606, y=53.487377, z=2.000000), Rotation(pitch=0.000000, yaw=-90.147385, roll=0.000000))
Spawning (static.prop.dreyevr_sign_right) sign 616 at Transform(Location(x=94.828636, y=70.091522, z=2.000000), Rotation(pitch=0.000000, yaw=53.550362, roll=0.000000))
Spawning (static.prop.dreyevr_sign_right) sign 678 at Transform(Location(x=150.974686, y=66.288628, z=2.000000), Rotation(pitch=360.000000, yaw=89.852615, roll=0.000000))
Spawning (static.prop.dreyevr_sign_straight) sign 895 at Transform(Location(x=21.138271, y=126.940002, z=2.000000), Rotation(pitch=360.000000, yaw=269.182800, roll=0.000000))
Spawning (static.prop.dreyevr_sign_right) sign 978 at Transform(Location(x=-61.208221, y=126.352516, z=2.000000), Rotation(pitch=360.000000, yaw=268.703186, roll=0.000000))
Spawning (static.prop.dreyevr_sign_left) sign 1091 at Transform(Location(x=-73.937134, y=28.531349, z=2.087857), Rotation(pitch=359.246429, yaw=-0.156219, roll=0.000000))
Spawning (static.prop.dreyevr_sign_left) sign 1169 at Transform(Location(x=-134.689957, y=-7.159969, z=2.000000), Rotation(pitch=0.000000, yaw=-449.705322, roll=0.000000))
Spawning (static.prop.dreyevr_sign_goal) sign 1203 at Transform(Location(x=-154.519943, y=22.429756, z=2.000000), Rotation(pitch=0.000000, yaw=180.029846, roll=0.000000))
The scenario cannot be loaded
Traceback (most recent call last):
  File "scenario_runner.py", line 393, in _load_and_run_scenario
    debug_mode=self._args.debug)
  File "C:\VR_testbed\scenario_runner\srunner\scenarios\route_scenario.py", line 171, in __init__
    world, ego_vehicle, self.config, self.route, timeout=self.timeout))
NameError: name 'ego_vehicle' is not defined
name 'ego_vehicle' is not defined
Exception ignored in: <function RouteScenario.__del__ at 0x000001EF1C247730>
Traceback (most recent call last):
  File "C:\VR_testbed\scenario_runner\srunner\scenarios\route_scenario.py", line 605, in __del__
    self.remove_all_actors()
  File "C:\VR_testbed\scenario_runner\srunner\scenarios\basic_scenario.py", line 203, in remove_all_actors
    for i, _ in enumerate(self.other_actors):
AttributeError: 'RouteScenario' object has no attribute 'other_actors'
No more scenarios .... Exiting

Interesting. This shouldn't happen. Are you on the latest version of ScenarioRunner (our Fork: DReyeVR-0.9.13) and DReyeVR? Have you tried building a new instance (of Carla + DReyeVR, you can keep the same UE4) with the dev changes (which we will merge into main soon)

Sounds worth a shot. But do I need to make pythonAPI before the DReyeVR installation and then make PythonAPI again? Because usually there are lots of issues of the origin windows build pipeline.

You can copy over the Build/ folder from one install to the other, so most of the windows build issues should not happen again. But yes, you should rebuild the PythonAPI since we made (slight) changes to it

Thanks for the advice. I do have another question now, I cloned the latest version of scenario runner from your fork. After I run make install in the DReyeVR folder it showed message like this

should I proceed anyways? Just tried to make sure every steps is correct.

you should switch the scenario runner to have the v0.9.13 git branch

It worked! Thank you for your time and patience!


Update Plugin Artifacts Links for v0.137.2

Automated changes by create-pull-request GitHub action

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


Adjust Kafka concurrency during runtime

Is it possible to adjust the listener's concurrency during the run-time of the application ?
I have set X number of listeners in my application.ini file, which are configured during boot up in the @KafkaListener annotation.
@KafkaListener(id = "MyContainer",
                   topics  = MyClass.TOPIC,
                   groupId = MyClass.GROUP_ID,
                   containerFactory = MyClass.CONTAINER_FACTORY,
                   autoStartup = "${kafka.listener.listenMyClass.enabled}",
                   concurrency = "${kafka.listener.listenMyClass.concurrency}")

However, there are times whereby I want to adjust the concurrency during run-time, but that entails having to restart the application which can be problematic during peak hours. I was hoping there might be something in MessageListenerContainer but there does not seem to be anything of interest.
Please advise.

Did you not read the issue template? It clearly states that GitHub issues are not for asking questions; they are for reporting bugs or asking for new features; questions should be asked on Stack Overflow - to help the community as a whole.
The only way to change the concurrency is to stop the container, update its properties and start it again.
If you give the listener an id property, you can use it to retrieve a reference to the container from the KafkaListenerEndpointRegistry bean; you can then stop() it, cast it to a ConcurrentMessageListenerContainer, update the concurrency and start() it.

Closing due to lack of activity; please open a new issue if you are still having issues.


Incomplete error reporting for function expressions in guards

The patterns proposal says it's an error to have a bare (i.e. not enclosed in some kind of brackets) function expression in a guard clause. It specifically says this error applies to all combinations:

Function expressions with => bodies.
Function expressions with {} bodies.
Guards in switch expressions.
Guards in switch statements.
Guards in if-case statements.
Guards in if-case elements.

It appears that the parser implementation currently only reports an error for (a) function expressions with => bodies inside switch expressions, and (b) function expressions with {} bodies inside switch expressions. (a) is the place where the actual ambiguity occurs, so that's good. But the implementation is still out of sync with the spec for guards in other contexts.
I think we probably should stick with the current spec for {} bodies because that same restriction applies to constructor initializers and we definitely want to prohibit {}-bodied function expressions there.
I'm agnostic as to whether we should keep the spec about disallowing bare function expressions in switch statements and if-case, or whether we should tweak the spec to follow the implementation. I could go either way, and I'm happy to defer to @stereotype441 based on the implementation effort.

I'd recommend that we use a narrow scope and only report the situations where it is actually needed (and perhaps a few others, if this has already been implemented and is inconvenient to remove again).
The situation where the error is justified is when an => function literal occurs in a guard of a switch expression. All the other cases would be included for some other reason, e.g., consistency.
However, there is no particular need for consistency. Nobody will think "Oh dear, I wish I could have that error here!" when they're writing one of those other cases. They only need to know about this rule when they get the error, so they won't need to remember anything, they'll just add those parentheses and go on with their life.
A construct like case p when () {.../*I need a whole function body here*/...} (): ... might even be useful. ;-)

I'd recommend that we use a narrow scope and only report the situations where it is actually needed (and perhaps a few others, if this has already been implemented and is inconvenient to remove again).

I'm on board with this.

A construct like case p when () {.../*I need a whole function body here*/...} (): ... might even be useful. ;-)

Yeah, I'm sad that this isn't supported right now.  But supporting it would require a non-trivial amount of parser re-work:

We would have to replace the parser's mayParseFunctionExpressions with something that can track three possible states (allow all function expressions, allow only block-bodied function expressions, allow no function expressions); this involves touching a lot of code that's not related to patterns, so it carries risk of breaking pre-existing functionality.
Some of the parser's disambiguation rules decide whether they are looking at a function expression or not without looking ahead to find the => or { token.  For example, in var x = () async { ... }, the parser knows it's looking at a function expression as soon as it hits the async keyword.  These rules would have to be re-worked to distinguish between the two types of function expressions.

Given that the beta cut is less than a week away, I think we should stick with what's currently implemented: function expressions are prohibited inside the guards of switch expressions.


[tests-only] Bump commit ids for tests

@saw-jan is going to take over this PR and add the remaining expected-failures.

@saw-jan is going to take over this PR and add the remaining expected-failures.

Thanks @saw-jan - I squashed and rebased. This is ready for review and merge.

Thanks @saw-jan - I squashed and rebased. This is ready for review and merge.


Add exit for integration of unit test with CI

Goal:
Run CI tests within the unit test of an object type class. The setup of a test class should be minimal. As a default, the unit test should not run any CI tests. However, it shall be possible to define locally a list of CI tests that should be executed.
Solution:
This PR provides a new exit that can be called from a unit test. In the exit, one or more abapGit test repos (https://github.com/abapGit-tests) are defined that will then be run via abapGit CI (https://github.com/abapGit/CI).
Requirements:

Installation of https://github.com/abapGit/CI
https://github.com/abapGit/CI/pull/80 (not merged yet)

Instructions:
Add the following to the test class of your object type - for example, zcl_abapgit_object_tabl. Side note: This should be mandatory for all object type classes since we require a test repo anyway.
CLASS ltcl_ci DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.

  PUBLIC SECTION.
    METHODS run FOR TESTING.

ENDCLASS.

CLASS ltcl_ci IMPLEMENTATION.
  METHOD run.
    zcl_abapgit_exit=>get_instance( )->run_ci_tests( 'TABL' ).
  ENDMETHOD.
ENDCLASS.

Implement the run_ci_tests method to call CI test run(s).
Example implementation:
  METHOD zif_abapgit_exit~run_ci_tests.

    DATA:
      ls_result      TYPE zif_abapgit_ci_definitions=>ty_result,
      ls_repo_result TYPE zabapgit_ci_result,
      lr_repos       TYPE zcl_abapgit_ci_test_repos=>gty_repo_name_range,
      ls_repos       LIKE LINE OF lr_repos,
      lv_url         TYPE string,
      lx_error       TYPE REF TO zcx_abapgit_exception.

    ls_repos-sign = 'I'.
    ls_repos-option = 'EQ'.

    " >>> Setup: For each object type, list the repos that you want to test
    CASE iv_object.
      WHEN 'TABL'. " Name of object type
        ls_repos-low = 'TABL'.  " Name of repo at https://github.com/abapGit-tests
        APPEND ls_repos TO lr_repos.
        ls_repos-low = 'TABL_foreign_key'.
        APPEND ls_repos TO lr_repos.
    ENDCASE.
    " <<< End of Setup

    IF lines( lr_repos ) = 0.
      RETURN.
    ENDIF.

    TRY.
        ls_result = NEW zcl_abapgit_ci_controller(
          ii_repo_provider = NEW zcl_abapgit_ci_test_repos( CORRESPONDING #( lr_repos[] ) )
          is_options       = VALUE #(
            result_git_repo_url    = ''
            post_errors_to_slack   = abap_false
            slack_oauth_token      = ''
            exec_generic_checks    = abap_false
            exec_repository_checks = abap_true
            repo_check_options = VALUE #(
              check_local         = abap_true
              check_transportable = abap_false
              layer               = ''
            )
          )
        )->run( ).

        " No errors?
        cl_abap_unit_assert=>assert_equals(
          exp = abap_false
          act = ls_result-ci_has_errors ).

        " Check individual repos
        LOOP AT ls_result-repo_result_list INTO ls_repo_result.
          cl_abap_unit_assert=>assert_equals(
            exp = 'OK'
            act = ls_repo_result-create_package ).
          cl_abap_unit_assert=>assert_equals(
            exp = 'OK'
            act = ls_repo_result-clone ).
          cl_abap_unit_assert=>assert_equals(
            exp = 'OK'
            act = ls_repo_result-pull ).
          cl_abap_unit_assert=>assert_equals(
            exp = 'OK'
            act = ls_repo_result-syntax_check ).
          cl_abap_unit_assert=>assert_equals(
            exp = 'OK'
            act = ls_repo_result-object_check ).
          cl_abap_unit_assert=>assert_equals(
            exp = 'OK'
            act = ls_repo_result-purge ).
          cl_abap_unit_assert=>assert_equals(
            exp = 'OK'
            act = ls_repo_result-check_leftovers ).
        ENDLOOP.

      CATCH zcx_abapgit_exception INTO lx_error.
        cl_abap_unit_assert=>fail( ).
    ENDTRY.

  ENDMETHOD.

Obviously depends on what you put in the exit. It runs nothing by default so I put harmless short.
Since the intention is for more risky test, we certainly change it. It’s quite fast though.

Curiosity question: Is there a reason for doing this in a user exit? Personally I'd implement this in a global test class.

and then enable/disable via

There are a few issues that need to be addressed. Correct me if I'm wrong:

We don't want a dependency on the CI repo
We don't want to impact a system in case someone runs all AG unit tests
As a developer/contributor, we want to be able to choose which CI tests to run

A global test class could solve 1. by calling the CI test code dynamically (which is still a dependency) and 2. by using the "dangerous" switch (but just partially since there's only one switch for all unit tests). But how would 3. work without an exit?
How about we use the exit to just ask for the range of repos and put the rest into a global class?

Won't 3 just work automatically? Since the test is registered in the test include of the serializer class the scope of the unit test classes to execute is determined by the tooling (right click on serializer class = just that one, right click on package = all). Or do you mean to specify the repos for the serializers with multiple test cases?

The later. For example, TABL has 10 different test repos. So I think it would be nice to specify which repos in https://github.com/abapGit-tests should be checked. There would also be the case of using your own repo(s) but that's not covered in this PR.

I don't think a dependency is avoidable, and IMO it is not an issue since abapGit-CI is specifically for abapGit. If 10 developers each write their own exits to call CI then we still have 10 dependencies, the difference being that are "someone else's problem".
I think a global TC could either call CI via the API or it can check it's existence. A global TC does not have to test all repos either, it just acts as a proxy.
CLASS ZCL_ABAPGIT_CI_PROXY DEFINITON FOR TESTING
...
  METHODS run_ci_for IMPORTING iv_repo_name.
...

CLASS ltc_ci DEFINITON FOR TESTING.
  PRIVATE SECTION.
    METHODS run_ci FOR TESTING.
...
  METHOD run_ci.
    lo_ci_proxy->run_ci_for( 'TABL' ).
...

Now for the thorny bit: From my brief tests, this is still way too slow to use for TDD. Runtime ~5s via CI vs 0.5s local. Some kind of repo caching would be needed.

change the Ctrl+Shift+F10 shortcut to do CALL TRANSACTION 'ZABAPGIT_CI_RUN_TESTS_CONFIGURED_BY_USER' ? 😜

I moved the logic to a global test class ZCL_ABAPGIT_OBJECTS_CI_TESTS that dynamically calls the CI test controller.
However, I can't figure out how to make the following work:
'Call of the method CONSTRUCTOR of the class ZCL_ABAPGIT_CI_CONTROLLER failed; wrong type for parameter II_REPO_PROVIDER'
    CREATE OBJECT li_ci_controller TYPE ('ZCL_ABAPGIT_CI_CONTROLLER')
      EXPORTING
        ii_repo_provider = li_repo_provider "<<< how to dynamically cast to ZIF_ABAPGIT_CI_CONTROLLER ???
        is_options       = <ls_options>.

Hmmm...
Unit test:
CLASS ltcl_ci DEFINITION FOR TESTING RISK LEVEL CRITICAL DURATION SHORT.

  PUBLIC SECTION.
    METHODS run FOR TESTING.

ENDCLASS.

CLASS ltcl_ci IMPLEMENTATION.
  METHOD run.
    zcl_abapgit_objects_ci_tests=>run( 'TABL' ).
  ENDMETHOD.
ENDCLASS.

The user exit is simplified to:
  METHOD zif_abapgit_exit~get_ci_tests.

    " Return the name of repos at https://github.com/abapGit-tests
    CASE iv_object.
      WHEN 'TABL'.
        APPEND 'TABL' TO rt_repos.
        APPEND 'TABL_foreign_key' TO rt_repos.
    ENDCASE.

  ENDMETHOD.

The CI tests will do a complete end-to-end check (with a local package, not a transportable package). A few seconds seems reasonable for that. What's included in your 0.2s local test?

Do you still need an exit class in this scenario? I would think now a dev can just call the proxy directly and be done with it. The proxy checks the critical setting and calls CI.
Also, I don't think the CI controller is the most remote-friendly entry point. But technically it should still be possible to call it dymamically:
    DATA: li_ci_controller TYPE REF TO object,
          li_repo_provider TYPE REF TO object.

    DATA repos TYPE RANGE OF string.
    APPEND VALUE #( sign = 'I' option = 'EQ' low = 'TABL' ) TO repos.
    CREATE OBJECT li_repo_provider TYPE ('ZCL_ABAPGIT_CI_TEST_REPOS')
      EXPORTING it_repo_name_range = repos.

    CREATE OBJECT li_ci_controller TYPE ('ZCL_ABAPGIT_CI_CONTROLLER')
      EXPORTING ii_repo_provider = li_repo_provider.

For my test I copy-pasted the repo into code. See
https://github.com/abapGit/abapGit/blob/1e93c1d3d360efbf646ac190aa1d3341700ca12e/src/objects/zcl_abapgit_object_pdts.clas.testclasses.abap#L26
and the de/serialization test at
https://github.com/abapGit/abapGit/blob/1e93c1d3d360efbf646ac190aa1d3341700ca12e/src/objects/zcl_abapgit_object_pdts.clas.testclasses.abap#L265
It's been merged into master so you should be able to run the test yourself, zcl_abapgit_object_pdts

I think either we should call the REST API or add a nicer background call to CI.

I already tried what you suggested. Unfortunately, the second create statement fails.
I had a look at pdts test class. that is a lot of hardcoded XML. It works but is imho limited to simple cases.
Have a look at the test cases for WDCA https://github.com/abapGit-tests/WDCA/tree/master/src or SFPF https://github.com/abapGit-tests/SFPF/tree/master/src. There are 120 object type classes. We can't possibly put all those test cases into abapGit itself.

Regarding exit see my comment above https://github.com/abapGit/abapGit/pull/3961#issuecomment-700777796

Yes the XML is a copy-paste from GitHub. It was a quick hack to get a test working that would save me time. It's not ideal and that's why I raised #3776 because I think the whole thing could be streamlined. Your approach is tackling it form the other end. In the middle I think perhaps a local cache for the test repo or something like that could do the trick.
The main point of my mentioning the PDTS test is that it runs fast enough to make it feasible to run de/serialization in a unit test, and from my own experience on it's been a huge timesaver.
An alternative to user exit could be a repo config option to list test repos that would be run for unit testing.

BTW, I tested the dynamic call, and it seems ABAP doesn't like interfaces. Bug or design? Smells like bug to me, but nevertheless I learnt something today :)
INTERFACE lif_test.
ENDINTERFACE.

CLASS lcl_main DEFINITION.

  PUBLIC SECTION.
    INTERFACES lif_test.
    METHODS run.
    METHODS run_with_obj IMPORTING i_obj TYPE REF TO lcl_main.
    METHODS run_with_intf IMPORTING i_intf TYPE REF TO lif_test.

ENDCLASS.

CLASS lcl_main IMPLEMENTATION.

  METHOD run.
    DATA obj TYPE REF TO object.
    DATA intf TYPE REF TO object.

    CREATE OBJECT obj TYPE ('LCL_MAIN').
    CALL METHOD obj->('RUN_WITH_OBJ') EXPORTING i_obj = me.  "OK
    CALL METHOD obj->('RUN_WITH_INTF') EXPORTING i_obj = me. "Dump

  ENDMETHOD.

ok, why bother with the controller that has big overhead. I changed to ZCL_ABAPGIT_CI_REPOS and now it's working and pretty fast. For TABL it takes about 1.5s. I tried with PDTS and it's 1.2s.
The exit needs to return repo name and clone URL, which makes it even more flexible since you can refer to any of your own repos, too:
   " Return the name of repos and their clone URL
    " The name is used to define the package "$___<name>" link to the abapGit repo

    " Examples:
    CASE iv_object.
      WHEN 'TABL'.
        " Generic insert which works for any object type
        " given we require such test repo for any new object type
        INSERT VALUE #(
          name      = iv_object
          clone_url = |https://github.com/abapGit-tests/{ iv_object }| )
          INTO TABLE rt_repos.

        " Add some other repo from https://github.com/abapGit-tests
        INSERT VALUE #(
          name      = 'TABL_foreign_key'
          clone_url = 'https://github.com/abapGit-tests/TABL_foreign_key' )
          INTO TABLE rt_repos.

        " Add your own repo works as well
        INSERT VALUE #(
          name      = 'MYTEST'
          clone_url = 'https://github.com/mbtools/abapGit-test-del' )
          INTO TABLE rt_repos.

      WHEN 'PDTS'.
        INSERT VALUE #(
          name      = iv_object
          clone_url = |https://github.com/abapGit-tests/{ iv_object }.git| )
          INTO TABLE rt_repos.
    ENDCASE.

BTW, I tested the dynamic call, and it seems ABAP doesn't like interfaces. Bug or design? Smells like bug to me, but nevertheless I learnt something today :)

I think you just had a typo :P
 CREATE OBJECT obj TYPE ('LCL_MAIN').
 CALL METHOD obj->('RUN_WITH_OBJ') EXPORTING i_obj = me.  "<--- OK
-CALL METHOD obj->('RUN_WITH_INTF') EXPORTING i_obj = me. "<--- Dump
+CALL METHOD obj->('RUN_WITH_INTF') EXPORTING i_intf = me. "<--- OK

I think you just had a typo :P

I did indeed, thanks! It was late, that's my excuse and I'm sticking with it! :P

Closing in favor of https://github.com/abapGit/abapGit/pull/3993


Does it support multi-modal LLM like LLaVa?

The given example shows how to use for LLM like llama.
But how can I use it to accelerate Visual Language Model like LLaVa?

LLaVa needs to be added with our lightweight model addition process. Contribution welcomed!

LLaVa needs to be added with our lightweight model addition process. Contribution welcomed! https://docs.vllm.ai/en/latest/models/adding_model.html

You dont generally see an issue in using the lighweight model adidtion for the composed llava model with CLIP, vision encoder and LLM?

It does turns out to be more complex. A working PR is here #3042

Closing as https://github.com/vllm-project/vllm/pull/3042 adds support for LLaVA1.5

is LLaVA-Next supported?
couldn't find a working example

@iamsaurabhgupt Feel free to take a look at the example here! https://github.com/vllm-project/vllm/issues/4194#issuecomment-2187565657. One limitation we have now is that we don't support dynamic shape of input image, so the results might be slightly different from huggingface implementation, but we're on track to support this very soon!


Guacamole VNC Throws 500 in Sunstone

Description
If FireEdge endpoints are configured in Sunstone, Guacamole is used for VNC access and returns a 500 error. Note Guacamole in FireEdge, and legacy VNC in Sunstone are working as expected.
To Reproduce
Configure FireEdge endpoints in Sunstone:
:private_fireedge_endpoint: http://localhost:2618
:public_fireedge_endpoint: https://[redacted]

Try to open a VM's console - Sunstone will return It appears there was a server exception. Please check server's log. and server side logs will have a line such as:
[17/Jun/2023:08:31:51 +0000] "POST /vm/152/guac/vnc HTTP/1.1" 500 - 0.3126

Expected behavior
Console opens and I can see my VM's screen
Details

Affected Component: Sunstone
Hypervisor: KVM
Version: 6.6

Additional context
I've been unable to fetch more detailed logs, due to lack of familiarity with Sunstone. If there are hints on which debug to enable and where to look to figure this out, I'll be happy to support.

Progress Status

[ ] Code committed
[ ] Testing - QA
[ ] Documentation (Release notes - resolved issues, compatibility, known issues)

Yes, I can use FireEdge no issues (moved to port 2618 since 2616 is the default for staticd). I can also use Guacamole directly in FireEdge no issues, so the problem seems somewhere in Sunstone before I'm even redirected there.
fireedge.error is empty, fireedge.log is a bit hard to read but no new line is added when I trigger the error.

"POST /vm/152/guac/vnc HTTP/1.1" 500 - 0.3126
someone is giving this 500 error, if it is not fireedge then is more likely your reverse proxy somehow.
can you try removing it from the equation?

I tried to reverse engineer the flow, but when I trigger the error no request is logged in my reverse proxy logs for the FireEdge hostname.
So we know the request goes this way:
client -> nginx -> sunstone
Sunstone throws a 500 (I can see it in /var/log/one/sunstone.log). When and why specifically it does so I don't know, but there seem to be no HTTP call whatsoever going through the reverse proxy. The fact no new lines land in fireedge.log makes me suspect not even a direct request via private_fireedge_endpoint lands there.
Is there a debug mode I can enable somewhere to figure out what Sunstone does before throwing the 500?

you can run sunstone-server.rb from the CLI, this will show exceptions from the server that probably are producing this 500.
For that, check the process using "ps -ef", stop it and run it using "ruby -dw"

Got it!
Exception `ArgumentError' at /usr/lib/one/sunstone/models/sunstone_guac.rb:236 - key must be 32 bytes
Exception `ArgumentError' at /usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1062 - key must be 32 bytes
2023-06-21 16:10:50 - ArgumentError - key must be 32 bytes:
	/usr/lib/one/sunstone/models/sunstone_guac.rb:236:in `key='
	/usr/lib/one/sunstone/models/sunstone_guac.rb:236:in `encrypt_data'
	/usr/lib/one/sunstone/models/sunstone_guac.rb:85:in `proxy'
	/usr/lib/one/sunstone/models/SunstoneServer.rb:344:in `startguac'
	/usr/lib/one/sunstone/sunstone-server.rb:1215:in `block in <main>'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1691:in `call'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1691:in `block in compile!'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1009:in `block (3 levels) in route!'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1027:in `route_eval'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1009:in `block (2 levels) in route!'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1058:in `block in process_route'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1056:in `catch'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1056:in `process_route'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1007:in `block in route!'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1004:in `each'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1004:in `route!'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1128:in `block in dispatch!'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1099:in `catch'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1099:in `invoke'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1123:in `dispatch!'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:939:in `block in call!'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1099:in `catch'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1099:in `invoke'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:939:in `call!'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:928:in `call'
	/usr/share/one/gems-dist/gems/rack-2.2.4/lib/rack/common_logger.rb:38:in `call'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:261:in `call'
	/usr/share/one/gems-dist/gems/rack-2.2.4/lib/rack/deflater.rb:44:in `call'
	/usr/share/one/gems-dist/gems/rack-2.2.4/lib/rack/session/abstract/id.rb:266:in `context'
	/usr/share/one/gems-dist/gems/rack-2.2.4/lib/rack/session/abstract/id.rb:260:in `call'
	/usr/share/one/gems-dist/gems/rack-protection-3.0.4/lib/rack/protection/xss_header.rb:20:in `call'
	/usr/share/one/gems-dist/gems/rack-protection-3.0.4/lib/rack/protection/path_traversal.rb:18:in `call'
	/usr/share/one/gems-dist/gems/rack-protection-3.0.4/lib/rack/protection/json_csrf.rb:28:in `call'
	/usr/share/one/gems-dist/gems/rack-protection-3.0.4/lib/rack/protection/base.rb:53:in `call'
	/usr/share/one/gems-dist/gems/rack-protection-3.0.4/lib/rack/protection/base.rb:53:in `call'
	/usr/share/one/gems-dist/gems/rack-protection-3.0.4/lib/rack/protection/frame_options.rb:33:in `call'
	/usr/share/one/gems-dist/gems/rack-2.2.4/lib/rack/null_logger.rb:11:in `call'
	/usr/share/one/gems-dist/gems/rack-2.2.4/lib/rack/head.rb:12:in `call'
	/usr/share/one/gems-dist/gems/rack-2.2.4/lib/rack/method_override.rb:24:in `call'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:219:in `call'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:2002:in `call'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1561:in `block in call'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1777:in `synchronize'
	/usr/share/one/gems-dist/gems/sinatra-3.0.4/lib/sinatra/base.rb:1561:in `call'
	/usr/share/one/gems-dist/gems/thin-1.8.1/lib/thin/connection.rb:86:in `block in pre_process'
	/usr/share/one/gems-dist/gems/thin-1.8.1/lib/thin/connection.rb:84:in `catch'
	/usr/share/one/gems-dist/gems/thin-1.8.1/lib/thin/connection.rb:84:in `pre_process'
	/usr/share/one/gems-dist/gems/thin-1.8.1/lib/thin/connection.rb:50:in `block in process'
	/usr/share/one/gems-dist/gems/eventmachine-1.2.7/lib/eventmachine.rb:1077:in `block in spawn_threadpool'

Sunstone it's complaining (not very elegantly, I have to admit) about fireedge_key not containing a proper 32 key.
You can find this file in /var/lib/one/.one, it should be generated by fireedge on first run.

File exists but it's empty, seems to be untouched for years:
root@za:~# stat /var/lib/one/.one/fireedge_key
  File: /var/lib/one/.one/fireedge_key
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: fd00h/64768d	Inode: 534047      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 9869/oneadmin)   Gid: ( 9869/oneadmin)
Access: 2023-06-21 15:55:01.872623415 +0000
Modify: 2021-05-01 11:41:40.014058237 +0000
Change: 2021-05-01 11:41:40.014058237 +0000
 Birth: 2021-05-01 11:32:31.948179169 +0000

Do you have an hint on how to generate the key? I tried to slap 32 hex bytes in it but I get the same error (openssl rand -hex 32).

this file is automatically generated by fireedge , you can delete it and restart fireedge service to recreate it

This worked! Thanks a lot.
Should whatever check you make at startup also validate the file is not empty? I've never fiddled with it so this file has clearly broken at some update or similar. Unfortunately my apt log doesn't go back to 2021 so can't confirm what happened on that day or which version was installed then.

Certainly we can add a check, we'll do it as part of the campaign for the new Fireedge Sunstone #5422


ModuleNotFoundError: No module named 'cutie'

I followed the installation everything went smooth until I tried to run:
python interactive_demo.py
I get this error:
(cutie) D:\AI\Cutie>python interactive_demo.py
Traceback (most recent call last):
  File "D:\AI\Cutie\interactive_demo.py", line 20, in <module>
    from gui.main_controller import MainController
  File "D:\AI\Cutie\gui\main_controller.py", line 20, in <module>
    from cutie.model.cutie import CUTIE
ModuleNotFoundError: No module named 'cutie'

I also tried this:
pip install cutie
But I still get the same error.
I'm not a programmer so I can't understand how to fix it,
Any suggestion how to fix that and make Cutie launch so I can test the demo?
Thanks ahead 🙏

Clone our repository:
git clone https://github.com/hkchengrex/Cutie.git

Install with pip:
cd Cutie
pip install -e .

Did you do these?

Thanks for the reply,
Yes, I did it but for some reason the git clone didn't download all the files I think.
So what I did was to download manually the ZIP and I extracted it, then it worked :)


overide default logging with filebeat version 7

This PR overrides default logging with filebeat version 7 running on systems running systemd
Since filebeat version 7,  systemd service file hard codes the flag -e. this option sets the logging to syslog and will ignore any logging set by this puppet module.
This change creates a systemd drop-in file for filebeat that drops the -e flag if a $logging hash is set when using the class

Thanks for the work on this. I've made a few comments, plus we should add some documentation around what's happening.
We need to be careful about changing existing installs too much so we don't break backwards compatibility too. While the default behavior might not be intuitive, I'm hesitant to change how the service runs on a minor version upgrade. I'm open to suggestions, but maybe this change should be opt-in?

Agreed. this totally needs to be opt in. just not sure how to approach this.
Also I think the code supplied might fail on an older system or a system that does not have systemd installed. because it will try to install a file into the service drop in location..  if the base directories are not installed it will fail..... sooooooo this also need to test for systemd is part of the system

create a bolean param
$systemd_log_opt_override      = false

I am terrible at naming things.
if $systemd_log_opt_override and version 7+
add drop in service file
else
remove drop in service file
end
how does this sound?

Thinking about this a bit more, we need to cover a few more things. Before doing anything we need to check that systemd is in use (is the service_provider fact always around?). If we create an override file, we need to reload the systemd configuration too.
The camptocamp/systemd module does a nice job of dropping the files in place and reloading systemd, but I'm not sure it makes sense to force everyone to use the same systemd module either (is that something people feel strongly about?).
What if we create a single new string parameter named systemd_beat_log_opts? If it's left undefined we do nothing at all, regardless of what the logging parameter is set to. If the parameter has a value (including an empty string), we use that in the override file. Of course we still need to check for systemd in case someone is installing on a box without systemd (including Windows).

fyi,as of puppet 6.1 systemctl daemon-reload  is handled when units change already (6.1 release_notes) ... I don't think adding the camptocamp/systemd dependency added to the dep manifest is needed. but add documentation that they should add this if they have older puppet versions.. I doubt that everyone is like me and keeps puppet bleeding-edge like me though. but I do agree the puppet-systemd module will do a better job managing systemd unit files
with the proposed var systemd_beat_log_opts I suggest defaults be
String $systemd_beat_log_opts  = '-e'

the reason I say this is,

its the default for filebeat 7.0+ with systemd
having the drop-in file being the same will not make any system changes if the drop in file is created
this would allow the add extra options (as seen in filebeat docs) like -e -d elastic
setting this to undef would set the opt to empty and allow the logging hash to work

I also personally think we should not touch the original systemd service file as this gets replaced on each upgrade (which I just noticed upgrading systems to 7.3) this means we might need to make a params logic that if in the future they change the default, we supply that default
I think this logic would be better with the optional camptocamp/systemd module is available. we will also not need to check for systemd systems as the module handles this.
# nothing happens if the module is not included
if defined('systemd')  {
  systemd::dropin_file { 'logging.conf':
  unit   => 'filebeat.service',
  source => template logic here,
}

we would need to add documentation to the $logging and the $systemd_beat_log_opts that the camptocamp/systemd module would need to be added if you want to change the behaviour on systemd systems

I didn't know about the systemd change, but that certainly makes things easier. Fewer dependencies is always a little better too, especially on something like systemd. A note in the docs that you'll need Puppet 6.1 or higher if you're using that parameter is probably enough.
I'd rather not manage an override file at all if we're not overriding anything, which is why I'm thinking a default undef value might be easier than having to actively keep up with default value. Maybe a better parameter name is systemd_beat_log_opts_override?

the more and more I think about it.. I agree with your last message.
here is what I will change with PR.

check that puppet version
$::clientversion >= 6.1
use StdLib $::service_provider fact to detect what service provider is being used
service_provider == 'systemd'
->
check if filebeat >= 7  is being used
->
if $systemd_beat_log_opts_override != undef create dropin file and if == undef make sure the file is absent

this will actually simplify future version.

Changed the pr. I also updated the README for the class information and added to the Limitations section.
I think the puppet-systemd module usage in the documentation provided is accurate. but I think it should be used against filebeat::service instead
let me know if you want me to change it and put the override in the service class instead
class{'filebeat::service':
 systemd_beat_log_opts => ""
}

I will have this pull request updated with the recommendations soon.

Thanks for all the work on this. I'm not going to be near a computer for the rest of the week so I'm going to cut a new release on Monday in case we missed something.

Released as 4.1.0


Add Proguard Docs

Hi,
Any update regarding this?
Also, is this still valid?

No updates yet, but I'll put it on our next week's work plan.
The link is not valid.


Only download new wheels?

Looks like currently python get_wheels.py will always re-download all wheels to a tmp folder on each invocation, and then copy to the local wheelhouse folder.
Maybe this can be changed to only download new wheels that I don't have yet?
(base) hfm-1804a:wheel-forge deil$ python get_wheels.py
Fetching wheels for build 8 of astropy-project/wheel-forge
Downloading 20 artifacts to /var/folders/t_/_mywtcj146lbk2c99bnxw7z40000gp/T/tmpk3zl766j
 -> downloaded wheels-linux32-astropy-healpix
 -> downloaded wheels-linux64-astropy-healpix
 -> downloaded wheels-linux32-reproject
 -> downloaded wheels-macosx-astropy-healpix
 -> downloaded wheels-linux64-reproject
 -> downloaded wheels-linux64-regions
 -> downloaded wheels-linux32-regions
 -> downloaded wheels-linux64-photutils
 -> downloaded wheels-linux32-photutils
 -> downloaded wheels-macosx-photutils
 -> downloaded wheels-macosx-reproject
 -> downloaded wheels-macosx-regions
 -> downloaded wheels-windows32-astropy-healpix
 -> downloaded wheels-windows64-astropy-healpix
 -> downloaded wheels-windows32-photutils
 -> downloaded wheels-windows32-regions
 -> downloaded wheels-windows64-photutils
 -> downloaded wheels-windows32-reproject
 -> downloaded wheels-windows64-regions
 -> downloaded wheels-windows64-reproject
Extracting wheels to current directory
(base) hfm-1804a:wheel-forge deil$ python get_wheels.py
Fetching wheels for build 8 of astropy-project/wheel-forge
Downloading 20 artifacts to /var/folders/t_/_mywtcj146lbk2c99bnxw7z40000gp/T/tmpo7n4883w
 -> downloaded wheels-linux32-astropy-healpix
 -> downloaded wheels-linux64-astropy-healpix
 -> downloaded wheels-linux32-reproject
 -> downloaded wheels-macosx-astropy-healpix
 -> downloaded wheels-linux64-reproject
 -> downloaded wheels-linux64-regions
 -> downloaded wheels-linux32-regions
 -> downloaded wheels-linux64-photutils
 -> downloaded wheels-linux32-photutils
 -> downloaded wheels-macosx-photutils
 -> downloaded wheels-macosx-reproject
 -> downloaded wheels-macosx-regions
 -> downloaded wheels-windows32-astropy-healpix
 -> downloaded wheels-windows64-astropy-healpix
 -> downloaded wheels-windows32-photutils
 -> downloaded wheels-windows32-regions
 -> downloaded wheels-windows64-photutils
 -> downloaded wheels-windows32-reproject
 -> downloaded wheels-windows64-regions
 -> downloaded wheels-windows64-reproject
Extracting wheels to current directory

Technically this makes sense, but I need to check if there is a way to find out the checksum of the file before downloading - or alternatively we can probably have some kind of cache of the artifact IDs inside the downloaded wheelhouse folder.


liquidity error

Describe the bug
I have added liquidity for BLL and HORSE pairs, the wallet has confirmed the completion of the transaction but when I check the liquidity pool again, they don't appear.
Steps to reproduce
Steps to reproduce here.
Additional context

Additional context here.

Hello, how are you? Were you able to resolve your issue? Generally, errors like these occur due to communication failures between the blocks or even connection errors. However, to precisely understand what happened, we need more information, such as the transaction ID.
I'm here to help, my friend!!!

Hello,
Here are my 2 transaction ids getting error about adding liquidity as
mentioned in github:
My 1st trade (August-19-2023 10:36:12 PM +7 UTC) is add 0.05 HORSE and
about 0.014 BLL with transaction ID:
"0x574c8ba41b20e4ce632fdccd44a5b838e241b1a6669cbd4c528b36454e3f56c6"
My second trade(August-19-2023 10:36:12 PM +7 UTC) is adding about 0.01
HORSE and about 0.003 BLL  with transaction ID:
"0xf95be683c0fc186374deb4d317770d1a117a9f04639cd5fa73b2d61a4d9ee7ac"
Thank you!.
Vào CN, 20 thg 8, 2023 vào lúc 09:20 TTorricobr @.***>
đã viết:

Hello, how are you? Were you able to resolve your issue? Generally, errors
like these occur due to communication failures between the blocks or even
connection errors. However, to precisely understand what happened, we need
more information, such as the transaction ID.
I'm here to help, my friend!!!
—
Reply to this email directly, view it on GitHub
https://github.com/taikoxyz/taiko-mono/issues/14542#issuecomment-1685157228,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXYCGWQGGI6PB5EEIKWFVUDXWFX6BANCNFSM6AAAAAA3W5QARY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hello, how are you? Were you able to resolve your issue? Generally, errors like these occur due to communication failures between the blocks or even connection errors. However, to precisely understand what happened, we need more information, such as the transaction ID.
I'm here to help, my friend!!!

Here are my 2 transaction ids getting error about adding liquidity as mentioned in github:
My 1st trade (August-19-2023 10:36:12 PM +7 UTC) is add 0.05 HORSE and about 0.014 BLL with transaction ID: "0x574c8ba41b20e4ce632fdccd44a5b838e241b1a6669cbd4c528b36454e3f56c6"
My second trade(August-19-2023 10:36:12 PM +7 UTC) is adding about 0.01 HORSE and about 0.003 BLL  with transaction ID: "0xf95be683c0fc186374deb4d317770d1a117a9f04639cd5fa73b2d61a4d9ee7ac"

Bridge dapp v1 has been deprecated.


Color Picker popup behind the button when...

When a ColorPickerButton is child of a Node2D with z>0:

Am I supposed to do this however?

yes, this is intended, the ColorPicker contains a dialog and dialogs don't keep their parent Zs. (GUI components don't use Z). This is a really strange use case though, so if you want to set a custom Z to the color pciker, I am adding a function get_picker() to the button, so you can do:
VS.canvas_item_set_z( button.get_picker().get_canvas_item(), <your_z_here> );


colorschemes/catppuccin: add originalName

Supports lazy loading
Lz-n will look for the colorscheme in packpath by originalName. Without change it will throw an error when trying to lazy load. This plugin has a unique originalName because the upstream repo is just nvim and upstream package is being added to packpath as catppuccin-nvim.

@mergify queue


Generic transaction and block Environment.

After Evm builder is finished we should generalize the Block and Transaction to the trait, this would allow adding new fields to both of those structs and elevate usage of the External Contexts as it would allow multiple generics and easier integration with other types.
Evn should stay as the default type that we use, and this would be overridable in EvmBuilder.

Make Transaction generic contains tx type so we have a clean difference between transactions, currently we have done it ad hoc if field is Some.

Yeah, at least for the concrete types we would want something like this:
/// Ethereum tx env
pub struct EthTxEnv {
    // ... the tx env fields for mainnet ethereum
}

/// Data used to calculate the l1 cost of a transaction
pub struct RollupCostData {
    /// The number of ones in the rlp encoding of the signed transaction being executed
    pub ones: u64,
    /// The number of zeroes in the rlp encoding of the signed transaction being executed
    pub zeroes: u64,
}

/// Optimism tx env
pub struct OptimismTxEnv {
    /// The underlying ethereum tx environment
    pub eth_env: EthTxEnv,
    // ... then the optimism specific fields
    // ideally including this:
    pub rollup_cost_data: RollupCostData,
}

And each of these would implement an environment trait with methods to expose what we currently use in mainnet eth execution.
We'd also want some flexibility, for example to let optimism actually use its custom tx env fields.
For example here are some things that optimism currently does with custom fields:
https://github.com/bluealloy/revm/blob/7cf937ae2e902c0eb6b2d2e6c385903a3d65851e/crates/primitives/src/env.rs#L84-L94
https://github.com/bluealloy/revm/blob/7cf937ae2e902c0eb6b2d2e6c385903a3d65851e/crates/primitives/src/env.rs#L207-L212
https://github.com/bluealloy/revm/blob/7cf937ae2e902c0eb6b2d2e6c385903a3d65851e/crates/revm/src/optimism/handler_register.rs#L125-L150
Not sure how yet we could provide this flexibility, maybe adding some hooks that are run in the beginning of tx validation, or elsewhere

This is imagined to be a TxTrait or TxEnvTrait that you can override if needed. It is up to lib user to specify different generics of the trait and add handlers that use that trait. In reth, this would be just implementing TxTrait over &Transaction and you could use &Transaction directly inside revm without need to populate Env

I'll give this a shot


cps/xfrm: cleanup exception rewrite and fix bugs

Fixed one main issue where the "current" exception is not refreshed
every bounce and that the exception is not voided after completion
of the except clauses.
Also moved the except rewrite outside of cpsTryExcept.
Need more tests.

There are a few major issues left:

Exception raised and handled within the exception handler will replace the handler's current exception
Even with the latest commit, the exception might leak if an unhandled exception is raised (we may have to decide how unhandled exceptions affect a running continuation)

There are a few major issues left:

Exception raised and handled within the exception handler will replace the handler's current exception

Okay, but isn't that correct behavior?

Even with the latest commit, the exception might leak if an unhandled exception is raised (we may have to decide how unhandled exceptions affect a running continuation)

I don't know why we'd want to catch unhandled exceptions.  Ideally, exceptions don't touch the state so that the user can simply invoke the continuation again -- kinda like quirky exceptions, right?

Okay, but isn't that correct behavior?

https://play.nim-lang.org/#ix=3nFm <-- apparently not

I don't know why we'd want to catch unhandled exceptions. Ideally, exceptions don't touch the state so that the user can simply invoke the continuation again -- kinda like quirky exceptions, right?

I worry about this: https://github.com/nim-lang/Nim/issues/18070

https://play.nim-lang.org/#ix=3nFm <-- apparently not

I guess we have to store all exceptions in the locals.  This is feeling the original handwritten transform, right?

I worry about this: https://github.com/nim-lang/Nim/issues/18070

Looks like the pointer isn't cleared but that should be an easy fix.  Did you look at the codegen?


nvidia/GPU support?

What do you think about adding GPU support via one of these crates?
Have you looked into it?
I would be happy to open a PR if it is something we would like to add...

Looks like i3status-rust does some Nvidia stuff: https://github.com/greshake/i3status-rust/blob/master/src/blocks/nvidia_gpu.rs
They could probably benefit from an Nvidia library too so that they could clean up their code a bit

Radeontop (written in C) might also be a good point of reference for AMD cards.


bug: the lspconfig-option document_highlight does not exist

Did you check docs and existing issues?

[x] I have read all the LazyVim docs
[x] I have updated the plugin to the latest version before submitting this issue
[x] I have searched the existing issues of LazyVim
[x] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
0.10.2
Operating system/version
MacOS
Describe the bug
setting the option document_highlight to true or false has no effects. it also seems that lspconfig doesn't have the option document_highlight.
https://github.com/LazyVim/LazyVim/blob/5ea3cfa48e6ac88b90282da86dba7799f67b2e30/lua/lazyvim/plugins/extras/editor/illuminate.lua#L58
Steps To Reproduce
add lspconfig.lua with content
return {
  "neovim/nvim-lspconfig",
  opts = {
    document_highlight = {
      enabled = false, -- highlighting über vim-illuminate
    },
}

to your plugins folder.
open a file with lsp support (including documentHighlightProvider)
Check if other highlighters are enabled an disable them (like illuminate ux)
Hover over a Symbol, References are still Highlighted.

Expected Behavior
References shouldn't be highlighted anymore.
You can stop your LSP with :LspStop to see the expected result
Repro

Thank you very much!


Inconsistencies in detection and extraction of text using tesseract

Your Feature Request
I have provided the image from which I am trying to extract text from, using tesseract ocr.

Along with that, I have also provided the result or the extracted text from the image.

As it can be observed from the images, the extracted text is not very accurate. Negative symbols have been omitted, some undesired characters are also there in the extracted text. (I have marked some of the incorrect results with blue boxes)
I have tried to improve the results by preprocessing and bringing changes in the parameters of the model. I have tried:

binarizing the images
HDR processing of the processes
Even then, such inconsistencies remain.

How to improve the detection and extraction of text in tesseract? I have also tried paddleocr for the same task. Even then, symbols such as euro, some negative signs are not being detected.

What about reading documentation?

@zdenop Thank you for your response. I tried each and every step mentioned in this documentation. Even then, some decimal points are being omitted such as 22.5 is being misunderstood as 225. Moreover some numbers and being wrongly detected, such as -9 is being extracted as = ). Some negative symbols are also being omitted.
I have tried preprocessing the images and have implemented the following:

noise removal
canny edge detection
hough line transform
binarization
hdr processing

Pls provide your guidance and help me resolve this issue.

And what did you learn about table recognition?
What forum posts about table recognition, what other issues are stated about table recognition? You should check these sources BEFORE posting the issue.

This mod seems to do a slightly better job, still not flawless...


Currently models cant be serialized

On the latest (currently) commit ef88814 on branch 21.2.0 I can't serialize-deserialize models with soil.
string modelPath = "C:/Temp/FEM-Design api piles foundation/example.struxml";
var model = Model.DeserializeFromFilePath(modelPath);
model.SerializeModel(modelPath.Replace(".struxml", "_serialized.struxml"));

The diff between the before and after seems to have a problem for the materials

Can you place the file in our drive? it might be that only Deserialisation works and needs to investigate the serialisation.

395 - Serialization

Perfect! Thanks!


memory leak fix

This commit fix somes memory leak reported by valgrind

@damian-m-g valgrind reported me somes memory leak fix related to xml ressource not freeed
regards

Hi @gvollant, good catch and thanks for the PR. Cheers.


Deploy errror

I am trying to deploy an unlocked package using this command: sfdx force:source:deploy  -p
I get this error:
*** Deploying with REST ***
ERROR running force:source:deploy:

Illegal Request

You have sent us an Illegal URL or an improperly formatted request.

    </td>
</tr>

Can you please help?

I began hitting this myself after upgrading to version 7.91.0-6a6ed69ebe from 7.85 yesterday. I noticed this "Deploying with REST" message being logged and had not noticed that before. I saw that the release notes for 7.90.2 called out a change to the default behavior from using SOAP to using REST for deployment: https://github.com/forcedotcom/cli/tree/main/releasenotes#5122-march-4-2021---cli-7902. So, I set the SFDX_REST_DEPLOY environment variable to false, and this solved my problem.

Indeed, @tfuda is correct. This is a REST API issue that the CLI is simply surfacing.
You can set the SFDX_REST_DEPLOY environment variable to false to use the SOAP API.
We're triaging other REST API issues at https://github.com/forcedotcom/cli/issues/860 so you can follow that for more information.

That worked for me. Appreciate your help
Raghu
On Tue, Mar 16, 2021, 11:27 AM Rodrigo Espinosa de los Monteros <
@.***> wrote:

Indeed, @tfuda https://github.com/tfuda is correct. This is a REST API
issue that the CLI is simply surfacing.
You can set the SFDX_REST_DEPLOY environment variable to false to use the
SOAP API.
We're triaging other REST API issues at #860
https://github.com/forcedotcom/cli/issues/860 so you can follow that
for more information.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/forcedotcom/cli/issues/921#issuecomment-800410451,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAESRWVAUALUDIFMCMU5BC3TD6BHPANCNFSM4ZIVRMVA
.


Exclude testdata directories

The golint check is currently reporting issues for testdata directories. See https://goreportcard.com/report/github.com/bradleyfalzon/apicompat
However, testdata is often contains purposefully invalid code, and should generally be ignored, at least for lint checks. golint already ignores this directory (https://github.com/golang/lint/blob/8f348af5e29faa4262efdc14302797f23774e477/golint/import.go#L208 and so does the go tool https://golang.org/cmd/go/#hdr-Description_of_package_lists) and I think goreportcard should to (at least for the lint checks, but perhaps others too).
If agreed and scope can be determined (all tests or lint only), I can investigate further (hints appreciated) and provide PR for review.

I can't seem to reproduce this in dev, using a fresh GOPATH (via docker):
docker run -it --rm -p 8000:8000 golang:1.7 bash
go get -u github.com/gojp/goreportcard
cd $GOPATH/src/github.com/gojp/goreportcard
make install
make start-dev

After checking http://<IP_ADDRESS>:8000/report/github.com/bradleyfalzon/apicompat, golint scores 100% - this is expected behaviour, but production shows 71% and shows the warnings in testdata directories. See
I've tried a few different things, and from what I can see, golint should've been ignoring this since supporting recursive paths, so I'm not sure why production would be any different (I also checked autocomplete/138-cmd branches and they both report 100% for golint tests).
Any thoughts why production scores golint 71% but development scores golint 100%?

OK, seems production maybe running an older version of gometalinter before https://github.com/alecthomas/gometalinter/commit/dcc27da2ed95dee794fa7d979d8e3b9b842bbb41
The above change fixes the issue for gometalinter (which is why I couldn't reproduce on dev), but this would still occur for other checks not using gometalinter, so I'll still send through a PR.

Sorry. Using GitHub on mobile on a train :)
Production could very well be out of date re: gometalinter, I'll update it as soon as I can. Thanks!

@bradleyfalzon just updated gometalinter and all linters on production

thanks @shawnps I can see the lints are now 100% as expected.


2.0-wip navbar-form align issue

inputs and button don't align well in the navbar:
/slim template used here
form.navbar-form.pull-right action="/user/login" method='post'
  input.input-small name='email' placeholder="eMail" type="text"
  input.input-small name='password' placeholder="Passwort" type="password"
  button.btn type="submit" Anmelden

well, margin doesn't seem to be better either...

Just resolved that. Thanks!


Raise Exception from AnyInstanceOf Constructor

What:

#233
Why:

How:

Checked for the input arguments of the AnyInstanceOf to be of an instance of type. If not, raise a ValueError exception.
Risks:

Checklist:

[x] Added tests, if you've added code that should be tested
[x] Updated the documentation, if you've changed APIs
[x] Ensured the test suite passes
[x] Made sure your code lints
[x] Completed the Contributor License Agreement ("CLA")

Do I need to add the "correct usage" of the AnyInstanceOf in the tests?

Pull Request Test Coverage Report for Build 677094818

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.004%) to 94.133%

Totals

Change from base Build 617391924:
0.004%

Covered Lines:
2551

Relevant Lines:
2710

💛  - Coveralls

Thank you @macisamuele for your help. Learned a lot in the past week. 😊

I know that I might asking a lot, so sorry in advance.
Would you have bandwidth to address also the other matches? (possibility on a different PR such that this can eventually be merged)

And yes, no worries of the bandwidth.
Also, I might sometimes ask childish questions 😅. Just to be sure about what needs to be done. I hope it won't be an issue.

And yes, no worries of the bandwidth.
Also, I might sometimes ask childish questions 😅. Just to be sure about what needs to be done. I hope it won't be an issue.

at this point I do believe that you have fully grasped what needs to be done and how to do it. Still, no questions are childish so do not hesitate to post them.


Add custom I18n exception handler

Context
In the event of a missing or incorrect key, default i18n behaviour in Rails is to simply render a missing key error on the page. We can improve this to increase the likelihood of finding such errors.

Changes proposed in this pull request
Adds a custom I18n exception handler which sends missing translation errors to Sentry when running in production mode.
In test/development mode it raises the exception.

Guidance to review

Link to Trello card
https://trello.com/c/D4UPWMWZ/226-improve-handling-of-missing-i18n-keys

Checklist

[x] Attach to Trello card
[x] Rebased main
[x] Cleaned commit history
[x] Tested by running locally

 Improve handling of missing i18n keys


AutoMapper does not handle Doctrine managed entities, leading to new instances being created for existing entities

I am using AutoMapper in a Symfony project alongside Doctrine. When mapping a DTO to an entity, AutoMapper creates new instances for related entities, even if those entities already exist in the database and should be managed by Doctrine.
For example, I am mapping a Course DTO that contains a CourseType (which is an existing entity in the database). The CourseType has a valid id, and this should indicate to Doctrine that it is an existing entity, but AutoMapper is not respecting that. Instead, it creates a new CourseType instance, which is not managed by Doctrine, leading to persistence issues (e.g., Doctrine attempts to persist the new CourseType as if it were a new entity).
The only way I found to ensure that the related entity is managed by Doctrine is to manually fetch it from the database before persisting the mapped entity, which defeats the purpose of using AutoMapper to simplify this process.
What can I do? Thanks!

i faced the same issue, but you can do better than fetch the entity from the database.
AutoMapper can map to an existing entity, so what you need is to have an Entity Proxy, if it stored in a Doctrine's IdentityMap.
For example, you want to map an UserDTO to UserEntity:
$this->map($userDTO, UserEntity::class);
...
private function map(mixed $dto, string $resourceClass): object
{
    if ($dto->getId() !== null) {
        $resourse = $this
            ->entityManager
            ->getUnitOfWork()
            ->tryGetById($dto->getId() , $resourceClass);
        if ($resource !== false) {
            return $this->autoMapper->map($dto, $resource);
        }
    }
    return $this->autoMapper->map($dto, $resourceClass);
}

Hey @m4n50n and @AntipodTX , thanks for reporting your issue !
I think the best here would be to add a Doctrine provider within the AutoMapper Bundle. I'm still not sure how to make it work correctly. Ideally the provider would contain something close to your last comment @m4n50n. But I don't think we would like that every time, how do you guys we should make it trigger ?
I was thinking about a context parameter, something like ['recover_from_database' => true] ? (name is just an idea, nothing temporary).
Also how should it work ? If no object found in database we throw an Exception ? we map onto a new object ?
There is some stuff we should define before doing such provider in my opinion !
If you have time to answer all this and give me your feedback, I can see about implementing it later on !
Baptiste

Hi!
I'm just facing this issue,
In my opinion, as soon as an entity is declared as an ORM entity, should always work this way :

If DTO has not null identifier, it should be fetched from the database.
If no such id exists in database, then it should return a new empty instance of the entity (filled with the dto values of course).

If it has to be otherwise, I think this is for specific use cases, and this should be handled by custom provider for these edge cases.

@Korbeil
The code that you see above it is a simplified version of the code that i am using in my Transformer. I implemented the feature mentioned here , so i can collect all static metadata information about the Entity during the mapper class generation process and store it in a generated mapper class using my own PropertyTransformer. The thing is (for example) the Entity can have a composite identifier and, IMO, it is better to collect this information once instead of doing it all the time during the mapping (and the Provider's) call. I am not against the Provider, i am just thinking out laud about the performance.
@yobud
One small correction - If DTO has not null identifier, the Entity should be fetched from the database. if it is not fetched yet


Sentry Release

Move sentry CI/CD release to a separate job. It will not run on Mac container only Linux container

It is still falling. Moved to 0.1.1 in order to focus on the deliverables of 0.1.0

I will leave this closed but we should discuss a different pipeline for release that will run like the old one.

the dev pipeline in every develop branch merge
the release pipeline in every tag creation


adminserver，移除节点失败

In GitLab by @cuiaq123 on Mar 27, 2020, 06:16

In GitLab by @luotian-github on Mar 27, 2020, 06:20
assigned to @guyingyan and unassigned @liyanq528

In GitLab by @cuiaq123 on Mar 27, 2020, 06:24
填写密码错误导致的

In GitLab by @cuiaq123 on Mar 27, 2020, 06:24
closed

In GitLab by @cuiaq123 on Mar 27, 2020, 06:26
需要在用户手册里说明一下