PyImath Bindings fail to build when using Clang on Windows (Release branch, 3.17, issue still present on Main)

OS:  Windows 10 22H2, 19045.2965
Tools:

bundled with Visual Studio 2022 Community Edition

CMake 3.26.0-msvc3
clang-cl 15.0.1
MSVC cl version 19.36.32532 for x64

Visual Studio Code (text editor)

CMake Tools

Libraries:

Boost 1.82.0 (compiled locally using cmake)
Python 3.10
Numpy 1.24.3

cmake configuration:
cmake --no-warn-unused-cli -DCMAKE_INSTALL_PREFIX:STRING=C:/lib/imath \
-DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE \
-DBUILD_TESTING:BOOL=TRUE \
-DBoost_ROOT:STRING=C:/lib/boost \
-DBoost_NO_BOOST_CMAKE:BOOL=FALSE \
-DBoost_USE_STATIC_LIBS:BOOL=FALSE \
-DBoost_USE_MULTITHREADED:BOOL=TRUE \
-DBoost_USE_STATIC_RUNTIME:BOOL=FALSE \
-DPYTHON:BOOL=TRUE \
-DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE \
-DCMAKE_C_COMPILER=clang-cl \
-DCMAKE_CXX_COMPILER=clang-cl \
-SD:/Code/lib/Imathfork \
-Bd:/Code/lib/Imathfork/build \
-G "Ninja Multi-Config"

I've tested using both the Ninja generator and the Visual Studio generator, as well as specifying cxx standards 11 and 17.
Using clang (or clang-cl) to compile the release branch (commit a4f9d5c) will error out on the python bindings. I've truncated the log to one of the relevant sections. Apologies if it's messy, it's from VS Code's output window.
[build] FAILED: src/python/PyImath/CMakeFiles/PyImath_Python3_10.dir/Release/PyImathAutovectorize.cpp.obj
[build] "C:\PROGRA~1\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\bin\clang-cl.exe"   -TP -DBOOST_CONTAINER_DYN_LINK -DBOOST_CONTAINER_NO_LIB -DBOOST_PYTHON_DYN_LINK -DBOOST_PYTHON_NO_LIB -DIMATH_DLL -DPYIMATH_BUILD -DPyImath_Python3_10_EXPORTS -DCMAKE_INTDIR=\"Release\" -ID:\Code\lib\Imath\build\src\python\PyImath -ID:\Code\lib\Imath\src\python\PyImath -ID:\Code\lib\Imath\src\Imath -ID:\Code\lib\Imath\build\config -imsvcC:\lib\boost\include\boost-1_82 -imsvcC:\Python310\include /clang:-march=native /MD /O2 /Ob2 /DNDEBUG /EHsc -std:c++17 /showIncludes /Fosrc\python\PyImath\CMakeFiles\PyImath_Python3_10.dir\Release\PyImathAutovectorize.cpp.obj /Fdsrc\python\PyImath\CMakeFiles\PyImath_Python3_10.dir\Release\ -c -- D:\Code\lib\Imath\src\python\PyImath\PyImathAutovectorize.cpp
[build] In file included from D:\Code\lib\Imath\src\python\PyImath\PyImathAutovectorize.cpp:8:
[build] In file included from D:\Code\lib\Imath\src\python\PyImath/PyImathAutovectorize.h:34:
[build] In file included from D:\Code\lib\Imath\src\python\PyImath/PyImathFixedArray.h:17:
[build] D:\Code\lib\Imath\src\python\PyImath/PyImathUtil.h(43,20): error: attribute 'dllexport' cannot be applied to a deleted function
[build]     PYIMATH_EXPORT PyAcquireLock(const PyAcquireLock& other) = delete;
[build]                    ^
[build] D:\Code\lib\Imath\src\python\PyImath/PyImathUtil.h(44,36): error: attribute 'dllexport' cannot be applied to a deleted function
[build]     PYIMATH_EXPORT PyAcquireLock & operator = (PyAcquireLock& other) = delete;
[build]                                    ^
[build] D:\Code\lib\Imath\src\python\PyImath/PyImathUtil.h(45,20): error: attribute 'dllexport' cannot be applied to a deleted function
[build]     PYIMATH_EXPORT PyAcquireLock(PyAcquireLock&& other) = delete;
[build]                    ^
[build] D:\Code\lib\Imath\src\python\PyImath/PyImathUtil.h(46,36): error: attribute 'dllexport' cannot be applied to a deleted function
[build]     PYIMATH_EXPORT PyAcquireLock & operator = (PyAcquireLock&& other) = delete;
[build]                                    ^
[build] D:\Code\lib\Imath\src\python\PyImath/PyImathUtil.h(67,20): error: attribute 'dllexport' cannot be applied to a deleted function
[build]     PYIMATH_EXPORT PyReleaseLock(const PyReleaseLock& other) = delete;
[build]                    ^
[build] D:\Code\lib\Imath\src\python\PyImath/PyImathUtil.h(68,36): error: attribute 'dllexport' cannot be applied to a deleted function
[build]     PYIMATH_EXPORT PyReleaseLock & operator = (PyReleaseLock& other) = delete;
[build]                                    ^
[build] D:\Code\lib\Imath\src\python\PyImath/PyImathUtil.h(69,20): error: attribute 'dllexport' cannot be applied to a deleted function
[build]     PYIMATH_EXPORT PyReleaseLock(PyReleaseLock&& other) = delete;
[build]                    ^
[build] D:\Code\lib\Imath\src\python\PyImath/PyImathUtil.h(70,36): error: attribute 'dllexport' cannot be applied to a deleted function
[build]     PYIMATH_EXPORT PyReleaseLock & operator = (PyReleaseLock&& other) = delete;
[build]                                    ^
[build] 8 errors generated.

The issue is tied to src/python/PyImath/PyImathUtil.h specifically, where PYIMATH_EXPORT is assigned to the deleted copy and move constructors/operators. Clang on Windows will provide a _MSC_VER definition, so this resolves to __declspec(dllexport) in PyImathExport.h. The issue is with the declarations of PyAcquireLock and PyReleaseLock.

This
class PyAcquireLock
{
  public:
    PYIMATH_EXPORT PyAcquireLock();
    PYIMATH_EXPORT ~PyAcquireLock();

    PYIMATH_EXPORT PyAcquireLock(const PyAcquireLock& other) = delete;
    PYIMATH_EXPORT PyAcquireLock & operator = (PyAcquireLock& other) = delete;
    PYIMATH_EXPORT PyAcquireLock(PyAcquireLock&& other) = delete;
    PYIMATH_EXPORT PyAcquireLock & operator = (PyAcquireLock&& other) = delete;

  private:
    PyGILState_STATE _gstate;
};

ends up compiling as
class PyAcquireLock
{
  public:
    __declspec(dllexport) PyAcquireLock();
    __declspec(dllexport) ~PyAcquireLock();

    __declspec(dllexport) PyAcquireLock(const PyAcquireLock& other) = delete;
    __declspec(dllexport) PyAcquireLock & operator = (PyAcquireLock& other) = delete;
    __declspec(dllexport) PyAcquireLock(PyAcquireLock&& other) = delete;
    __declspec(dllexport) PyAcquireLock & operator = (PyAcquireLock&& other) = delete;

  private:
    PyGILState_STATE _gstate;
};

Clang explicitly disallows dllexport to be assigned to deleted functions; while clang-cl in general attempts to mimic the behavior of MSVC, it would appear that it is rigid in this scenario, while MSVC will still compile. My understanding is that dllexports only apply to non-deleted functions, and as such it's not good practice to be declaring them on deleted functions regardless. Looking through the dumpbin on the generated library file from MSVC, it appears that MSVC's behavior is to not export the deleted functions (the constructors/destructors for PyAcquireLock and PyReleaseLock are still properly exported), implying it sees the declaration and ignores it for the deleted copy/move constructor/operator functions. Performing a diff on the dumpbins compiled using MSVC with and without the PYIMATH_EXPORT declarations on the deleted functions shows that output is equivalent.
Changing the code to
class PyAcquireLock
{
  public:
    PYIMATH_EXPORT PyAcquireLock();
    PYIMATH_EXPORT ~PyAcquireLock();

    PyAcquireLock(const PyAcquireLock& other) = delete;
    PyAcquireLock & operator = (PyAcquireLock& other) = delete;
    PyAcquireLock(PyAcquireLock&& other) = delete;
    PyAcquireLock & operator = (PyAcquireLock&& other) = delete;

  private:
    PyGILState_STATE _gstate;
};

works.
The next issue has to do with the exports declared in an anonymous namespace in PyImathStringTable.cpp -- these have internal linkage, and so Clang errors out because __declspec(dllexport) was used on functions without external linkage. I'm actually unsure as to how MSVC handles this case (I haven't checked a dump for these symbols), but I'm assuming that it's similar to the above scenario.

PyImathStringTable.cpp lines 91-94
namespace {
template class PYIMATH_EXPORT StringTableDetailT<std::string>;
template class PYIMATH_EXPORT StringTableDetailT<std::wstring>;
}

I'm currently working on a fork to fix compile errors when using Clang on Windows. I've managed to get the program to compile; I still need to run tests to verify that I didn't inadvertently break the python bindings. Before I propose the removal of PYIMATH_EXPORT being assigned to the deleted functions, I did want to ask if there's a reason for it to be there -- I'll admit I'm not very familiar with building libraries for sharing, and know little about how symbol visibility and exports are handled beyond what I've managed to look up in response to this error, or how __attribute__((visibility("default"))) behaves in environments where that is declared instead. If it wouldn't cause issues (and assuming it's not too minor for a PR), I'll submit a PR once I've got things working -- currently I'm fixing my PATH to include the required DLL's from boost for the python tests to run.

I'm having trouble getting the python binding tests to run; ctest is not properly setting up the environment to load all required dll's for the module. This is probably because I'm making use of python 3.10, and if I recall correctly python 3.8+ require some extra steps to load dll's that aren't in the same directory (it no longer checks PATH). That said, setting up the directories in a test script I wrote appears to properly load the module. I'll try rebuilding boost.python with python 3.7 later to check if I can't get the tests working.

See also https://github.com/AcademySoftwareFoundation/Imath/issues/312#issuecomment-1508302944 and further discussion. There is indeed something not quite right w/ the exports...

An update; I have managed to get the numpy test and python3 test to run (still no luck on PyImathTestC, I'll have to figure out what's up with that). PyImathTest_Python3 fails on M44
[ctest] Running testM44
[ctest] M44f
[ctest] ok
[ctest] M44d
[ctest] Traceback (most recent call last):
[ctest]   File "D:\Code\lib\Imathfork\src\python\PyImathTest\pyImathTest.in", line 10327, in <module>
[ctest]     test[1]()
[ctest]   File "D:\Code\lib\Imathfork\src\python\PyImathTest\pyImathTest.in", line 6323, in testM44
[ctest]     testM44x (M44d, V3d)
[ctest]   File "D:\Code\lib\Imathfork\src\python\PyImathTest\pyImathTest.in", line 6153, in testM44x
[ctest]     assert sInq.equalWithAbsError(s, sInq.baseTypeEpsilon())
[ctest] AssertionError

Belated thanks for the investigation. The PYIMATH_EXPORT on both the deleted members and in the anonymous namespace are almost certainly oversights. If you have a PR you can submit for that, we'll happily accept it.
It looks like we need to re-examine the other exports in PyImath. We have a bunch of internal code that relies on this library, but we don't compile it with either clang or Windows, so I can't easily reproduce #312.
Regarding the failed assertion in testM44, could you also print out s-Sinq? I suspect it's close to baseTypeEpsilon but would like to see for sure.

Apologies for the large delay @cary-ilm; I've had a hectic couple of weeks. I'll go ahead and submit a PR, details on the changes will be in the request (not many lines were changed; I didn't spot any other exports that were clearly incorrect).
Here's the values on the failed M44d test:
[ctest] M44d
[ctest] s: V3d(1, 2, 3)
[ctest] sInq: V3d(1, 2, 3)
[ctest] sInq.baseTypeEpsilon(): 2.220446049250313e-16
[ctest] s-sInq: V3d(0, -4.44089e-16, 0)
[ctest] s[1]: 2.0
[ctest] sInq[1]: 2.0000000000000004

It looks like the precision error is two represent-able double values off, instead of the minimum epsilon. Interestingly, this doesn't seem to be an issue for the extracted shear, rotation, or translation vectors; ignoring the assert on s and sInq, all other tests pass.
I did manage to get PyImathTestC running -- it fails on Plane. I haven't had a chance to dig into that yet.
Should I open a separate issue for the failed tests?

Thanks for that analysis.  I'm pretty sure the purpose of that test is to confirm that m.extractSHRT is performing the right calculation, not to test floating-point precision, although it's a little concerning that it fails on your machine and not on the many others it's been executed over the years. That file has a long history and has a variety of validation strategies, many of which are substantially looser, as in the use of the eps=10*FLT_EPSILON at top. I'm also not sure of the purpose behind the 2* in the comparison; the bounds on the shear and translation comparison are epsilon, but the scale and rotation are twice that, for no obvious reason. If you change the 2 to a 4, does the test pass? If so, I'm fine with that, can you just submit that as a PR? Thanks.

I can believe I'm an edge case on the tests; my environment has caused some strange behavior on other projects in the past. Turns out compiling with -march=native for a release build causes PyImathTestC to pass (that would be targeting Haswell feature set, I'm on an i7-4770k). The thought of digging into exactly which enabled target feature causes the difference is giving me a headache already; I'm inclined to just accept that a release build will pass tests and not worry about that further, since you've mentioned that the tests seem to pass fine on other machines. That said, I'd be willing to dig further in to see which section is failing on a build not compiled with target features. No such luck with PyImathTest itself, though. I'm going to double check what compilation flags are being enabled in my environment, though I'm fairly certain no unsafe fp optimizations are enabled.
The assert that fails is on line 6244 of pyImathTest.in, which I believe is the scale; it doesn't have a multiplier on the epsilon. I think I know which code you're referring to, though -- it looks like in the M33x tests there is a multiplier on the epsilon for the scale; perhaps a similar issue came up in the past and that extra wiggle room was added there, but the M44x test wasn't changed. Looking at the revision history it looks like both tests were added 12 years ago and this section hasn't been touched much since then; looks like I'm the lucky one where the difference became relevant, haha.
    # The M33x test
    b = m.extractSHRT(sInq, hInq, rInq, tInq)

    assert sInq.equalWithAbsError(s, 2 * sInq.baseTypeEpsilon())
    assert hInq.equalWithAbsError(h, hInq.baseTypeEpsilon())
    assert rInq.equalWithAbsError((-a, 0), 2 * rInq.baseTypeEpsilon())
    assert tInq.equalWithAbsError(t, tInq.baseTypeEpsilon())

    # The M44x test
    b = m.extractSHRT(sInq, hInq, rInq, tInq)

    assert sInq.equalWithAbsError(s, sInq.baseTypeEpsilon()) # line 6244, this is the assert that fails
    assert hInq.equalWithAbsError(h, hInq.baseTypeEpsilon())
    assert rInq.equalWithAbsError((0, 0, -a), 2 * rInq.baseTypeEpsilon())
    assert tInq.equalWithAbsError(t, tInq.baseTypeEpsilon())

Adding a multiplier to be 2*basetypeepsilon should work, since what I'm getting is the next representable value after 2 -- the difference should be exactly twice the base epsilon for double. I'll check in a bit and edit this comment afterwards.

As a follow-up before I submit a PR to just change the test, a quick note:
Most of the tests seem to use baseTypeEpsilon() as the epsilon value, occasionally with a multiplier. Looking at where this is declared in the Imath files, these all return std::numeric_limits<T>::epsilon(). I'll admit I'm unfamiliar with best practicies regarding floating point comparisons in unit tests, but using std::numeric_limits::epsilon() doesn't seem very well-suited to comparisons for values above 1.0 if it's acceptable to have precision error. It returns the difference between 1.0 and the next representable value after 1.0. Each power of two left of the decimal is going to lead to a doubling of the difference between the integer values used in tests and the next representable double. To highlight what I mean, here's a quick c++ showcase:
#include <iostream>
#include <iomanip>
#include <limits>
#include <cmath>

using namespace std;

int main()
{
    double baseEp = std::numeric_limits<double>::epsilon();
    double deltaone = std::nextafter(1.0, 2.0) - 1.0;
    double deltatwo = std::nextafter(2.0, 3.0) - 2.0;
    double deltathree = std::nextafter(3.0, 4.0) - 3.0;
    double deltafour = std::nextafter(4.0, 5.0) - 4.0;
    double deltaseven = std::nextafter(7.0, 8.0) - 7.0;
    double deltaeight = std::nextafter(8.0, 9.0) - 8.0;
    cout << std::setprecision(17)
        << "numeric_limits<double>::epsilon(): " << baseEp << endl
        << "Delta after one: " << deltaone << endl
        << "Delta after two: " << deltatwo << endl
        << "Delta after three: " << deltathree << endl
        << "Delta after four: " << deltafour << endl
        << "Delta after seven: " << deltaseven << endl
        << "Delta after eight: " << deltaeight << endl
        << "Deltatwo / deltaone: " << deltatwo / deltaone << endl
        << "Deltafour / deltaone: " << deltafour / deltaone << endl
        << "Deltaeight / deltaone: " << deltaeight / deltaone << endl
        ;

    return 0;
}

The output of this is:
numeric_limits<double>::epsilon(): 2.2204460492503131e-16
Delta after one: 2.2204460492503131e-16
Delta after two: 4.4408920985006262e-16
Delta after three: 4.4408920985006262e-16
Delta after four: 8.8817841970012523e-16
Delta after seven: 8.8817841970012523e-16
Delta after eight: 1.7763568394002505e-15
Deltatwo / deltaone: 2
Deltafour / deltaone: 4
Deltaeight / deltaone: 8

This means that for values >= 2.0, unless there's a multiplier used in the test for the epsilon value, equalWithAbsError is checking for exact floating point equivalence.

@cary-ilm I believe I understand why the bounds are raised for scale but not for the shear or the translation, looking at the matrix the vectors are extracted from and the values being compared. This is for M44x tests, but the same holds true for the M33x tests where you saw the difference in bounds.
    s = Vec(1, 2, 3)
    h = Vec(0.5, 1, 0.75)
    a = pi/4
    t = Vec(4, 5, 6)

    ...

    # this isn't in the code, but this is the value of m before extraction
    m = M44d((0.70710678118654757, -0.70710678118654757, 0, 0),
        (2.1213203435596428, 0.70710678118654757, 0, 0),
        (3.7123106012293747, -0.5303300858899106, 3, 0),
        (4, 5, 6, 1))

S contains values >= 2.0 but < 4.0, so multiplying the baseTypeEpsilon value by 2 allows for precision error up to one representable value away. The values for shear are all less than 2.0, so this multiplier isn't needed. The values expected for translation are unaltered, and there shouldn't be precision error introduced, so it's fine to check for exact equivalence. I am mildly surprised to see that there's a multiplier for the rotation, since the comparison is on values less than one; I wouldn't expect there to be error greater than one value away.

Thank you for that analysis and the fix. I'm not all that familiar with the history of the various sections of that test, many people have contributed to it over the years, but it certainly looks like many of the comparisons aren't especially scientific or precise, both the ones that are looser than necessary as well as in the case of your failure, too tight.  But it's certainly appropriate for the M33 and M44 tests to be similar.


Still continue appear message warning: Deprecated

In " \zend-mvc\src\Controller\AbstractController.php on line 258 "
Let me see if I got it right. I can not use getServiceLocator() in the controller? I have to send all pendencies by factories? Even extending AbstractActionController?

@wtabata Yes. We're emitting it at that location for a number of reasons:

We had to remove the ServiceLocatorAwareInterface implementation from AbstractController due to the fact that it does not exist in zend-servicemanager v3; we want developers to be able to upgrade to that version if desired, but we could not do so while still implementing that interface.
For backwards compatibility purposes, we need to still inject the service locator, even if users never consume it. Doing so, however, should not emit a deprecation notice, because we cannot know if it is even being used.
When developers call getServiceLocator() from within their controllers, then we know they are using it, and that's when we need to raise the deprecation notice.

Because ServiceLocatorAwareInterface is removed from zend-servicemanager v3, and because we plan to remove the initializers for it in zend-mvc v3, we are using the deprecation notices to signal to users when and where they need to make changes to their code to make it forwards compatible.
We have been recommending for literally years that developers not pull dependencies from the composed service locator, and instead directly inject their dependencies. We recommend this for several reasons:

Explicitness. If you require dependencies via your constructor and/or setters, you can tell by the method signatures precisely what your class requires in order to operate. This allows you to know what components, libraries, modules, etc. you need to install.
Testing. It's far easier to test when you can directly inject your collaborators, vs. injecting into a service container, and injecting the service container. Additionally, without explicit dependencies, writing tests becomes cumbersome as you need to understand the code internals to know what dependencies will be fetched from the service container for any given code path or behavior.

While we recognize that during early development of a controller, it's often easier to pull stuff out of the service locator, we feel that for the reasons stated above, it's an anti-pattern, and will lead to costly maintenance eventually. For these reasons, we'll be removing this capability in zend-mvc v3.
If you rely on that capability, you have several choices:

Pin to an earlier version of zend-mvc (versions earlier than 2.7). Be aware, however, that these may not continue to receive security updates.
Use zend-mvc 2.7, and either disable reporting of deprecation notices via the error_reporting INI configuration or the display_errors configuration.
When v3 drops, you can always add your own initializer for this capability. However, you will also need to re-add the methods for injection and retrieval of the service locator in your controllers.

Alternately: start updating your code to remove this usage, as your code and maintenance will benefit from the changes.

@weierophinney terrific!!

Thanks for the extensive explanation!
But still I have an issue regarding to "Alternately: start updating your code to remove this usage...".
I already have all dependencies injected via factory in constructor and I never use getServiceLocator() method (but I am using ControllerPlugins).
Should we remove "MyController extended AbstractActionController" ?
I didn't found in migration guide clearly what should be the replacement and best practice for this case ?

Which plugins are you using, specifically?
On Mar 3, 2016 11:29 AM, "Alex"<EMAIL_ADDRESS>wrote:

Thanks for the extensive explanation!
But still I have an issue regarding to "Alternately: start updating your
code to remove this usage...".
I already have all dependencies injected via factory in constructor and I
never use getServiceLocator() method (but I am using ControllerPlugins).
Should we remove "MyController extended AbstractActionController" ?
I didn't found in migration guide clearly what should be the replacement
and best practice for this case ?
—
Reply to this email directly or view it on GitHub
https://github.com/zendframework/zend-mvc/issues/89#issuecomment-191874003
.

Redirect, FlashMessenger, Identity, Params and Layout.
I don't have message warning: Deprecated anymore, I am just curious about migration to new zend-mvc.
Should we do something else except remove usage of  getServiceLocator() in Controller.

Small offtopic, but related:

you can tell by the method signatures precisely what your class requires in order to operate.
What possibilities to sign setter to be clear is required for this class (by constructor is clear)?

@ronan-gloo We provided an answer to that scenario (conditional dependencies) in ZF 2.3, via lazy services. The recommendation is to use lazy services when you have a dependency that is only used in some code paths; these are injected as normal dependencies, i.e., via constructor or setter injection. The benefit they provide is that the "heavy" service is not retrieved from the service container until first access of any method on the service instance.
So, yes, the recommendation of injecting all services vs pulling them from a composed service locator still stands. The addition of lazy services to zend-servicemanager was what allowed us to unequivocally recommend the practice.

Hi,
how should I order the Doctrine\ORM\EntityManager now? The documentation recommends that you do the getServiceLocator ( )

I think we should correct documentation with the correct method, so we avoided continue to develop wrong code.

Hate to sound like a dinosaur ... but by forcing developers to pre-inject everything, we're back to the good old create a base class and extend it paradigm.  The idea of inversion-of-control is that we're not bogging down classes with unneeded functionality, right?  So if I have a controller where 1 method needs X and 4 methods do not, by pre-injecting X I'm wasting resources 80% of the time.

Hey Doug,
The fact that you pre-inject things that you won't use indicates some SRP
issues. Regardless of that, you can still just make the injected services
lazy, which will prevent any init-time I/O
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On 30 March 2016 at 03:04, Doug Bierer<EMAIL_ADDRESS>wrote:

Hate to sound like a dinosaur ... but by forcing developers to pre-inject
everything, we're back to the good old create a base class and extend it
paradigm. The idea of inversion-of-control is that we're not bogging down
classes with unneeded functionality, right? So if I have a controller where
1 method needs X and 4 methods do not, by pre-injecting X I'm wasting
resources 80% of the time.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/zendframework/zend-mvc/issues/89#issuecomment-203177512


(calibre) switch to non-embedded

Description
Switches Calibre to non-embedded
Motivation and Context
Installer now makes package too big for embedded on CCR
How Has this Been Tested?
Tested on Windows 10 and in Chocolatey test env
Screenshot (if appropriate, usually isn't needed):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[x] My code follows the code style of this repository.
[ ] My change requires a change to documentation (this usually means the notes in the description of a package).
[ ] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[ ] I have updated the package description and it is less than 4000 characters.
[x] All files are up to date with the latest Contributing Guidelines
[x] The added/modified package passed install/uninstall in the Chocolatey Test Environment(https://github.com/chocolatey-community/chocolatey-test-environment/). Note that we don't support the use of any other environment.
[x] The changes only affect a single package (not including meta package).

:white_check_mark: Package verification completed without issues. PR is now pending human review

Calibre is up to version 7.20 now from the 7.17 that last passed all the check automatically. Hoping to see this soon.


Y axis on chart in firefox is being drawn outside of its lines

The most recent price (blue tag) shifts left & right as you move your cursor over the chart. This behaviour seems to happen with all the chart types, but is far worse for candlesticks and area charts where you can see more clearly the cause of the problem. It seems as though the chart is being drawn correctly but then it is being drawn over the axis too causing the most recent price indicator to shift right a bit. Check the video for example:bandicam 2016-02-01 08-44-43-589.zip
Uploaded using ZenHub.io

Problem seems to also exist within the X axis labelling when you are using the navigation tool to scroll across the graph. After dragging and moving the position of the visible graph, the labels are being redrawn briefly in the wrong place and then they are being moved down a littlebandicam 2016-02-01 08-56-59-105.zip
Uploaded using ZenHub.io


Cursor jumps to the start of input when changing input type

[x ] The issue is present in the latest release.
[ x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
Cursor jumps to the start of input when changing input type
Expected Behavior 🤔
Cursor preserves its position when changing input type
Steps to Reproduce 🕹
Steps:

Create textfield with password input type and visibility toggler like this: https://material-ui.com/components/text-fields/#input-adornments
Input some text
Click password visibility icon button
Cursor jumps to the start of input

Context 🔦

Your Environment 🌎
Version 90.0.4430.85 (Official Build) (x86_64)

`npx @material-ui/envinfo`
  Don't forget to mention which browser you used.
  Output from `npx @material-ui/envinfo` goes here.

Weird, it works correctly with CRA https://codesandbox.io/s/naughty-nightingale-8luwv?file=/src/Demo.tsx but fails with Next.js https://codesandbox.io/s/upbeat-ardinghelli-xw8kn?file=/pages/index.js

Likely similar to https://github.com/mui-org/material-ui/issues/23096

I could reproduce the issue with a <input, it doesn't seem related to Material-UI.

@oliviertassinari True, It's more of a javascript issue. The cause of this issue is focus handling when visibility toggler is clicked, it shifts the  focus from input box to toggle icon, in order to save it from shifting focus, a function needs to be run on mouseDown event of icon, like <Icon onMouseDown = {(e) => e.preventDefault()} />  similar to input adornments https://material-ui.com/components/text-fields/#input-adornments

@gupta-piyush19 that's correct, but I already implemented e.preventDefault() as docs suggested

@gupta-piyush19 that's correct, but I already implemented e.preventDefault() as docs suggested

on which component have you implemented preventDefault() on the input field or icon?

The same bug without Material-UI:

CRA: https://codesandbox.io/s/silly-elbakyan-udgtk?file=/src/Demo.tsx:0-855
Next.js: https://codesandbox.io/s/trusting-sun-s2yuj?file=/pages/index.js

@gupta-piyush19 that's correct, but I already implemented e.preventDefault() as docs suggested

on which component have you implemented preventDefault() on the input field or icon?

on Icon

I found a workaround to this problem by calling preventDefault() on the onMouseUp event as well.
https://codesandbox.io/s/admiring-bash-htted?file=/pages/index.js
I wasn't able to track down this bug but I don't think it's React fault since it works properly on CRA.
Hope it helps

It was weirdly difficult to find this issue, so I'm going to mention several keywords here:
Cursor resets on input type change from password to text and back

I found a workaround to this problem by calling preventDefault() on the onMouseUp event as well.
https://codesandbox.io/s/admiring-bash-htted?file=/pages/index.js
I wasn't able to track down this bug but I don't think it's React fault since it works properly on CRA.
Hope it helps

Thanks for the workaround. It works in vite as well.

I found a workaround to this problem by calling preventDefault() on the onMouseUp event as well.
https://codesandbox.io/s/admiring-bash-htted?file=/pages/index.js
I wasn't able to track down this bug but I don't think it's React fault since it works properly on CRA.
Hope it helps

that actually helped
I put those as props on IconButton:  onMouseDown={(event) => {
event.preventDefault();
}}
onMouseUp={(event) => {
event.preventDefault();
}}

I got the error with next.js using chrome on mobile. Not in Firefox.   onMouseDown={(event) => {   event.preventDefault(); }} doesn't work.


Usage of embedded, unexported types, makes for poor docs

For example, the implementation of BlobGetPropertiesResponse uses an anonymously embedded type that's not exported.  Unfortunately this breaks the documentation experience.
https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob#BlobGetPropertiesResponse
As you can see, none of the exported fields in blobClientGetPropertiesResponse show up in the docs.
This pattern needs to be removed.

I am a Go developer attempting to find the last modified timestamp of a file blob, and due to this issue, the LastModified value or ANY file metadata for that matter can't be accessed:
https://github.com/Azure/azure-sdk-for-go/blob/8dce4d522a207952d9f0ac2b56b61b9b595b67b6/sdk/storage/azblob/zz_generated_response_types.go#L712
Thanks much @jhendrixMSFT !

Fixed in upcoming<EMAIL_ADDRESS>


Priority handling in the Pthread library is still missing

The implementation should be verified.

Heyy @stlankes I am interested in working on this feature. Can you please guide me a little more about what exactly is to be done?Thanks in advance!!

I use a small library to realize POSIX threads. The function pte_osThreadCreate calls my kernel. I never checked if we pass correctly the priority to the kernel.

I think changing it to pthread_setschedparam() function might correctly prioritize.


Variable is already defined in class

If a user puts a property in their GraphQL schema in all caps the Java code generation creates a conflict between the ModelField variable name and the QueryField variable name because they are both named identically. This would be a breaking change to fix so perhaps we need to just document that we don't support all caps type fields but wanted to raise the issue here to discuss.

Closing as this issue is now resolved with https://github.com/aws-amplify/amplify-cli/pull/5500


📦 NEW : Blockchain ---> Job-Boards

Hi, I wanted to add a new job hunting website in the /Blockchain ---> Job-Boards folder. Can I create a PR ?
Thanks :)

Just do it already man. The PR will be reviewed regardless.

Hey @ishvinder-singh as @cosmicqbit you can go ahead with the PR. We make sure to review every PR


Add DoubleEndedIterator to queue iterators

The implementation is pretty straightforward and it's useful

Thanks!
bors r+


Update README.md

Indent Ruby code.

Thanks for the PR! Looks good to me. Currently working to get Travis CI setup and would like to wait until then to merge in new PRs.

sounds good!

Hi @jbrophy17 I'm finally merging this a year later 😂


Prettier readme

Are you fine with making the readme markdown Prettier compliant?
It mostly wants to remove extra whitespace, use "`" over "~" and prefer "-" over "*". I can make a separate PR for that. It would make contributing changes easier.

I LOVE prettier but I always disable it for markdown files... I really don't like its styling choices :(
I understand updating the readme might be annoying, but I can handle that if it's too painful.

Let's commit a .prettierignore then.


make input bind to disabled

example:
{{input zip label="PLZ" disabled='zipDisabled'}}

Thank you for submitting this PR, but it's not necessary anymore.
Most of the code of the library was rewritten to be compatible with Ember 1.13, and this is already fixed in the most recent version.
You can get the most recent version of ember-easy-form on the branch 1-0-stable or as an ember-addon here.


Where is the release commit?

I've updated my firmware using the publicly-release snapshot https://kinesis-ergo.com/download/adv360-pro-factory-default-branch-3-0-v1-16-24-commit-ddcdb88/
I now need to manually remap everything to support my macOS/Dvorak layout, and I want to do so atop that same curated commit.
However, the commit ddcdb88 is not in this repository. Nor is there a single branch or tag in this repository for anything other than the development tip.
Please make a release branch available that tracks the canonical public releases, so that users can fork/track those and not a development branch.

The factory firmware tracks the firmware here, but has an additional commit to change the keymap. When changes are made here that change the actual firmware (e.g. not changes to the makefile or ci processes) the factory firmware gets updated.
The branch here can be considered the authoritative release branch, as we have another mechanism for development/beta testing that can be seen in the readme

Thanks for the prompt reply.  I feel like I've seen a lot of churn on the GitHub issues so I have been under the impression that this repository is not particularly stable.  Thus I've held off on the 3.0 update until forced into it today when my right keywell suddenly refused to connect.
I'm also curious why there's keycap changes to the factory firmware that aren't in-sync with the baseline you provide to customers that need to customize anything.  (Which AFAICT includes everyone who's not on a Windows+QWERTY layout.)

The factory firmware is the keymap here, except with the four macro keys mapped to keycodes to facilitate testing during assembly. It is expected that customers who will be changing the default keymap will have their own uses for these four keys. There are a few different default firmwares available to download here including Dvorak: https://kinesis-ergo.com/support/kb360pro
I can understand the concern about stability, but we're always trying to improve the experience with each update

I think i'm going to close this issue as solved now, for the avoidance of doubt we always recommend using the latest state of this repo to base any keymap customisations off of, and fetching upstream when new commits are added


[Feature] Keyword to redirect to API Page with query params already set

Description
Inside an introduction page for one of our library, I wanted to redirect the user to the API Page where the scope of this project is already set.
It should also be interesting to have the same for the Type field, and future other fields
Proposed solution
When I click on API IO, I'm already on this page with the URL [hostname]/api?scope=IO (where in local, hostname is http://localhost:4200) :

Alternatives considered
Tried using KeywordLoader, but it is difficult to get the current hostname and it creates another tab inside the browser, which is not the desired behavior. Or I can use the new Page Processor, I will investigate

:tada: This issue has been resolved in version 16.11.0 :tada:
The release is available on:

v16.11.0
GitHub release

Your semantic-release bot :package::rocket:


{{url}} prints "Invalid date" on preview

Issue Summary
When I open preview of a post, the {{post.url}} contains very weird string eg.:
/Invalid date/Invalid date/Invalid date/dsadsa/. The {{url}} helper also prints the same.
I've discovered this because I had some troubles with invalid URLs in Disqus. Apparently once the post preview is opened, Disqus caches this invalid URL and uses it even after the post is published.
I've managed to overcome this problem by conditionally excluding Disqus when post is not published: {{#if published_at}}, however I'm sure this is a bug and it should be fixed somehow.
Steps to Reproduce

Add {{post.url}} somewhere in your post template Handlebars file.
Create a new post, don't publish, just click "preview".
There you go.

Expected output: Not really sure about that, either empty string or a link to the post preview (UUID). Up for discussion.
Technical details:

Ghost Version: 0.8.0.
Node Version: 4.3.1
Browser/OS: OS X / any browser
Database: sqlite3

Hey @mmiszy
Thanks for the bug report - I will fix this bug next week.
If date permalinks are enabled and no published date available, we could generate the url based on today.

Thanks for quick response! This will certainly fix unexpected output from {{url}}.
However, the URL-caching issue still remains. Currently I'm using conditional {{#if published_at}} but it doesn't feel right – do you think it would be possible to add some kind of a Handlebars helper to detect whether post is being previewed or is published?

@mmiszy the preview is designed to be as close to real-life as possible so there are no easy hooks to manipulate the output when in preview mode at the moment. For now I would suggest if you have external services that will cache things when you visit pages that you block them from doing that on /p/* urls

Sounds reasonable. Thanks a lot!


doesn't compile with gcc-7

/home/barriosj/hobbes-orig/lib/hobbes/events/httpd.C: In member function ‘bool hobbes::PartialHTTPRequestState::transition(char)’:
/home/barriosj/hobbes-orig/lib/hobbes/events/httpd.C:72:7: error: this statement may fall through [-Werror=implicit-fallthrough=]
       if (c != ' ') {
       ^~
/home/barriosj/hobbes-orig/lib/hobbes/events/httpd.C:81:5: note: here
     case FindHeaderBegin:
     ^~~~
cc1plus: all warnings being treated as errors
CMakeFiles/hobbes-pic.dir/build.make:422: recipe for target 'CMakeFiles/hobbes-pic.dir/lib/hobbes/events/httpd.C.o' failed
make[2]: *** [CMakeFiles/hobbes-pic.dir/lib/hobbes/events/httpd.C.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/hobbes-pic.dir/all' failed
make[1]: *** [CMakeFiles/hobbes-pic.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

I think having all warnings be errors might be slightly heavy handed in that new gcc versions have more warnings.

Good to hear from you jeb!
Internally we are a little behind on gcc versions, but we have some large programs where we embed hobbes and have warnings-as-errors enabled in those projects.  So to be on the safe side (to avoid awkward/painful integration issues when embedding hobbes in those projects), I have hobbes set to build with warnings as errors too.
Maybe it's worth adding a CI job for gcc7.

Oh that makes sense.


rest-client uses system proxy even though RestClient.proxy is set to nil

Hi!
We encountered a problem in ruby-2.0.0p195. Requests made by rest-client used the system's underlying proxy (in this case the environment variable http_proxy on Unix/Linux/Mac) even though RestClient.proxy was set to nil. We believe this is due to a change in net/http in ruby 2.
We forked rest-client and we have a fix here: https://github.com/bring/kp-rest-client/commit/cc872eb643e57e6ee13c0533c0c55f545ed0e4b1
Please consider pulling this commit into rest-client :)
Best Regards
Trond Valen

The current implementation does not seem to use the system proxy value, at least after require; i.e.
$ pry
[1] pry(main)> require 'rest-client'
=> true
[2] pry(main)> RestClient.proxy
=> nil
[3] pry(main)> ENV['http_proxy']
=> "http://proxy.example.org:80"

That is, the RestClient.proxy value is not representing whether the system proxy is used or not.  However, when a request is sent, the system proxy may be used; e.g.
[4] pry(main)> response = RestClient.get 'http://www.google.com';
[5] pry(main)> response.code
=> 200

Fixed by https://github.com/rest-client/rest-client/pull/383


stop ignoring some lint rules

i'm actually surprised we had so many useless f-strings here

Yeah, I wonder why we ignored that rule in the first place, doesn't seems like it would change any behaviour in the code 🤔


[WIP] A third gfx example

Depends on #2071 and #2052
PR checklist:

[ ] make succeeds (on *nix)
[ ] make reftests succeeds
[ ] tested examples with the following backends:

I'll reopen this when I work on more examples again.

We can get around manually dropping things by ordering the members in the struct definitions in the order we want to drop them. I feel, however, that manually drop helps document the order in which you should be dropping things. I think you'll agree that It would be annoying if changing the order of the members in a struct caused bugs.
As for takeable, no. The hal destroy functions want ownership & drop only gets an &mut.

We can get around manually dropping things by ordering the members in the struct definitions in the order we want to drop them.

Do you really have to drop things in a specific order with HAL? AFAIK, Vulkan says destruction order can be arbitrary.

Other than the swapchain, no. I removed all the manuallydrop and just made the swapchain takeable.

Thank you!
I'm still not sure we need takeable_option magic though. Would the code be much worse if it had a few regular Option members of structs? In the worst case, we'll have something like as_mut().unwrap() in a place or two, but using a standard construct (Option) is way friendlier.

@kvark You can compare the two versions and see which you prefer. I personally like Takeable (else I wouldn't have made it).

@ZeGentzy thank you, looks great! Let's fix the CI issues and get this merged.

@kvark Done.

Bors  r+

On Jul 20, 2018, at 21:56, Hal Gentz<EMAIL_ADDRESS>wrote:
@kvark Done.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


refactor: missing barcode spec

Related to https://github.com/rubyforgood/human-essentials/issues/4199
Last spec!!! It somehow got missed.
Type of change

Refactor

How Has This Been Tested?
Passes current suite

https://github.com/rubyforgood/human-essentials/pull/4206 removes all seeding behavior and is rebased on top of this PR. So it's good to go as soon as this one is.


Removed generator functionality

Removed all generator related functionality, dependencies, unused functions

👍

👍
Luca, if your happy..

should i merge?

Yes, I'm happy enough with.
Kindest Regards,
Dean
On 14 Jul 2016, at 13:46, Mihai Dima <notifications<EMAIL_ADDRESS>wrote:
should i merge?

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/apparatus/fuge/pull/115#issuecomment-232655315, or mute the threadhttps://github.com/notifications/unsubscribe/ADdT6WR_8nxEmDZk89iRHvXlrsutIX_dks5qVi-igaJpZM4JLc-H.


Square in toolbar isn't quite clean

Above: Toolbar square
Below: Orphaned square

You're right :) planning to fix that this week hopefully #272

Done! 7b2d1ff45812669b4dfeeebd90cec8df5675f2a1


Drain fails to interact with other containers using Fabric Transfer API, crashing the world

Describe the Bug
Trying to transfer multiple items to a drain crashes the game
Reproduction Steps

Place a drain in the world
Connect it to an item pipe from other mods, for instance an IndRev item pipe
Insert multiple things
the game perishes in silence oh no

Expected Result
Things don't go wrong and if multiple buckets are inserted, bucket should pop off
Screenshots and Videos
No response
Crash Report or Log
https://paste.gg/p/anonymous/682b158290484ee3ba5367f20931d560
Operating System
Arch Linux
Mod Version
0.4.0d
Minecraft Version
1.18.1
Other Mods
indrev, ae2, modern industrialization are the best candidates to test the aformentioned behavior
Additional Context
No response

Please test this on build 482 or newer. If this issue still occurs, please re-open it.


Add all in one executable to future releases

Hello and thank you for working on this awesome project.
It would be nice, if you could build an executable that does not need python to be installed on the system. I know that youtube-dl achieved this somehow.
Thank you.

If some one who has done it before has a tutorial on how to attempt this, I will try

You could try it with auto-py-to-exe.

Which file would be the entry point to build the exe from?

I haven't had time to try and do this, so if you want to please feel free.  Would appreciate it.  From what I understand maybe the same as the pip? backgroundremover.cmd.cli

No worries. If anyone else comes across this and can point me in the right direction, this is where I'm stuck: https://nitratine.net/blog/post/issues-when-using-auto-py-to-exe#how-do-i-convert-all-my-python-files


update to 0.90 please

oh, looks like this functionality is now part of stock http://wiki.kerbalspaceprogram.com/wiki/Crew
Thanks anyway :smile:

oh, looks like this functionality is now part of stock http://wiki.kerbalspaceprogram.com/wiki/Crew
Thanks anyway :smile:


update-bootengine: use the native ldconfig

ldconfig does not work on non-native arches. Use the ldconfig
present in the target chroot to properly create the library cache.

LGTM


Add patch file to midstream-1.2.2 branch for database setup

The upstream PR here https://github.com/sigstore/rekor/pull/1708 ensures that if the pod goes down and comes back up again, the mysql instance will correctly start up.
The changes in the upstream PR need to be provided as a patch to midstream-v1.2.2.

Will do, Im assuming we do not not need it on main as well? @lance

Will do, Im assuming we do not not need it on main as well? @lance

No it will be included on commits to upstream main already. Thanks for taking care of this!


Please update info that it is also for web

Scanning through som solutions for draw on image for flutter web, this was promising, until I saw it was not mentioned it was for WEB until I read the version information (as I "never" do...).

Please update the "aiming" list that it is for WEB too...

Those tags are generated by pub.dev itself. In this library example, we are using dart:io library to export the image into a file. Since that library doesn't support the web, it sees the package as not supported by the web. Also, this package is up to date with Flutter mobile stable releases but isn't tested on the web for every release. Thank you for the suggestion though. That is something I can look into.


[HOLD] Replace count with block for core & sql managed rules to WAF

Who is this for?
Part of https://github.com/wellcomecollection/wellcomecollection.org/issues/10511
Following https://github.com/wellcomecollection/wellcomecollection.org/pull/10510
Here's the graph of requests being noticed by the WAF from late last week when the new rules were added:

Link (experience account)
The rules matched seem overwhelmingly to be UserAgent_BadBots_HEADER from the Core rule set.
I don't foresee an issue with enabling blocking against these rulesets. The description for this rule is:
Inspects for common User-Agent header values that indicate that the request is a bad bot. Example patterns include nessus, and nmap. For bot management, see also AWS WAF Bot Control rule group.

nessus and nmap are vulnerability scanning tools.
What is it doing for them?
This change is enabling request blocking after monitoring the requests which match the new rules blocked. The intention is to stop more requests falling through the service itself and reduce the quantity of alarms that we receive that don't need attention.
How to test?

[ ] Deploy to production, ensure that the WAF rules have been updated as expected. Be vigilant for errors caused by blocking potentially valid requests.

[!WARNING]
We are holding deployment until after the festive break. Problems are unlikely but not worth the risk!

Closing as superseded by https://github.com/wellcomecollection/wellcomecollection.org/pull/10533/files


Share your designs on social media

Use #OpenCode19 hashtags while you share.
Comment the Screenshots here!

Done!

done

Done.

Done


check that downward api supports dots in field paths

just a little unit test that shows how to use downward api field path with dots.

@cppforlife just putting this back on your radar so we can get it merged in


Extend MuxApplication to be able to take care of resource handling

In the context of startMux, when it starts all the treads, run a supplied bracket like function and share the created resource with spinned threads.  This way we could run bracketFetchClient to create and share FetchClientContext in chain-sync and block-fetch mini-protocols.

If we use the p2p governor, and do the mux refactoring we'll probably want to include this.


Merge to master

This change is

Reviewed 1 of 2 files at r1, 9 of 12 files at r2, 1 of 1 files at r3, 1 of 1 files at r4, 15 of 15 files at r5.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 2 of 2 files at r6.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 1 of 1 files at r7.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 1 of 1 files at r8, 4 of 4 files at r9.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 3 of 3 files at r10, 1 of 1 files at r11.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


基于wechaty开发的医疗小助手

Please make sure to check the following boxes creating your pull request, thank you very much!

[ ] Add Blog Header, including title, author, image, categories, tags, etc.
For example:
---
title: Your Great Blog Title
author: your_github_id
categories: project
tags:
  - python
  - padlocal
image: /assets/2021/02-your-blog-slug/teaser.jpg
---

One line bio

Your blog post content Your blog post content
Your blog post content Your blog post content
Your blog post content Your blog post content

It will be easier to start drafting your post by using a existing post file as your template, for example, this one

[ ] Keep all filenames lowercase, and use - to connect words instead of space. e.g. 2017-10-06-wechat-pc-impactor.md instead of 2017-10-06-WeChat PC Impactor.md

[ ] Embed video/pdf from YouTube/Bilibili/local (if there's any) by using {% include iframe.html src="URL_or_PATH" %}. (Learn more about how to embed file/url in the post by reading this blog post

[ ] Save photo to local before publishing, to a folder named by ${MONTH}-${YOUR_BLOG_SLUG}/ under /assets/2021/ directory.

[ ] Select a beautiful and meaningful teaser image for your blog

[ ] Create your contributor profile (if you are a first time contributor)
For excample:

jekyll/_contributors/lijiarui.md

---
name: Jiarui LI (李佳芮)
site: https://lijiarui.github.io
bio: 句子互动创始人 & CEO，微软人工智能最具价值专家 (AI MVP)
avatar: /jekyll/assets/contributors/lijiarui/avatar.png
email<EMAIL_ADDRESS>twitter: https://weibo.com/u/2175505900
---

Here is the example file:

lijiarui.md: https://github.com/wechaty/wechaty.js.org/blob/master/jekyll/_contributors/lijiarui.md
It will shown like this on wechaty website: https://wechaty.js.org/contributors/lijiarui/

To learn more about the contribute guideline, visit: https://wechaty.js.org/docs/contributor-program/

 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.

Please make sure the following requirements have been met for your PR before we can continue reviewing it:

The PR has passed all the CI tests and turns green. (you can execute all tests locally by running npm test)

It seems that we still have the following issues:
jekyll/_contributors/smartnikocj.md:15:33 MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 1]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:81:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:81 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- 轮科医生排班与考勤"]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:82:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:83:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:84:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:85:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:86:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:87:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:88:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:94 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2]

It seems that we still have the following issues:
jekyll/_contributors/smartnikocj.md:15:33 MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 1]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:81:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:81 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- 轮科医生排班与考勤"]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:82:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:83:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:84:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:85:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:86:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:87:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:88:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:94 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2]

I'd like to suggest that you run the npm test locally to fix those problems more efficiently, esp., there will be more tests after the markdown linting.

Thanks, I try my best to run npm test locally.

It seems that we still have the following issues:
jekyll/_contributors/smartnikocj.md:15:33 MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 1]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:81:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:81 MD032/blanks-around-lists Lists should be surrounded by blank lines [Context: "- 轮科医生排班与考勤"]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:82:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:83:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:84:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:85:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:86:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:87:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:88:1 MD007/ul-indent Unordered list indentation [Expected: 0; Actual: 2]
jekyll/_posts/2022-02-02-wechaty-medical-bot.md:94 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2]

I'd like to suggest that you run the npm test locally to fix those problems more efficiently, esp., there will be more tests after the markdown linting.

Thanks, I try my best to run npm test locally.

HELP WANTED!
I run npm install and then npm test, errors were noticed.
Here is the log.
0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   'H:\\Software\\nodejs\\node.exe',
1 verbose cli   'H:\\Software\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli   'run',
1 verbose cli   'lint'
1 verbose cli ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'prelint', 'lint', 'postlint' ]
5 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>6 info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>7 verbose lifecycle<EMAIL_ADDRESS>unsafe-perm in lifecycle true
8 verbose lifecycle<EMAIL_ADDRESS>PATH: H:\Software\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;H:\Software\Python\Pycharm\wechaty.js.org\node_modules\.bin;H:\Software\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;H:\Software\Python\Pycharm\wechaty.js.org\node_modules\.bin;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Intel\OpenCL SDK\1.5\bin\x86;C:\Program Files (x86)\Intel\OpenCL SDK\1.5\bin\x64;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;H:\Software\Lenovo\Bluetooth Software\;H:\Software\Lenovo\Bluetooth Software\syswow64;H:\Software\Python\Python38\Scripts;H:\Software\phantomjs\bin;H:\Software\Python\Python38\;H:\Software\Git\cmd;H:\Software\nodejs\;H:\Software\7-Zip;H:\Software\PostgreSQL\12\bin;H:\Software\scrcpy-v1.17\adb.exe;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;H:\Software\Python\Python38\Scripts\;H:\Software\Python\Python38\;C:\Users\SMarT\AppData\Local\BypassRuntm;C:\Users\SMarT\AppData\Roaming\npm
9 verbose lifecycle<EMAIL_ADDRESS>CWD: H:\Software\Python\Pycharm\wechaty.js.org
10 silly lifecycle<EMAIL_ADDRESS>Args: [ '/d /s /c', 'npm-run-all lint:es lint:ts lint:md lint:fn lint:yml' ]
11 silly lifecycle<EMAIL_ADDRESS>Returned: code: 1  signal: null
12 info lifecycle<EMAIL_ADDRESS>Failed to exec lint script
13 verbose stack Error<EMAIL_ADDRESS>lint: `npm-run-all lint:es lint:ts lint:md lint:fn lint:yml`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (H:\Software\nodejs\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
13 verbose stack     at EventEmitter.emit (events.js:315:20)
13 verbose stack     at ChildProcess.<anonymous> (H:\Software\nodejs\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:315:20)
13 verbose stack     at maybeClose (internal/child_process.js:1021:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)
14 verbose pkgid<EMAIL_ADDRESS>15 verbose cwd H:\Software\Python\Pycharm\wechaty.js.org
16 verbose Windows_NT 6.1.7601
17 verbose argv "H:\\Software\\nodejs\\node.exe" "H:\\Software\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "lint"
18 verbose node v12.18.3
19 verbose npm  v6.14.6
20 error code ELIFECYCLE
21 error errno 1
22 error<EMAIL_ADDRESS>lint: `npm-run-all lint:es lint:ts lint:md lint:fn lint:yml`
22 error Exit status 1
23 error Failed at the<EMAIL_ADDRESS>lint script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

I google it, but still failed to fix the problem. And I think I can push and wait the CI help me to check whether there are errors. Howerer, get error again when I push my content. See below.
NotSupportedException encountered. ServicePointManager ��֧�־��� socks5 �����Ĵ��� npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR<EMAIL_ADDRESS>lint:es: `eslint "src/**/*.ts" "tests/**/*.spec.ts" --ignore-pattern tests/fixtures/` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the<EMAIL_ADDRESS>lint:es script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR!  C:\Users\SMarT\AppData\Roaming\npm-cache\_logs\2022-02-03T03_07_36_637Z-debug.log ERROR: "lint:es" exited with 1. npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR<EMAIL_ADDRESS>lint: `npm-run-all lint:es lint:ts lint:md lint:fn lint:yml` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the<EMAIL_ADDRESS>lint script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR!  C:\Users\SMarT\AppData\Roaming\npm-cache\_logs\2022-02-03T03_07_36_679Z-debug.log Failed to exec pre-push hook script failed to push some refs to 'https://github.com/smartnikocj/wechaty.js.org.git'

It seems that you are running into the following 2 issues:

Our testing script is not support windows now. You need either to run it under Linux/Mac, or just push it to your GitHub branch to let the GitHub Actions to run it for you (which is slower but workable)
Your internet connection seems is inside the china intranet. Use a VPS our side of China will probably solve your problem.

It seems that you are running into the following 2 issues:

Our testing script is not support windows now. You need either to run it under Linux/Mac, or just push it to your GitHub branch to let the GitHub Actions to run it for you (which is slower but workable)
Your internet connection seems is inside the china intranet. Use a VPS our side of China will probably solve your problem.

Thanks Huan.
That is what I am thinking now. I want to push it to my Github and let the Action help me to check error.
But, I still get error no matter I use VPS or not. The PUSH was ok before I run npm install yesterday.
NotSupportedException encountered. ServicePointManager ��֧�־��� socks5 �����Ĵ��� npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR<EMAIL_ADDRESS>lint:es: `eslint "src/**/*.ts" "tests/**/*.spec.ts" --ignore-pattern tests/fixtures/` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the<EMAIL_ADDRESS>lint:es script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR!  C:\Users\SMarT\AppData\Roaming\npm-cache\_logs\2022-02-03T03_46_58_664Z-debug.log ERROR: "lint:es" exited with 1. npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR<EMAIL_ADDRESS>lint: `npm-run-all lint:es lint:ts lint:md lint:fn lint:yml` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the<EMAIL_ADDRESS>lint script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR!  C:\Users\SMarT\AppData\Roaming\npm-cache\_logs\2022-02-03T03_46_58_708Z-debug.log Failed to exec pre-push hook script failed to push some refs to 'https://github.com/smartnikocj/wechaty.js.org.git'

try use
NO_HOOK=1 git push

Sad, I can not run this command in Pycharm.

try use
NO_HOOK=1 git push

fatal: NotSupportedException encountered.
ServicePointManager 不支持具有 socks5 方案的代理。

I think something went wrong after running npm install. It changes my proxy?

after trying everything, still get error:
Push failed Npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR<EMAIL_ADDRESS>lint:es: `eslint "src/**/*.ts" "tests/**/*.spec.ts" --ignore-pattern tests/fixtures/` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the<EMAIL_ADDRESS>lint:es script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR!  C:\Users\SMarT\AppData\Roaming\npm-cache\_logs\2022-02-03T06_04_30_331Z-debug.log ERROR: "lint:es" exited with 1. npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR<EMAIL_ADDRESS>lint: `npm-run-all lint:es lint:ts lint:md lint:fn lint:yml` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the<EMAIL_ADDRESS>lint script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR!  C:\Users\SMarT\AppData\Roaming\npm-cache\_logs\2022-02-03T06_04_30_374Z-debug.log Failed to exec pre-push hook script failed to push some refs to 'https://github.com/smartnikocj/wechaty.js.org.git'

Finally, I use git bash to push sucessfully.

I think I should wait the maintainer to approve my application because this is my first contribution. @huan , thanks.

Yeah, now GitHub requires approve manually Everytime for the PR to run the actions.

1..20
# failed 1 of 20 tests
# time=40[342](https://github.com/wechaty/wechaty.js.org/runs/5048634596?check_suite_focus=true#step:7:342).972ms
----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files |       0 |        0 |       0 |       0 |
----------|---------|----------|---------|---------|-------------------
ERROR: "test:unit" exited with 1.
Error: Process completed with exit code 1.

What should I do now? Sorry, I can not figure out which step is wrong.

See: https://github.com/wechaty/wechaty.js.org/runs/5048634596?check_suite_focus=true#step:7:125

    not ok 1 - "jekyll/assets/2022/02-wechaty-medical-bot/title-image.webp" (width: 2000, size: 76858) exceed the maximum limitation: width<=1920 size<=1048576

not ok 8 - tests/assets-image-type-size.spec.ts # time=4[126](https://github.com/wechaty/wechaty.js.org/runs/5048634596?check_suite_focus=true#step:7:126).741ms
  ---
  env: {}
  file: tests/assets-image-type-size.spec.ts
  timeout: 60000
  command: /opt/hostedtoolcache/node/16.13.2/x64/bin/node
  args:
    - tests/assets-image-type-size.spec.ts
  stdio:
    - 0
    - pipe
    - 2
  cwd: /home/runner/work/wechaty.js.org/wechaty.js.org
  exitCode: 1
  ...
{
    # Subtest: image size should be fit for the web (no more than 1MB and 1920x1080)
        not ok 1 - "jekyll/assets/2022/02-wechaty-medical-bot/title-image.webp" (width: 2000, size: 76858) exceed the maximum limitation: width<=1920 size<=1048576
          ---
          at:
            line: 74
            column: 9
            file: file:///home/runner/work/wechaty.js.org/wechaty.js.org/tests/assets-image-type-size.spec.ts
            type: Test
          stack: |
            Test.<anonymous> (file://tests/assets-image-type-size.spec.ts:74:9)
            runMicrotasks (<anonymous>)
          ...

        ok 2 - 1700 files checked
        1..2
        # failed 1 of 2 tests
    not ok 1 - image size should be fit for the web (no more than 1MB and 1920x1080) # time=3742.783ms

not ok 8 - tests/assets-image-type-size.spec.ts # time=4[126](https://github.com/wechaty/wechaty.js.org/runs/5048634596?check_suite_focus=true#step:7:126).741ms
  ---
  env: {}
  file: tests/assets-image-type-size.spec.ts
  timeout: 60000
  command: /opt/hostedtoolcache/node/16.13.2/x64/bin/node
  args:
    - tests/assets-image-type-size.spec.ts
  stdio:
    - 0
    - pipe
    - 2
  cwd: /home/runner/work/wechaty.js.org/wechaty.js.org
  exitCode: 1
  ...
{
    # Subtest: image size should be fit for the web (no more than 1MB and 1920x1080)
        not ok 1 - "jekyll/assets/2022/02-wechaty-medical-bot/title-image.webp" (width: 2000, size: 76858) exceed the maximum limitation: width<=1920 size<=1048576
          ---
          at:
            line: 74
            column: 9
            file: file:///home/runner/work/wechaty.js.org/wechaty.js.org/tests/assets-image-type-size.spec.ts
            type: Test
          stack: |
            Test.<anonymous> (file://tests/assets-image-type-size.spec.ts:74:9)
            runMicrotasks (<anonymous>)
          ...

        ok 2 - 1700 files checked
        1..2
        # failed 1 of 2 tests
    not ok 1 - image size should be fit for the web (no more than 1MB and 1920x1080) # time=3742.783ms

    # Subtest: we enforce all image type to .webp (#1035)
        ok 1 - all image files are .webp
        1..1
    ok 2 - we enforce all image type to .webp (#1035) # time=378.649ms

    1..2
    # failed 1 of 2 tests
    # time=4126.741ms
}

Get it! image size should be fit for the web (no more than 1MB and 1920x1080).

See: https://github.com/wechaty/wechaty.js.org/runs/5048634596?check_suite_focus=true#step:7:125

    not ok 1 - "jekyll/assets/2022/02-wechaty-medical-bot/title-image.webp" (width: 2000, size: 76858) exceed the maximum limitation: width<=1920 size<=1048576

not ok 8 - tests/assets-image-type-size.spec.ts # time=4[126](https://github.com/wechaty/wechaty.js.org/runs/5048634596?check_suite_focus=true#step:7:126).741ms
  ---
  env: {}
  file: tests/assets-image-type-size.spec.ts
  timeout: 60000
  command: /opt/hostedtoolcache/node/16.13.2/x64/bin/node
  args:
    - tests/assets-image-type-size.spec.ts
  stdio:
    - 0
    - pipe
    - 2
  cwd: /home/runner/work/wechaty.js.org/wechaty.js.org
  exitCode: 1
  ...
{
    # Subtest: image size should be fit for the web (no more than 1MB and 1920x1080)
        not ok 1 - "jekyll/assets/2022/02-wechaty-medical-bot/title-image.webp" (width: 2000, size: 76858) exceed the maximum limitation: width<=1920 size<=1048576
          ---
          at:
            line: 74
            column: 9
            file: file:///home/runner/work/wechaty.js.org/wechaty.js.org/tests/assets-image-type-size.spec.ts
            type: Test
          stack: |
            Test.<anonymous> (file://tests/assets-image-type-size.spec.ts:74:9)
            runMicrotasks (<anonymous>)
          ...

        ok 2 - 1700 files checked
        1..2
        # failed 1 of 2 tests
    not ok 1 - image size should be fit for the web (no more than 1MB and 1920x1080) # time=3742.783ms

I believe this PR will be OK to be merged after we fixed this size issue.

Get it! I have modified the size of the image.

Let's see!

Let's see!

Cool and excited! It turns GREEN!! My first PR, I believe I will contribute more!! @huan

Thank you very much for your contribution!
You are welcome to join Wechaty Contributor Program
1. Join Wechaty Organization

You've invited SMarT to Wechaty! They'll be receiving an email shortly. They can also visit https://github.com/wechaty to accept the invitation.

I have invited you to join our Wechaty GitHub Organization, please accept it by following the above message. (See also: wechaty/PMC#16)
2. Update Your Wechaty Contributor Profile

Please open Contributor Hall of Fame and add yourself to the end of the list, so that other contributors will know you better!
Please add yourself to our Website Contributors by creating a PR and refer to this PR link as well.

3. Join The Contributor Only WeChat Room
We also have a WeChat room for contributors only which can discuss Wechaty at a deeper level, you are welcome to join and if you are interested.
Please add @lijiarui wechat: ruirui_0914 and send her this pr link. She will invite you into Wechaty Contributor Room
Cheers!


Question: Using Native TypeScript Types vs. Zod/Prisma Types with Nestia Swagger Docs

Question
Hello, I'm currently working on a NestJS project that utilizes Prisma Client for ORM and Zod for data validation. I've been trying to integrate Nestia for Swagger documentation generation, but I'm facing challenges with Nestia's ability to detect and use types generated by Prisma Client and schemas inferred by Zod. I was wondering if there's a recommended approach or existing solution to integrate these effectively with Nestia's Swagger documentation generation.
Detailed Explanation
In my project, models are defined using Prisma Client and validated with Zod. However, the Swagger documentation generated by Nestia doesn't accurately reflect these types. When I switch to native TypeScript types defined manually, Nestia generates the documentation correctly.
I'm particularly interested in:

Any best practices or patterns that are recommended for ensuring that Nestia correctly interprets and integrates Prisma Client generated types and Zod inferred schemas in the Swagger documentation.
If there are known limitations or challenges with this integration, and any potential workarounds that might exist.
Any plans for future updates or enhancements in Nestia that will improve this integration.

Context

Nestia version: [v5.1.2]
Prisma version: [v5.8.0]
Prisma Client: [v5.8.0]
Zod version: [v3.22.4]
@nestia/core: [v2.4.4]
Node.js version: [v20.11.0]

This issue is significant for our project, as we rely on Prisma Client for ORM and Zod for validation. While native TypeScript types are a workaround, they don't offer the same level of convenience and functionality as the generated types from Prisma and Zod. We're seeking a more streamlined approach that allows for seamless integration.
Additional Information
Any insights, advice, or resources on this matter would be greatly appreciated. If more information or specific examples from our codebase are needed to better understand the issue, I'd be happy to provide them.
Thank you for your time and support in addressing this query.

As you know, the 1st principle of typia and nestia is not to writing any extra schema like intro page.
It's not a matter to find the best way by yourself, but I don't want to do it, prohibiting the 1st principle \o/.
By the way, if you want to utilize the original type of Prisma, then just use it directly. It is the pure TypeScript type. Also, even when using the zod schema, you can still utilize it through Infer feature of the zod, because it is also the pure TypeScript type. Furthermore, if you turn on the clone mode of SDK generator, you can clone pure interface DTO types from them.
https://nestia.io/docs/sdk/sdk/#configuration

Specific Issue with Nestia Swagger Documentation and Prisma/Zod Types
I am working on a NestJS project using Nestia for Swagger documentation generation, Prisma for ORM, and Zod for data validation. I've run into a problem where Nestia fails to recognize and use types when they are either generated by Prisma or inferred from Zod schemas for the Swagger documentation. However, it works correctly when I define the types manually in TypeScript.
Working Scenario (Manual TypeScript Types)
When I define a type manually in TypeScript, Nestia successfully generates the Swagger documentation:
export type User = {
  id: number;
  email: string;
  password: string;
  name: string | null;
  createdAt: Date;
  updatedAt: Date;
};

@TypedRoute.Post()
create(@TypedBody() createUserDto: Prisma.UserCreateInput): Promise<User> {
  return this.userService.create(createUserDto);
}

Non-Working Scenario (Zod Inferred Types)
When using Zod to define a schema and then inferring the TypeScript type from it, Nestia fails to generate the Swagger documentation:
import * as z from 'zod';

export const userSchema = z.object({
  id: z.number(),
  email: z.string(),
  password: z.string(),
  name: z.string().nullable(),
  createdAt: z.date(),
  updatedAt: z.date(),
});

export type User = z.infer<typeof userSchema>;

@TypedRoute.Post()
create(@TypedBody() createUserDto: Prisma.UserCreateInput): Promise<User> {
  return this.userService.create(createUserDto);
}

Non-Working Scenario (Prisma Generated Types)
Similarly, when using types generated by Prisma, Nestia also fails to generate the Swagger documentation:
import { Prisma, User } from '@prisma/client';

// Example Prisma-generated User Model:
export type User = $Result.DefaultSelection<Prisma.$UserPayload>
// ...other properties...

@TypedRoute.Post()
create(@TypedBody() createUserDto: Prisma.UserCreateInput): Promise<User> {
  return this.userService.create(createUserDto);
}

Steps to Reproduce

Set Up NestJS with Nestia, Prisma, and Zod: Create a NestJS project, integrating Nestia for Swagger documentation, Prisma for ORM, and Zod for validation.

**Define Models and Validation**: Define data models using Prisma and validation schemas using Zod. Infer TypeScript types from Zod schemas.

Implement Controllers with Different Type Definitions: Implement the controllers using:
- Manually defined TypeScript types.
- Types inferred from Zod schemas.
- Types generated by Prisma.

Generate Swagger Documentation: Run the Nestia Swagger generation command.

Observe the Difference in Behavior: Note that Nestia successfully generates documentation for manually defined types but fails for types from Zod or Prisma.

Make me a reproducible repo, then I will test.

I can give you a repo now which i am working on to learn nestia:
https://github.com/Lotfi-Arif/TradeTrove

It is just a trick, change like below, then it works.
As type X = Y statement means an alias type definition, your type User = z.infer<typeof userSchema> statement means that always copying and pasting the z.infer<typeof userSchema> type statement everywhere the type User being utilized. If you change it to a new interface statement, the problem being solved.

The z.infer is also an alias type of implicit type of TMP. So it is blocked.
The reason why blocking the implicit type is for the SDK purpose (client developer needs explicit type definition)

export interface User extends z.infer<typeof userSchema> {}

Oh i am guessing it is the same case for prisma generated types.
I think i understand the solution, Thanks for the help!


OSD time in version 0.3.0 is wrong

My Timezone: CET-1CEST,M3.5.0,M10.5.0/3
OSD time in the upper left corner shows one hour too much while snapshot time and local time on the mainpage are displayed correctly.

In version 0.2.9 it was still correct.

Maybe it has something to do with the winter time change

do you set timezone correctly in home page?

do you set timezone correctly in home page?

And what's your model?

Sorry for late response. I was traveling. I have two identical cameras y21ga with identical settings (CET-1CEST,M3.5.0,M10.5.0/3). The only difference is that one of them still runs on 0.2.9 and the other on 0.3.0. And the one with version 0.3.0 shows the wrong OSD time although the snapshot time and the local time under System are displayed correctly.

I tried to check the difference between 0.2.9 and 0.3.0:
https://github.com/roleoroleo/yi-hack-Allwinner-v2/compare/0.2.9...0.3.0
There are no changes about osd.
Could you check how is configured the time inside the app?

Hi,
I can confirm this issue. Just unpacked a Yi 1080p Home QFUS (with original FW 9.0.35) and installed the latest hack (0.3.0). Then I configured the timezone to CET-1CEST,M3.5.0,M10.5.0/3. The time on the status page of the web interface is correct (Sat Jan 6 18:06:31 CET 2024), but time on the OSD display in the stream says 01/06/2024 09:06:31, so 9 hours before. Tried rebooting two times, but the OSD is still wrong.

Edit2: It is now working. No idea what finally made it work. But I just deleted all files from the SD card, and then changed all settings at once and saved them once. Then used the "Reboot Camera" button on the Maintenance page instead of unplugging the cable. Maybe the hard power off I did before resulted in some inconsistencies...

Strange.

This is funny. I just reactivated the cloud functionality to check in the Yi app whether there are any time settings there. I didn't find any. However, I noticed that the time is now displayed correctly. After deactivating the cloud, it was displayed incorrectly again. I tested this twice. If the cloud is activated, the time is correct - otherwise not.

Please, I need some other info.

What's the time in the main page of the web gui? (label "Local Time").
What's the value of the addresses 0x4e0 - 0x4e8 of the file /tmp/mmap.info (check with hexdump -C /tmp/mmap.info)

I don't understand why, but the time now works correctly even without the cloud connection. Here is the requested information.

Local Time on the web gui was allways correct.
hexdump:
...
000004d0  00 00 00 00 00 00 00 00  00 00 00 00 01 00 00 00  |................|
000004e0  10 0e 00 00 10 0e 00 00  00 00 00 00 00 00 00 00  |................|
000004f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
...

Thank you very much for your effort and your great project.

The dump is ok.
10 0e 00 00 means 3600 seconds vs GMT.
Let me know if you understand the reason why the problem appears and disappears.

After restarting the camera, OSD time is again 1h in the future.

Here is the hexdump
...
000004d0  00 00 00 00 00 00 00 00  00 00 00 00 01 00 00 00  |................|
000004e0  20 1c 00 00 10 0e 00 00  00 00 00 00 00 00 00 00  | ...............|
000004f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
...
Unfortunately, I understand C very rudimentarily. But I noticed a difference between 0.2.9 and 0.3.0 which may have something to do with the problem.
In src/set_tz_offset/set_tz_offset/set_tz_offset.c

I'm not sure if Y21GA_12 ist the right version.
Because it only affects OSD time, it may also have something to do with the -m and -f options described in the file.

Y21GA_12 is user for y21ga with firmware 12.
If I'm not wrong your fw is 9.0.19.
Check the value of mmap.info when the time is wrong.
Another question: are you using a NTP server?

Sorry to interfere, but some time ago I also noticed a time zone problem, but differently. I moved on because it wasn't important, but I noticed that the videos were recorded poorly (especially at night). I also opened a discussion, which roleo said was about the time zone "https://github.com/roleoroleo/yi-hack-Allwinner-v2/discussions/368"
furthermore, the files are recorded with an E01 (my time zone I think) before the actual file name, this problem has been reported in multiple topics. Example: E0122M00S.mp4 instead of 22M00S.mp4.
@BazzeDe  do you notice something similar in the night recordings too?

@roleoroleo the nmap dump in my post was with wrong time.

i use the standard NTP server

@Giuserver I didn't notice anything like that.

Ok, maybe a race condition occurs.
Try to set the time manually and check:

if the time changes properly
if the solution is persistent over time

The command is set_tz_offset -c tz_offset_osd -v 3600 -m y21ga -f 9

The time is correct after executing the command. After a restart, it runs incorrectly again.
At the moment it is running correctly and I will check whether this lasts longer.
What I find strange is that sometimes different times in OSD-Time and Watermark-Time are displayed when I open the snapshot with watermark=yes. Apart from that they have different formats.
OSD:       2024/01/12 18: 23: 54
Watermark: 2024-01-12 18:23:56

See screenshot:

What I find strange is that sometimes different times in OSD-Time and Watermark-Time are displayed when I open the snapshot with watermark=yes. Apart from that they have different formats.

Yes, it's possible.
The upper left comes from a Yi process and it's in real time.
The lower right is added after a sequence of programs and elaborations.

@BazzeDe
Is cloud enabled or disabled?

The time is still displayed correctly. Cloud is deactivated.
As long as i don't restart the camera it works with your command.

Tomorrow, I will send you a new script to test.

That looks good. Time is running right with the new cloudAPI_fake.

Added to the latest version released yesterday.

I've installed the new release 0.3.1 on my cams. It's working fine. Thank you 😊

With 0.3.1 (Y623) I wasn't able to disable time / OSD at all.
The time isn't supposed to be displayed after disabling the toggle button "Enable/disable time OSD", right?

It depends on the cam.
If the cam shows the osd natively, it cannot be disabled.
If the cam doesn't show the osd natively, you can enable and disable it.


How to express if something is planned

The application profile has a mechanism to express that something is planned
However, there is a comment from Rob (@rwwh) who points out that: "if a trivial update is performed by a tool, and the modification date is changed, this can put it beyond the planned date for some action. Unless planned actions are indicated in an explicit way, this can be a problem! Every tool must now check that they don't inadvertently move the dmp modification date past any other date in the DMP!"
If we change our philosophy to make things more explicit then we likely need to come up with a controlled vocabulary such as <todo, doing, done, ??> to describe states. Then we need to introduce additional field to the dataset (where else?).
The reason we did not do that in the first place:

we were concerned that terms from a controlled vocabulary can be interpreted differently depending on the specific viewpoint, e.g. "done" can be understood by researcher as submitted to the funder, but for the funder it doesn't mean the action was approved
we implemented the "dates arithmetic" for expressing embargoes in the same way as it was done for RIOXX - another application profile. Hence, it seemed a good idea to "talk about the future" in the same way.

In my opinion, the suggestion made by @rwwh does not break the application profile, but shifts the responsibilities and is a change request that we may want to discuss and potentially address in later releases (maintenance). To my best knowledge, the existing (and pending) adoptions of the standard do not use the mechanism for expressing something is planed (did not get that far), so any changes in the specification should not break existing implementations.

I am afraid I don't understand the use case described above: I don't see the problem with how the chronology is implemented in express that something is planned...
What am I missing?

I am afraid I don't understand the use case described above: I don't see the problem with how the chronology is implemented in express that something is planned...
What am I missing?

We indicate that something is planned by having a date that is later than the release-date of the document. A change somewhere else changes the release date of the document, causing it to jump over the "planned by" date, changing its semantics to "this happened on that date"; however there is no guarantee that it actually took place.

We indicate that something is planned by having a date that is later than the release-date of the document. A change somewhere else changes the release date of the document, causing it to jump over the "planned by" date, changing its semantics to "this happened on that date"; however there is no guarantee that it actually took place.

Thanks @rwwh. So I suppose we do not want to rely on external (or internal?) checks to ensure that this situation does not happen ?
Other than that, I have little insight into this issue... For now at least.

Thanks @rwwh. So I suppose we do not want to rely on external (or internal?) checks to ensure that this situation does not happen ?
Other than that, I have little insight into this issue... For now at least.

I think the only sensible way to handle this is by using explicit semantics for any relevant dates.
I found: https://www.w3.org/TR/owl-time/ for semantically defining relations between time intervals, and http://semanticscience.org/resource/SIO_000033 "process status"

I think the only sensible way to handle this is by using explicit semantics for any relevant dates.
I found: https://www.w3.org/TR/owl-time/ for semantically defining relations between time intervals, and http://semanticscience.org/resource/SIO_000033 "process status"

Hello.... yes, I agree: I had second thoughts, and now I understand why doing it this way will keep the CS self-contained and self-descriptive.

Hello.... yes, I agree: I had second thoughts, and now I understand why doing it this way will keep the CS self-contained and self-descriptive.

I agree with:

I think the only sensible way to handle this is by using explicit semantics for any relevant dates.

Using the updated date of the DMP to mean anything other than "last time this DMP was updated" would be mistake.


Update s3, sdk-core, sqs to 2.20.74

About this PR
📦 Updates

software.amazon.awssdk:s3
software.amazon.awssdk:sdk-core
software.amazon.awssdk:sqs

from 2.17.295 to 2.20.74
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "software.amazon.awssdk" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #611.


python3Packages.jupyterlab_server: fix build on darwin

Description of changes
Disable failing test of dependency jupyter_server on darwin, and mark the package as unbroken.
Closes #176525.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[X] x86_64-darwin
[ ] aarch64-darwin

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

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

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

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

[X] Fits CONTRIBUTING.md.

Why doesn't ofborg build the package?

@ofborg build python310Packages.jupyterlab_server

Ofborg would only have built it if you specified python310Packages in the commit message, I think

@ofborg build python310Packages.jupyterlab_server

I think this should be backported, right? Or Darwin users on 22.05 will be left without Jupyter.
Maybe together with #181547 and #181493.

that would probably also require to backport multiple pyopenssl related changes which is a bit much for my liking.


PDFPage.get_pages is inefficient for extracting a subset of pages

See https://github.com/ocrmypdf/OCRmyPDF/issues/1378
The issue is that, while we do need to walk the page tree (maybe) in order to get to a particular page by its index, we shouldn't be actually parsing all the pages if not specifically requested.

Ah. Turns out that instantiating PDFPage is not really expensive at all.  This is more of an API problem, people should not use get_pages in this way if they are going to call it repeatedly.  I will close this, not really an issue.


Symbolic execution fix

Reviewer checklist

[ ] Test coverage: stack test --coverage
[ ] Public API documentation: stack haddock
[ ] Style conformance: stylish-haskell

@virgil-serbanuta I did a few changes. First off, I realised that isSubsortOf is reflexive while subsorts did not include the requested sort in the resulting set, so I changed it to do so. This does not change the algorithm because the set intersection used in AndTerms still applies identically.
I added tests for both areas you mentioned -- see the replies to your review for exact links. Please let me know if you would rather i rebase before you re-check this. I think rebasing mid-review makes it harder to do subsequent reviews so I will not do it unless you specifically request it. The downside is, Jenkins will not run.


travis: add build check

Add automated build check for main repository. Pull requests should at least pass this test-suite.

close/reopen to trigger Travis

thx!

I decided to extend the setup-ock script. If that works, I'll remove most of the setup stuff from the travis file.

Jammy seems too outdated for testing this project. I'll close the the PR for now.