[SmsRetrieverHelper] SMS verification code request failed: unknown status code: 18002 Invalid PlayIntegrity token; app not Recognized by Play Store.

I am getting an error while fetching the sms code from the verification completed callback. I am getting an SMS on the physical device, but it fails to get set in the text field.
Error:
"E/FirebaseAuth(32222): [SmsRetrieverHelper] SMS verification code request failed: unknown status code: 18002 Invalid PlayIntegrity token; app not Recognized by Play Store."

In the screenshot, there's my authentication service class, which I've created, in that the code sent callback is working as expected, but the verification completed callback is never getting called.
Line no. 22 is never getting called.
Flutter Version:
Flutter (Channel stable, 3.7.0, on macOS 13.3 22E252 darwin-arm64, locale en-IN)
Plugin Version:
firebase_app_check: ^0.1.2
firebase_auth: ^4.4.0
firebase_core: ^2.9.0
Important:
I've set up Firebase "Phone Authentication" in Firebase Console & App
I've set up Firebase "App Check" in Firebase Console & App
I've set up SHA Keys (Debug & Release) in Firebase Console

@dharambudh1 this sound like a firebase issue rather than flutter's
maybe the issue should be opened here

@iapicca, I am confused as well. I am not sure about it.
Either it's a Flutter framework issue or a Firebase plugin issue.

@iapicca, I am confused as well. I am not sure about it.
Either it's a Flutter framework issue or a Firebase plugin issue.

@iapicca, I am confused as well.

@dharambudh1
I'm not confused, it's definitely a Firebase plugin issue

Okay @iapicca, I'm closing this issue from here.


Improve Connection::isCollationSupportedForKeys()

It has been reported that the function returns TRUE even if the DB
doesn't actually support keys in the specified length.
This change may hopefully fix this issue.

bump

As far as I can tell, this is still awaiting review.

As far as I can tell, this is still awaiting review.

I'm not really sure how to test this.

I'm not really sure how to test this.

When we install c5 we check if the DB supports utf8mb4.
We do that by creating a table: if we fail, utf8mb4 is not supported.
This PR improves this procedure by also adding a new record to that table.
So, to test this PR you simply have to install c5

I figure it has to be a bit more complicated than that...since concrete5 installs fine for me, doest that mean we don't need this pull request?

The issue was that for a user the function succeeded even if his mysql didn't support utf8mb4. We should try to replicate his system in order to see if with this PR the function fails (as it should)

Bump


feat: [WIP] Mode dashboard preview ACL

Summary of Changes
Include a summary of changes then remove this line
Tests
What tests did you add or modify and why? If no tests were added or modified, explain why. Remove this line
Documentation
What documentation did you add or modify and why? Add any relevant links then remove this line
CheckList
Make sure you have checked all steps below to ensure a timely review.

[ ] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[ ] PR includes a summary of changes, including screenshots of any UI changes.
[ ] PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public python functions and the classes in the PR contain docstrings that explain what it does

[ ] PR passes all tests documented in the developer guide

Codecov Report

Merging #481 into master will increase coverage by 2.73%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #481      +/-   ##
==========================================
+ Coverage   80.88%   83.61%   +2.73%
==========================================
  Files         223      181      -42
  Lines        5487     3735    -1752
  Branches      637      476     -161
==========================================
- Hits         4438     3123    -1315
+ Misses        989      597     -392
+ Partials       60       15      -45

Impacted Files
Coverage Δ

...on/proxy/issue_tracker_clients/issue_exceptions.py

amundsen_application/log/action_log.py

amundsen_application/api/announcements/v0.py

amundsen_application/models/user.py

...pplication/proxy/issue_tracker_clients/__init__.py

amundsen_application/models/preview_data.py

amundsen_application/oidc_config.py

amundsen_application/log/action_log_callback.py

...n_application/base/base_superset_preview_client.py

amundsen_application/base/base_preview.py

... and 29 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9fb996b...d76924d. Read the comment docs.


Add CircleCI support with CMake

@Idclip - this adds Circle CI support to your CMake changes, I thought I'd open this as a PR into your fork rather than add these changes directly because there's quite a lot of them.
This supports building standalone ABI=6, ABI=5, ABI=4 as well as Houdini 17.5, 17.0, 16.5. It builds all of it's dependencies from scratch right now to try and best match the VFX Reference Platform, however there are a few remaining things to resolve:

CMake 3.10.1 was the first release to support Boost 1.66 using FindBoost, so I think I need to update the version of CMake used in order to support the Boost version required in VFX Reference Platform 2019. I believe it picks up the default which is 3.7.3. Perhaps it's worth also using the earliest version of CMake as well for the other years, just to make sure that we're fully compatible.
OpenEXR only introduced CMake support in 2.3.0 and I haven't got around to adding support to build it prior to that, so can't fully support VFX 2018/2017 yet.
Houdini 17.5 ships with Imath/OpenEXR namespaced such as libImath_sidefx.so which I don't believe the CMake FindIlmBase modules can handle yet - I'm also not sure about the best way of supporting this?
Docker images - I'd like to publish Docker images for VFX 2019/2018/2017 that has pre-installed all the non-VFX dependencies (Boost, TBB, etc), then re-use them here. It may even be possible to build out a latest top-of-tree build using Docker too.
OpenEXR currently builds the whole library which includes some slow portions (the DWA compressor in particular). I'd like to push a change to OpenEXR to be able to optionally disable this when building as we don't support writing EXRs with this compression scheme in OpenVDB.

Also, I'd like to add a test job that builds everything at the latest top-of-tree. Ideally this is something we could run once a week or once a day or so to verify that any changes coming down the pipe don't cause issues for us.

This looks good Dan, thanks! A few things in reply to your comments:

Houdini 17.5 ships with Imath/OpenEXR namespaced such as libImath_sidefx.so which I don't believe the CMake FindIlmBase modules can handle yet - I'm also not sure about the best way of supporting this?

This is the same situation as boost no? We don't want to/can't use the namespaced packages so our own version of ilmbase/openexr now has to be provided. This is configured in  OpenVDBHoudiniSetup which only points ilmbase/openexr location to the houdini directory if HV < 17.0

OpenEXR only introduced CMake support in 2.3.0 ... VFX 2018/2017 yet.
Also need C++14 support in the cmake for this - and 2.3.0 is only for VFX 19 no?

Ah yes, you're right about boost. I thought for some reason SideFX were only shipping the boost libraries, but I realize the headers are included, just under "hboost" now. I missed that.
Why can't we use the namespaced packages? We wouldn't want to in a big studio, we'd want to build these libraries ourselves, but I don't see a reason why we should require someone to download boost and openexr if they already have it in Houdini. I'm not quite sure what the logic should be - pick up the non-namespaced ones as preference and then fall back to the Houdini ones if they're not available?
As for OpenEXR 2.3.0, yeah I'm using this for all reference platforms versions right now, because CMake isn't available for 2.2.0, but I'll have to get both working.
You're right about C++14, that's missing too.

Why can't we use the namespaced packages?

AFAIK because they all use Houdini namespacing - i.e. you cant just use hboost, you'd have to replace every instance of boost::method with hboost::method. The same goes for openexr. Example: https://www.sidefx.com/docs/hdk/_h_d_k__changes_16_5.html We'd have to add macros in OpenVDB to allow you to switch the namespace being used, so currently it's impossible to use sesis libs.

Why can't we use the namespaced packages?

AFAIK because they all use Houdini namespacing - i.e. you cant just use hboost, you'd have to replace every instance of boost::method with hboost::method. The same goes for openexr. Example: https://www.sidefx.com/docs/hdk/_h_d_k__changes_16_5.html We'd have to add macros in OpenVDB to allow you to switch the namespace being used, so currently it's impossible to use sesis libs.

Right, so for Boost, that's the case, the houdini library and SOPs have includes like this:
#if UT_VERSION_INT >= 0x10050000 // 16.5.0 or later
#include <hboost/algorithm/string/case_conv.hpp>
#include <hboost/algorithm/string/trim.hpp>
#else
#include <boost/algorithm/string/case_conv.hpp>
#include <boost/algorithm/string/trim.hpp>
#endif

However, the core library always uses <boost/... so you'd have to build your own (or make all the changes listed in that H16.5 doc).
I don't think that's the case for IlmBase/OpenEXR though as the header directory isn't called something like "hOpenEXR" so we should still be able to build against the version shipped with Houdini, it would just require picking up a library that is suffixed _sidefx.so (from H17.5+) which the CMake currently doesn't handle?

Nah it's not just the directory naming, they've namespaced the headers and symbols too. I have this comment in the cmake when building the vdb deps:
# Set core deps. Note that the order here is important. If we're building against
# Houdini 17.5 we must include OpenEXR and IlmBase deps first to ensure the normal
# namespaced headers are used over the Houdini 17.5 ones (which will be imported
# through targets like tbb which are still deployed with Houdini)

If you look at toolkit/include/OpenEXR/IlmBaseConfig.h and OpenEXRConfig.h:
...
#define IMATH_INTERNAL_NAMESPACE Imath_2_2_sidefx
#define IEX_INTERNAL_NAMESPACE Iex_2_2_sidefx
#define ILMTHREAD_INTERNAL_NAMESPACE IlmThread_2_2_sidefx
...

and
...
#define OPENEXR_IMF_INTERNAL_NAMESPACE Imf_2_2_sidefx
...

It's actually a bit annoying they haven't moved the headers out of include/OpenEXR because of this as it enforces the include order

Nah it's not just the directory naming, they've namespaced the headers and symbols too.

Actually, the headers haven't been namespaced from what I can tell and although the symbols have been namespaced, they're still available without the "internal" name too. See this comment in ImathNamespace.h for example:
// To ensure source code compatibility, the IMATH_NAMESPACE defaults to Imath
// and then "using namespace IMATH_INTERNAL_NAMESPACE;" brings all of the
// declarations from the IMATH_INTERNAL_NAMESPACE into the IMATH_NAMESPACE.
// This means that client code can continue to use syntax like Imath::V3f,
// but at link time it will resolve to a mangled symbol based on the
// IMATH_INTERNAL_NAMESPACE.

So we can completely ignore the internal namespace and the only change needed is to be able to link against libImath_sidefx.so (from H17.5 onwards) rather than libImath.so.

I tried to build against this a while back and it didn't immediately work out the box so I ignored it in favour of users providing their own for the current cmake change set. Have tried to build with these/got it working? I suggest this doesn't go into this batch of cmake changes if it involves any core vdb changes which aren't built system related

I tried to build against this a while back and it didn't immediately work out the box so I ignored it in favour of users providing their own for the current cmake change set. Have tried to build with these/got it working? I suggest this doesn't go into this batch of cmake changes if it involves any core vdb changes which aren't built system related. The linking issue shouldn't be too difficult to fix if we don't use openexrs cmake, we can just add custom changed to our own Find modules

Yeah, I think that's the change that's needed. I had a quick go at extending this:
      LIST ( APPEND CMAKE_FIND_LIBRARY_SUFFIXES
        "-${OpenEXR_VERSION_MAJOR}_${OpenEXR_VERSION_MINOR}.so"
        )

but it didn't work and I'm not sure this is quite the right mechanism to use anyway. I suspect that multiple calls to FIND_LIBRARY() with different library names would be better. Ultimately, we just need to decide the precedence for library names and search paths, which I suggest for standalone builds should be:

libImath.so
libImath_2_3.so

And for Houdini 17.5 builds should be:

libImath.so
libImath_2_3.so
libImath_sidefx.so

Basically, what I'm saying is that I think there also needs to be a fallback library suffix hint (ie "_sidefx") set by OpenVDBHoudiniSetup.cmake for H17.5.
There's the related problem that I think you can end up with headers being pulled from user/system locations and libraries from Houdini locations or vice versa depending on version suffix or not (I can't remember which way round this gets processed). Perhaps a better logic could be to look for the header first, then use whereever that's found to derive the search paths for the library?
If you have ilmbase/openexr installed as user/system headers and through Houdini, I'm not sure which should take precedence to be honest. Perhaps the former?

Okay I think we're talking about two slightly different things. There two issues with ilmbase/openexr:

The version suffixed builds which error as they can't find the correct lib name. This should already be fixed in the came improvements branch, let me know if it doesn't work. The Find modules should support this lib naming.

The Houdini 17.5 build which, afaik, has two problems. The first is at compile time where I was getting namespace errors due to mismatching headers.

So we can completely ignore the internal namespace and the only change needed is to be able to link against libImath_sidefx.so (from H17.5 onwards) rather than libImath.so.

When I originally tried this a while it wouldn't build due to the different namespaces, not because of issues with finding libImath_sidefx (though that's also a problem).
The second issue is during linking where the lib _sidefx can't be found. I propose this can be fixed by just adding _sidefx to CMAKE_FIND_LIBRARY_SUFFIXES outside the Find modules and update the IlmBase/OpenEXR ones to append to CMAKE_FIND_LIBRARY_SUFFIXES rather than overwrite or add it internally.

There's the related problem that I think you can end up with headers being pulled from user/system locations and libraries from Houdini locations or vice versa depending on version suffix or not (I can't remember which way round this gets processed).

Here's the ilmbase ordered priority search paths:
  ${ILMBASE_LIBRARYDIR}
  ${_ILMBASE_ROOT_SEARCH_DIR}
  ${PC_IlmBase_LIBDIR}
  ${SYSTEM_LIBRARY_PATHS}

The only way this module will ever pick up a custom lib such as houdini's is by manually specifying ILMBASE_LIBRARYDIR or a ILMBASE_ROOT (_ROOT won't work for houdini). This is what OpenVDBHoudiniSetup does and it does it in such a way that it should be impossible for the includes and libs to pick up different locations as you suggest unless you're providing your own values for these (see below).

If you have ilmbase/openexr installed as user/system headers and through Houdini, I'm not sure which should take precedence to be honest. Perhaps the former?

The Houdini libs are never used unless you explicitly tell the cmake to with either OPENVDB_BUILD_HOUDINI_SOPS (fyi I'm going to deprecate this in favour of OPENVDB_BUILD_HOUDINI_PLUGIN but retain it for backwards compatibility). or USE_HOUDINI. In both cases the cmake uses OpenVDBHoudiniSetup to switch to a purely houdini dep build for its included libs EXCEPT for boost (H>=16.5), ilmbase and openexr (H>=17.5). The cmake is flexible enough that every module exposes _LIBRARYDIR and _INCLUDEDIR variables so not only could you build against system libs and choose to use tbb from houdini, but you can point to headers/libs installed in custom locations (basically not /include /lib).

The version suffixed builds which error as they can't find the correct lib name. This should already be fixed in the came improvements branch, let me know if it doesn't work. The Find modules should support this lib naming.

I've just tried this again and it now seems to build... I need to run some more tests to verify this

That all makes sense. Yes you're right that in a Houdini build, Houdini libs should always take precedence unless you explicitly provide your own root / librarydir variables. So if you have Houdini and your own IlmBase/OpenEXR installed, it'll always pick up the Houdini one.

In both cases the cmake uses OpenVDBHoudiniSetup to switch to a purely houdini dep build for its included libs EXCEPT for boost (H>=16.5), ilmbase and openexr (H>=17.5).

So that's the only quibble I have - the only exception should be Boost. IlmBase and OpenEXR for all versions of Houdini should always use the Houdini deps (just to be sure we're on the same page here).

The second issue is during linking where the lib _sidefx can't be found. I propose this can be fixed by just adding _sidefx to CMAKE_FIND_LIBRARY_SUFFIXES outside the Find modules and updating the IlmBase/OpenEXR ones to append to CMAKE_FIND_LIBRARY_SUFFIXES rather than overwrite or add it internally.

That sounds like a good solution to this problem.
As a somewhat unrelated note, the suffix used for OpenVDB is "_sesi" but for all other libraries, it's "_sidefx". I'm not sure if there's any reason to be able to build just the OpenVDB Houdini library or SOPs against the OpenVDB library Houdini ships with, but I think we should either explicitly support this or explicitly disable this (if that's not the case already). I think it's a common misconception that this is how you need to build the OpenVDB SOPs currently, so even with this clearly documented, we should still make the CMake error if we are not supporting this workflow to avoid confusion.

So that's the only quibble I have - the only exception should be Boost. IlmBase and OpenEXR for all versions of Houdini should always use the Houdini deps (just to be sure we're on the same page here).

Yep I agree, I thought that we were actually unable to use the exr namespaced libs in 17.5 but I'm currently unable to reproduce the issue I originally had so this seems fine - in which case I'll remove the 17.5 branching logic in OpenVDBHoudiniSetup such that it always points to the houdini deps if they haven't been specified.

As a somewhat unrelated note, the suffix used for OpenVDB is "_sesi" but for all other libraries, it's "_sidefx". I'm not sure if there's any reason to be able to build just the OpenVDB Houdini library or SOPs against the OpenVDB library Houdini ships with, but I think we should either explicitly support this or explicitly disable this (if that's not the case already)

Hmmmm I mean technically you should be able to do something like:
OPENVDB_INCLUDEDIR=$HT/include
OPENVDB_LIBRARYDIR=$HDSO
LIST ( APPEND CMAKE_FIND_LIBRARY_SUFFIXES "_sesi.so"  )
FIND_PACKAGE ( OPENVDB REQUIRED )

And it should find it. I'll try and find some time to verify this. If it works, we could introduce an option for it but its getting a bit confusing, i.e. build_core=OFF, build_houdini=ON, use_houdini_vdb=??

Hmmmm I mean technically you should be able to do something like:
OPENVDB_INCLUDEDIR=$HT/include
OPENVDB_LIBRARYDIR=$HDSO
LIST ( APPEND CMAKE_FIND_LIBRARY_SUFFIXES "_sesi.so"  )
FIND_PACKAGE ( OPENVDB REQUIRED )

And it should find it. I'll try and find some time to verify this. If it works, we could introduce an option for it but its getting a bit confusing, i.e. build_core=OFF, build_houdini=ON, use_houdini_vdb=??

I'm leaning towards explicitly not allowing it. If you check out the OpenVDB codebase at the exact same version as Houdini is using and just build the OpenVDB SOPs (plus any extra ones you might have written), sure you'll have no issues. However, as soon as there's a deviation in API because you build from a slightly different version than Houdini is shipping with, it's going to cause all kinds of issues that might be confusing to debug. I think we should explicitly disallow it and if you attempt to work around it by adding a libopenvdb.so symlink to libopenvdb_sesi.so (as an example of a hack an uninformed user might try), it should still catch this and explain why it's not recommended practice, forcing you to actually modify the CMake to switch off this check if you really want to do this.

I just tested out your changes on the cmake_improvements branch and running into an issue where the function to retrieve the houdini default install directory doesn't exist in H16.5 or earlier:
CMake Error at openvdb_houdini/CMakeLists.txt:99 (houdini_get_default_install_dir):
  Unknown CMake command "houdini_get_default_install_dir".

I just tested out your changes on the cmake_improvements branch and running into an issue where the function to retrieve the houdini default install directory doesn't exist in H16.5 or earlier:

Thanks for catching this, I've fixed this on the cmake_stage branch along with a final few improvements. Performing a last few checks and will update the cmake_improvements branch with those. Last on my list is to see how much I can improve the docs by

I just checked your changes and it works fine now thanks.
One suggestion - I'd rather we leave Blosc enabled by default. Even though it's an optional dependency, OpenVDB relies so heavily on it, I think it could be confusing that you have to explicitly switch it on when building the core library as standalone.
I have added debug and GCC builds to Circle now, so it's almost matching Travis perfectly. The only thing it's missing is the ability to do header checks which I don't believe is supported in CMake? This is where you generate a .cpp for every header file which just #includes that one header and verify that it can be compiled.
I tried standing up an AppVeyor Windows build, but am running into this error:
CMake Warning (dev) at cmake/FindIlmBase.cmake:121 (IF):
  Policy CMP0057 is not set: Support new IN_LIST if() operator.  Run "cmake
  --help-policy CMP0057" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.
  IN_LIST will be interpreted as an operator when the policy is set to NEW.
  Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
  C:/Tools/vcpkg/scripts/buildsystems/vcpkg.cmake:247 (_find_package)
CMake Error at cmake/FindIlmBase.cmake:121 (IF):
  if given arguments:
    "NOT" "Half" "IN_LIST" "_ILMBASE_COMPONENT_LIST"
  Unknown arguments specified

I may have mis-understood this error, but I attempted to add a policy to the CMakeLists.txt but that doesn't seem to have worked.
Finally, I attempted to add a "latest" build running off the GitHub top-of-tree for every dependency and found two problems:

Boost 1.70.0 beta is not yet fully supported in the latest CMake, I hard-coded "latest" to 1.69.0 and this resolved this one but it's not ideal. The association between Boost and CMake is a bit strange in my opinion.
Using the latest Blosc produces a compile error in TestFile.cc that needs to be tracked down:

/root/project/openvdb/unittest/TestFile.cc:2555:17: error: no matching function for call to 'blosc_compcode_to_compname'
        if (0 > blosc_compcode_to_compname(compcode, &compname)) continue;
                ^~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/include/OpenEXR/../blosc.h:389:18: note: candidate function not viable: no known conversion from 'char **' to 'const char **' for 2nd argument
BLOSC_EXPORT int blosc_compcode_to_compname(int compcode, const char **compname);

I'm tempted to stand up a regular nightly (or even weekly?) job that builds OpenVDB against every released version of Blosc between 1.50 and the latest just so we can be 100% sure which versions are supported properly and to prevent any regressions in this area.
There's still a handful of todos in CMakeLists.txt such as this comment about malloc:
# @todo scalable/concurrent malloc option(s)
Are you planning to resolve these before merging?

I'd rather we leave Blosc enabled by default. Even though it's an optional dependency, OpenVDB relies so heavily on it, I think it could be confusing that you have to explicitly switch it on when building the core library as standalone.

My opinion is that we keep it off. It's not available through apt-get and the version from Homebrew currently isn't tested and doesn't work with VDB (unit tests don't compile and fail even once fixed) so it might be a big ask for some users to have to manually download and build this. Ultimately I want to implement this whole "use if available" paradigm but it won't make it in to this PR. Perhaps something we can discuss at the TSC?

The only thing it's missing is the ability to do header checks which I don't believe is supported in CMake?

Yeah I haven't done this - prioritising the documentation so will add this to my list of things to do.

AppVeyor Windows build, but am running into this error

This is weird, is it using CMake >= 3.3? I'll try and have a look but thus far haven't had the chance to test on windows

The association between Boost and CMake is a bit strange in my opinion.

I agree, I'm not a fan either. I have some extra boost python/numpy fixes which I might try and get in to this PR too so if I do I can take a look at 1.7 as well.

Using the latest Blosc produces a compile error in TestFile.cc that needs to be tracked down

Have a ticket for this here: https://jira.aswf.io/browse/OVDB-78 and is part of the reason I think Blosc should be off for the moment.

todo's ... Are you planning to resolve these before merging?

Probably not, the only one I might try and resolve is the static/shared lib options but still prioritising the docs.

Thanks Nick, all sounds reasonable.

My opinion is that we keep it off. It's not available through apt-get and the version from Homebrew currently isn't tested and doesn't work with VDB (unit tests don't compile and fail even once fixed) so it might be a big ask for some users to have to manually download and build this. Ultimately I want to implement this whole "use if available" paradigm but it won't make it in to this PR. Perhaps something we can discuss at the TSC?

I agree that it's not ideal, keeping it off is probably fine. In addition to the message that suggests using 1.5, perhaps it would be worth also adding a message that says that it's strongly recommended to use it if it's not enabled at all?

Yeah sure that sounds goo, I'll do that.
One last thing, I still haven't enabled correct linking to _sidefx libs for 17.5. I've just tried this and am running into issues with vdb_render. All you need to add to enable this is:
# Versions of Houdini >= 17.5 have some namespaced libraries (IlmBase/OpenEXR).
# Add the required suffix as part of the cmake lib suffix searches

IF ( APPLE )
  LIST ( APPEND CMAKE_FIND_LIBRARY_SUFFIXES "_sidefx.so" )
ELSEIF ( UNIX )
  LIST ( APPEND CMAKE_FIND_LIBRARY_SUFFIXES "_sidefx.dylib" )
ENDIF ()

I'm going to continue looking into this before I commit this change though

Yeah sure that sounds goo, I'll do that.
One last thing, I still haven't enabled correct linking to _sidefx libs for 17.5. I've just tried this and am running into issues with vdb_render. All you need to add to enable this is:
# Versions of Houdini >= 17.5 have some namespaced libraries (IlmBase/OpenEXR).
# Add the required suffix as part of the cmake lib suffix searches

IF ( APPLE )
  LIST ( APPEND CMAKE_FIND_LIBRARY_SUFFIXES "_sidefx.so" )
ELSEIF ( UNIX )
  LIST ( APPEND CMAKE_FIND_LIBRARY_SUFFIXES "_sidefx.dylib" )
ENDIF ()

I'm going to continue looking into this before I commit this change though

I'm currently not building the Python module, binaries or unit tests for Houdini, only for the standalone builds. This seems to work switching off installing IlmBase/OpenEXR, so I think it only needs libHalf.so in fact. I can switch it on again, but not sure if that's worth doing or not as it's only really testing the build system?

Yeah it does only need half, but what if you want to build the binaries against Houdini? This used to be "supported" in the sense that it worked. I now get this:
CMakeFiles/vdb_render.dir/openvdb_render.cc.o: In function `(anonymous namespace)::saveEXR(std::string const&, openvdb::v6_0abi5::tools::Film const&, (anonymous namespace)::RenderOpts const&)':
openvdb_render.cc:(.text+0x19a8): undefined reference to `Imf_2_2_sidefx::setGlobalThreadCount(int)'
openvdb_render.cc:(.text+0x19eb): undefined reference to `Imf_2_2_sidefx::Header::Header(int, int, float, Imath_2_2_sidefx::Vec2<float> const&, float, Imf_2_2_sidefx::LineOrder, Imf_2_2_sidefx::Compression)'
openvdb_render.cc:(.text+0x1a13): undefined reference to `Imf_2_2_sidefx::Header::compression()'
openvdb_render.cc:(.text+0x1a37): undefined reference to `Imf_2_2_sidefx::Channel::Channel(Imf_2_2_sidefx::PixelType, int, int, bool)'
openvdb_render.cc:(.text+0x1a43): undefined reference to `Imf_2_2_sidefx::Header::channels()'
openvdb_render.cc:(.text+0x1a57): undefined reference to `Imf_2_2_sidefx::ChannelList::insert(char const*, Imf_2_2_sidefx::Channel const&)'
openvdb_render.cc:(.text+0x1a75): undefined reference to `Imf_2_2_sidefx::Channel::Channel(Imf_2_2_sidefx::PixelType, int, int, bool)'
openvdb_render.cc:(.text+0x1a81): undefined reference to `Imf_2_2_sidefx::Header::channels()'
openvdb_render.cc:(.text+0x1a95): undefined reference to `Imf_2_2_sidefx::ChannelList::insert(char const*, Imf_2_2_sidefx::Channel const&)'
openvdb_render.cc:(.text+0x1ab3): undefined reference to `Imf_2_2_sidefx::Channel::Channel(Imf_2_2_sidefx::PixelType, int, int, bool)'
openvdb_render.cc:(.text+0x1abf): undefined reference to `Imf_2_2_sidefx::Header::channels()'
openvdb_render.cc:(.text+0x1ad3): undefined reference to `Imf_2_2_sidefx::ChannelList::insert(char const*, Imf_2_2_sidefx::Channel const&)'
openvdb_render.cc:(.text+0x1af1): undefined reference to `Imf_2_2_sidefx::Channel::Channel(Imf_2_2_sidefx::PixelType, int, int, bool)'
openvdb_render.cc:(.text+0x1afd): undefined reference to `Imf_2_2_sidefx::Header::channels()'
openvdb_render.cc:(.text+0x1b11): undefined reference to `Imf_2_2_sidefx::ChannelList::insert(char const*, Imf_2_2_sidefx::Channel const&)'
openvdb_render.cc:(.text+0x1b8d): undefined reference to `Imf_2_2_sidefx::Slice::Slice(Imf_2_2_sidefx::PixelType, char*, unsigned long, unsigned long, int, int, double, bool, bool)'
openvdb_render.cc:(.text+0x1ba8): undefined reference to `Imf_2_2_sidefx::FrameBuffer::insert(char const*, Imf_2_2_sidefx::Slice const&)'
openvdb_render.cc:(.text+0x1be0): undefined reference to `Imf_2_2_sidefx::Slice::Slice(Imf_2_2_sidefx::PixelType, char*, unsigned long, unsigned long, int, int, double, bool, bool)'
openvdb_render.cc:(.text+0x1bf8): undefined reference to `Imf_2_2_sidefx::FrameBuffer::insert(char const*, Imf_2_2_sidefx::Slice const&)'
openvdb_render.cc:(.text+0x1c30): undefined reference to `Imf_2_2_sidefx::Slice::Slice(Imf_2_2_sidefx::PixelType, char*, unsigned long, unsigned long, int, int, double, bool, bool)'
openvdb_render.cc:(.text+0x1c4b): undefined reference to `Imf_2_2_sidefx::FrameBuffer::insert(char const*, Imf_2_2_sidefx::Slice const&)'
openvdb_render.cc:(.text+0x1c83): undefined reference to `Imf_2_2_sidefx::Slice::Slice(Imf_2_2_sidefx::PixelType, char*, unsigned long, unsigned long, int, int, double, bool, bool)'
openvdb_render.cc:(.text+0x1c9b): undefined reference to `Imf_2_2_sidefx::FrameBuffer::insert(char const*, Imf_2_2_sidefx::Slice const&)'
openvdb_render.cc:(.text+0x1ca0): undefined reference to `Imf_2_2_sidefx::globalThreadCount()'
openvdb_render.cc:(.text+0x1cbc): undefined reference to `Imf_2_2_sidefx::OutputFile::OutputFile(char const*, Imf_2_2_sidefx::Header const&, int)'
openvdb_render.cc:(.text+0x1ccb): undefined reference to `Imf_2_2_sidefx::OutputFile::setFrameBuffer(Imf_2_2_sidefx::FrameBuffer const&)'
openvdb_render.cc:(.text+0x1cdb): undefined reference to `Imf_2_2_sidefx::OutputFile::writePixels(int)'
openvdb_render.cc:(.text+0x1dfd): undefined reference to `Imf_2_2_sidefx::OutputFile::~OutputFile()'
openvdb_render.cc:(.text+0x1e18): undefined reference to `Imf_2_2_sidefx::Header::~Header()'
openvdb_render.cc:(.text+0x1e6d): undefined reference to `Imf_2_2_sidefx::Header::compression()'
openvdb_render.cc:(.text+0x1e84): undefined reference to `Imf_2_2_sidefx::Header::compression()'
openvdb_render.cc:(.text+0x1fd3): undefined reference to `Imf_2_2_sidefx::Header::~Header()'
openvdb_render.cc:(.text+0x2099): undefined reference to `Imf_2_2_sidefx::OutputFile::~OutputFile()'

I think it's just a problem with the CMake though, not the Houdini libs

Okay I think this was just me being stupid, the snippet I like you had the suffixes the wrong way around... All seems to work, situation normal....

I think it's just a problem with the CMake though, not the Houdini libs

From the looks of things it needs the version in the suffix as well as "_sidefx":
    LIST ( APPEND CMAKE_FIND_LIBRARY_SUFFIXES
      "-${IlmBase_VERSION_MAJOR}_${IlmBase_VERSION_MINOR}.so"
      "-${IlmBase_VERSION_MAJOR}_${IlmBase_VERSION_MINOR}_sidefx.so"
      )

I suggest we just add the building of the binaries and Python module to the Clang Houdini 17.5 job, I'll do that now. I have a GCC H17.5 job, but I've had to throttle the threads to 1(!) to avoid it running out of memory so it takes 58 mins in comparison to the Clang build which takes just 24 mins.

Pushed up this trivial change to the cmake_stage branch, will test on mac and travis too then commit

So I'm still running into issues on Mac with Houdini 17.5.173, the same symbol errors as above. If I run strings libIlmImf_sidefx.so | grep compression on linux I get:
_ZN14Imf_2_2_sidefx6Header11compressionEv
_ZNK14Imf_2_2_sidefx6Header11compressionEv
_ZNK14Imf_2_2_sidefx14RgbaOutputFile11compressionEv
_ZNK14Imf_2_2_sidefx13RgbaInputFile11compressionEv
_ZNK14Imf_2_2_sidefx19TiledRgbaOutputFile11compressionEv
_ZNK14Imf_2_2_sidefx18TiledRgbaInputFile11compressionEv
_ZNK14Imf_2_2_sidefx14AcesOutputFile11compressionEv
_ZNK14Imf_2_2_sidefx13AcesInputFile11compressionEv
compression
Unknown compression type in image header.
" failed. The files use different compression methods.
Unhandled compression scheme case
Data compression (zlib) failed.
Data decompression (zlib) failed.
Invalid compression type for ACES file.
Unknown compression method in chunk offset reconstruction
_ZNK14Imf_2_2_sidefx13AcesInputFile11compressionEv
_ZNK14Imf_2_2_sidefx6Header11compressionEv
_ZNK14Imf_2_2_sidefx13RgbaInputFile11compressionEv
_ZNK14Imf_2_2_sidefx14AcesOutputFile11compressionEv
_ZNK14Imf_2_2_sidefx14RgbaOutputFile11compressionEv
_ZNK14Imf_2_2_sidefx18TiledRgbaInputFile11compressionEv
_ZN14Imf_2_2_sidefx6Header11compressionEv
_ZNK14Imf_2_2_sidefx19TiledRgbaOutputFile11compressionEv

on mac, strings libIlmImf_sidefx.dylib | grep compression, I get:
compression
Unknown compression type in image header.
" failed. The files use different compression methods.
Unhandled compression scheme case
Data compression (zlib) failed.
Data decompression (zlib) failed.
Invalid compression type for ACES file.
Unknown compression method in chunk offset reconstruction

I'll try a Mac build myself. I should point out that those symbols do exist:
If I do (note the extra hyphen) strings - libIlmImf_sidefx.dylib | grep compression:
compression
Unknown compression type in image header.
" failed. The files use different compression methods.
Data compression (zlib) failed.
Data decompression (zlib) failed.
Unhandled compression scheme case
Invalid compression type for ACES file.
Unknown compression method in chunk offset reconstruction
G1compressionEv
compressionEv
qcompressionEv
compressionEv
compressionEv
compressionEv
1compressionEv
1compressionEv
__ZN14Imf_2_2_sidefx6Header11compressionEv
__ZNK14Imf_2_2_sidefx13AcesInputFile11compressionEv
__ZNK14Imf_2_2_sidefx13RgbaInputFile11compressionEv
__ZNK14Imf_2_2_sidefx14AcesOutputFile11compressionEv
__ZNK14Imf_2_2_sidefx14RgbaOutputFile11compressionEv
__ZNK14Imf_2_2_sidefx18TiledRgbaInputFile11compressionEv
__ZNK14Imf_2_2_sidefx19TiledRgbaOutputFile11compressionEv
__ZNK14Imf_2_2_sidefx6Header11compressionEv

I suspect that this is something to do with IMF_EXPORT.

Okay I know why this is happening. I'm using homebrew which puts everything under /include which is getting included before OpenEXR/IlmBase and ends up pulling in the non namespaced headers. I'll take a look at fixing the include order again, I must have broken it

fixed on the stage branch


Adding the slot asset name in parenthesis next to the slot name in th…

…e foldout.  This helps avoid confusion when working with multiple recipes with different slots, yet the slots are named the same.

here's a preview:

Looks good!


[python][examples] Added example of custom feval with sklearn wrapper

Addressed to #1453.

Examples could be run by the same command on both Windows and Linux

conf files had been written years ago and contains outdated information in many cases (e.g. possible values of parameter). I've added a note about it.


add support for proxmox lxc containers

Proposed Changes

adds support for using lxc containers as your kubernetes hosts
https://gist.github.com/triangletodd/02f595cd4c0dc9aac5f7763ca2264185

Checklist

[x] Tested locally
[x] Ran site.yml playbook
[x] Ran reset.yml playbook
[x] Did not add any unnecessary changes
[x] Ran pre-commit install at least once before committing
[x] 🚀

Also worth noting: everything about this appears to be working, but I have not been able to reach a VIP assigned by metallb. Assuming this is a network configuration problem on my end though, since metallb does assign an IP as far as I can tell.
curl just waits forever, browser gives a timeout after spinning for a long time with http://<IP_ADDRESS>.
$ kubectl describe service nginx
Name:                     nginx
Namespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=nginx
Type:                     LoadBalancer
IP Family Policy:         PreferDualStack
IP Families:              IPv4
IP:                       <IP_ADDRESS>
IPs:                      <IP_ADDRESS>
LoadBalancer Ingress:     <IP_ADDRESS>
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  30932/TCP
Endpoints:                <none>
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

$ kubectl get endpoints nginx
NAME    ENDPOINTS   AGE
nginx   <none>      92m

Nice! Wouldn't this playbook work without modifications if an LXC container has an IP?
Also, would love to figure out how to test this with molecule and GitHub actions before merging if it's possible.

Nice! Wouldn't this playbook work without modifications if an LXC container has an IP?

In short, no. Without the updates to the conf file / adding the rc.local script, k3s crashes on startup.
Also, would love to figure out how to test this with molecule and GitHub actions before merging if it's possible.

Yeah, was going to look at that but I ran out of tinkering time and wanted to put something up to make sure you were open to it. I might have some more time this week, def this weekend, want to figure out why I can't reach the service first to make sure it is not something related to k3s setup. Will follow up by Sunday.

Alright, turns out not being able to reach the service was just another instance of me only half following the docs, and assuming the service file would also deploy containers. I now understand that is not the case, and you do in fact need to do both the service and the deployment 🙂.
With that being said, this does work and shouldn't need any additional implementation changes. Will still follow up by Sunday.

After doing a bit of research, I'm not totally sure if there is an easy way to test this with molecule.
There is a proxmox driver, but looks like that expects to be able to have access to a host already running proxmox, don't think that will fit in with the CI. Also looks like it only supports VMs, not containers.
I don't think there is much that could be done here, other than superfluous tests that check the file contents, similar to this. I don't think these add any value, and instead just add to the maintenance overhead. Ideally, we'd spin up a cluster with proxmox lxc containers and check that Kubernetes is running after deploying, but I don't see a simple path to make that happen currently. Thoughts?
Also, I spent some time playing with the permissions. Everything configured is definitely required, not running any of these tasks on either the control or worker nodes results in a cluster that does not start.

Thank you for doing this.  It's unfortunate that we don't have a test proxmox environment :)

Glad I could give back, hope it saves others some time :) thanks for making the slick playbook!


Support for Shallow IPs

Feature request:
Add the possibility of building an SIP (or any other IP for that matter) that is able to move transport the information about the content files, but not the files themselves, i.e. it will only carry pointers to the files.
In theory this is already possible without breaking the current implementation, but it would be nice to add a section to the spec explaining how to accomplish this.
Comment from @karinbredenberg: This information should live on the guidelines and not on the spec (see https://guides.dilcis.eu/guideline/Guideline_IP_and_more_v1_0_0.pdf)

According to @karinbredenberg this request violates one of the principles of the CSIP, however there are several use cases where this approach is quite useful.
@shsdev and @luis100 are able to provide some real world use cases.
I would like to bring this discussion to the next DILCIS Board meeting for approval. If this feature is approved, KEEP SOLUTIONS can describe its implementation approach.

During the DILCIS board (2022-12-15) it was identified that this approach violates the following CSIP principles:

Following Principle 3.2, it is strongly recommended that this logical structure is manifested as a physical folder structure.

Principle 3.2: The Information Package SHOULD ensure that data and metadata are physically separated from one another.
In addition to the logical separation of components, it is beneficial to have data and metadata physically separated (i.e. formatted as individual computer files or clearly separated bitstreams). This allows digital preservation tools and systems to update respective data or metadata portions of an Information Package without endangering the integrity of the whole package.

This is a strategy currently being in use by the Portuguese National Archives for the Distributed Digital Preservation service.
When this was presented, there were comments from some E-ARK partners that this strategy could help on large migration projects, specially when we need to wrap files in E-ARK SIP to be able to send them to an E-ARK compatible archive. Requiring files to be within the SIP will temporarily duplicate the amount of storage and requires a lot of I/O which may be unnecessary.
A similar strategy is also used in SIARD to segment SIARD files, for transfer but also for archiving, for example by the Danish National Archives. Although this does not solve the issue completely for SIARD, as a lot of data may not be in LOBS, it may solve the issue for SIPs, as we do not expect much data except for representation data files.

I know about a case where a community member needs to keep large amounts of image data, and they are using S3 to store them. Packaging the data would create a lot of redundancy, therefore they would be interested in having this feature for specific use cases.

The agenda for the next meeting is already filled it needs to be on the one after that, @jmaferreira

Following the decision at the DILCIS Board meeting on the 6th of February a working group is created.
See: https://github.com/DILCISBoard/GroupDocumentation/blob/master/MeetingNotes/2024/20240206%20DILCIS%20Board%20and%20EARK%20CSP%20CORE11%20and%20others.md

ISSUE MOVED TO CSIP
This issue has been moved to the Common Specification (CSIP) project as the feature requested has impact on all information packages (SIP, AIP and DIP).
Please refer to https://github.com/DILCISBoard/E-ARK-CSIP/issues/747 for additional information and comments.


Update .travis.yml

Closes #15.

Note this line from the log:
┌ Info: Coverage.process_cov: Coverage file(s) for src/affine.jl do not exist.
└ Assuming file has no coverage.

However, src/affine.jl contains code.


allow base-<IP_ADDRESS>

I am updating Stackage Nightly to ghc-8.10.5:
base-<IP_ADDRESS> (changelog) is out of bounds for:

[ ] crypto-enigma-<IP_ADDRESS> (>=<IP_ADDRESS> && < =<IP_ADDRESS>). Roy Levien<EMAIL_ADDRESS>@orome. @orome. Used by: library

I think your upper bound for base is misleading: base should follow PVP closely and base-<IP_ADDRESS> should be back compatible with base-<IP_ADDRESS>, ie any upper bound using minor version x.y.z should be suspicious.

@juhp What did I do wrong? I get

base-<IP_ADDRESS> (changelog) is out of bounds for:
72 - [ ] crypto-enigma-<IP_ADDRESS> (>=<IP_ADDRESS> && < =4.14). Roy Levien<EMAIL_ADDRESS>@orome. @orome. Used by: library

I thought 4.14 was exactly what you were saying I needed here? What should it have been?

You want < 4.15.

Expanding a little:
base-<IP_ADDRESS> is the version in ghc-8.10.5, whereas you tightened the bound making it not even build with ghc-8.10.4 now.

You want < 4.15.

Got it. Fixed.

Fixed with commercialhaskell/stackage#6063


Activity bar top position: allow multiline layout, so that activity icons aren't hidden by other content

Type: Feature Request
I love saving the screen space with the activity bar on top, but when I switch to eg. debug, the debug target picker shows up in a same line as the activity bar, hiding all but two leftmost icons.
I would like these activity specific additions to have a separate line, so that the activity bar is always visible with all its icons.
Thanks for consideration!
VS Code version: Code 1.84.2 (1a5daa3a0231a0fbba4f14db7ec463cf99d7768e, 2023-11-09T10:52:57.054Z)
OS version: Darwin arm64 23.1.0
Modes:

/duplicate
https://github.com/microsoft/vscode/issues/195262

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


21.7 throws exeption during startup

If 21.7 is installed and the preferences (or RMANTREE) are pointing to it, the addon throws a TypeError complaining a BoolProperty() is too long with a size longer than 63.
The property is: 'Texture.Filtering And Defaults.Advanced Texture Settings_ui_open'
Since _ui_open is added automatically, replacing _ui-open with something shorter like _uio over the entire code base hase solved this for me.

same here, linux, blender-2.79a
TypeError: BoolProperty(): 'Texture.Filtering And Defaults.Advanced Texture Settings_ui_open' too long, max length is 63
ValueError: bpy_struct "PxrLayeredTexturePatternNode" registration error: Texture.Filtering And Defaults.Advanced Texture Settings_ui_open could not register
also changed _ui_open to _uio, solved problem for me to
Thanks adminradio

How can I fix this problem? I can't find 'Texture.Filtering And Defaults.Advanced Texture Settings_ui_open' bool property.
Linux 64-bit Blender 2.79a

as suggested by adminradio, replace every "_ui_open" to something shorter, for example "_uio"  over the entire code base
actualy replaced every "_ui_open" to "_ui_o" in:
shader_parameters.py
nodes.py
ui.py
works to, does not exceed lenght

@sollozzo13 the property is autogenerated during startup and can't be found directly in the code. A quick (and some kind dirty) solution is to shorten the postfix _ui_open to _uio or similar. This works, because the property exceeds the max length only by two chars.
I'll search for a better solution in the next few days.

Hi guys!
How can I fix this problem?

Windows 10 64-bit Blender 2.79a

Do you save your user preferences with the addon enabled?  If so it automatically tries to load it at startup. If it makes it halfway through registration and fails, then trying to enable it again can cause that error

RicardasSim, thank you for your solution, it fixed the error and now the official PRman add-on for Blender is working.
Windows 10 Pro 64bit (1511) + Blender 2.79b 64bit (portable) + RenderMan 21.7 + RMfB 21.5


Moving to new netflixoss build

LGTM - what's the timeline for setting up cloudbees after this is merged?

We can go and kick off the ensure and seed jobs immediately or they'll run
once a day and should be good to go tomorrow.
On Wed, Mar 18, 2015 at 1:21 PM, Matt Bossenbroek<EMAIL_ADDRESS>wrote:

LGTM - what's the timeline for setting up cloudbees after this is merged?
—
Reply to this email directly or view it on GitHub
https://github.com/Netflix/PigPen/pull/146#issuecomment-83154136.


feat(saiph): implement a low-rank SVD with random methods for faster computations

Context
When we face high dimensional data, the computation of the SVD may be very expensive. Moreover, we often face cases where few singular values are much bigger than the others, meaning that few dimensions are sufficient to preserve the dataset variance.
The following tests used adult-census dataset (48842 samples, 15 features, 110 dimensions after dummisation).
Full SVD
The full SVD is computed using the current Saiph implementation of the SVD (scipy).
Tracemalloc memory: current=8 605 724, peak=6 419 574 291
k=5

Randomized SVD
The fixed-rank SVD approximation computes a SVD with a smaller number of dimensions: l<min(m,n)
We used the algorithms described in http://arxiv.org/abs/0909.4061, page 27 and 29.
Tracemalloc memory: current=8 612 208, peak=4 096 625 713
k=5
Number of retained dimension (fixed-rank SVD approximation): nf=20 over 110 dimensions after dummisation (adult-census dataset).

Results
Using a significantly lower number of dimensions (eg < 0.5 * the number of dimensions), we have better performance both in time and memory with the randomized SVD. However, to preserve high-quality avatar data, the data must be mostly explained by this few number of dimensions: it is not applicable to each use case.

also, the CI is failing 😉


Terminal unexpected display

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.85.2
OS Version: windows 10

Steps to Reproduce:

give focus to a running terminal tab :

anti aliasing looks activated
there are spaces between the characters
2 The terminal is running correctly
3 to fix it, I can
close and reopen the terminal
change some settings of the terminal (curson blink on/off for example)

Now that i'm thinking about, maybe it's because I previously connect to my PC from remote RDP ?
Version: 1.85.2
Commit: 8b3775030ed1a69b13e4f4c628c612102e30a681
Date: 2024-01-18T06:40:10.514Z
Electron: 25.9.7
ElectronBuildId: 26354273
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19045

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.86.0. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

I cannot reproduce. Can you in insiders?

I see the same thing on Mac. It happens after VSCode has been running for a while. The only real setting I've tweaked is that I've set my scrollback to 25000.
Version: 1.86.0
Commit: 05047486b6df5eb8d44b2ecd70ea3bdf775fd937
Date: 2024-01-31T10:29:11.933Z (1 wk ago)

Here's some debugging info, hopefully it helps.
I dumped the styles from the div that holds the terminal window: https://gist.github.com/mmastrac/faa9001068b56a3f05787100e15b94f8

And from the xterm-rows div, styles https://gist.github.com/mmastrac/457fd04902bc62120f2c25f676446ea6:

Enumerating objects: 17, done.

Counting objects: 100% (17/17), done.

Delta compression using up to 12 threads

Compressing objects: 100% (9/9), done.

Writing objects: 100% (9/9), 705 bytes | 705.

00 KiB/s, done.

Total 9 (delta 8), reused 0 (delta 0), pack-r

eused 0

remote: Resolving deltas: 100% (8/8), complet

ed with 8 local objects.

To https://github.com/mmastrac/deno.git

   d0c83ce1c..5228d029e  deno_core_bump -> de

no_core_bump

✔ ~/Documents/github/deno/deno [deno_core_bum

p|⚑ 22]

16:06 $

The problem appears to be this style. If I toggle the letter-spacing style rule, the terminal appears to be fixed:

@meganrogge
Can it be connected to a previous remote desktop connection to the PC running vscode ?
When connecting and disconnection, the resolution change and, maybe, the terminal is not refresh correctly ?
@mmastrac Are you using such a remote desktop connection on your mac sahen it happend ?

@nonprenom I'm not using any sort of remote desktop. It just appears that a terminal "rots" after being in the background long enough (maybe the laptop going to sleep?).

Have had same issue for weeks

What do you mean by terminals in accessible mode?

Hi So it happend to me often - what can I save or check to help here ?

What do you mean by terminals in accessible mode?

It appears the affected terminal is switching from a canvas/GPU renderer to an HTML renderer. There are a few accessibility messages scattered around the terminals that switch when browsing the DOM.
I am not sure how any of the terminal rendering code works, so that's just a guess that it's accessibility.

I've been seeing this issue randomly for the better part of a year:

Not sure what causes it. It seems to occur with long-running terminal sessions, after some time has passed. In my case, they are training runs for machine learning.
I'm using Code-OSS on Arch Linux with x11.

The problem appears to be this style. If I toggle the letter-spacing style rule, the terminal appears to be fixed:

I'm not sure why, but only the terminals that are in an accessible mode (why are some of them switching to be accessible?) seem to be broken.

This is new info for me, I was not aware of letter-spacing to looks like this. Perhaps something is going wrong here:
): void {

@Tyriar Let me know if you'd like me to set a breakpoint somewhere and monitor a running instance. For now I'll try to set a breakpoint on that line and see if I can get you the cached W width.

The letter spacing is determined by this line:
https://github.com/xtermjs/xterm.js/blob/8e015ebf872001352c8f382364f6d58048b7800b/src/browser/renderer/dom/DomRendererRowFactory.ts#L149-L150
The width cache gives 0:

Width cache _flat:

https://github.com/xtermjs/xterm.js/pull/4973 should fix it

Thank you, @Tyriar. Appreciate the investigation and fix.


Zenith: Add version 0.9.10.r1

I'm getting an error on startup on Windows 10. It might be due to me using a virtual machine without Direct3D support though. (I have OpenGL 3.3 support thanks to mesa-dist-win.)

I'll try to run it on bare metal when I find some time and report if it works.

My bad, I only tested it on Windows 7 and didn’t encounter any issue. On the game’s page, I see it requires OpenAL!

On 12 Mar 2020, at 21:18, Hugo Locurcio<EMAIL_ADDRESS>wrote:

I'm getting an error on startup on Windows 10. It might be due to me using a virtual machine without Direct3D support though. (I have OpenGL 3.3 support thanks to mesa-dist-win.)
I'll try to run it on bare metal when I find some time and report if it works.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Folders can be moved to Trash folder

Requirements

Non special folders (!== [INBOX, DRAFTS, SENT, TRASH]) display a trash icon when hovered in folder-list
If folder is not in TRASH folder, clicking the icon moves the folder to the TRASH folder children
UI can be blocked until BE request completes
Folder-list is updated accordingly

Moved folder is removed from previous parent
Moved folder is added to new parent (TRASH)

Folder moved to trash is not removed from list


fix(DateField): Add isInvalid to DateInputRenderProps (closes #5662)

Closes Github issue #5662
✅ Pull Request Checklist:

[x] Included link to corresponding React Spectrum GitHub Issue.
[x] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[x] Filled out test instructions.
[x] Updated documentation (if it already exists for this component).
[x] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:
N/A
🧢 Your Project:
https://github.com/alex-mcgovern/react-spectrum

You'll need to sign the CLA, then close and re-open this to run the check again and get the build to pass.

GET_BUILD


All variable names within "export default" blocks are treated as alias real names

TS and JS Grammar Extension version:  0.0.43 / latest
I originally opened up this issue in dracula/visual-studio-code#82 - @dsifford replied and suggested that this could be an issue with the JS/TS grammar.
The gist of the problem is that all variable names within an export default block seem to be treated as the real name of an alias, even though that might not necessarily be the case. You can see this when using the Dracula theme in VSCode - all variable names within an export default block will show as italicized orange characters, which is Dracula's styling for the real names of import/export aliases.
This obviously causes a lot of wonky-looking syntax highlighting for themes such as Dracula whenever you write an export default block that contains anything other than references to outside variables. A common case where this happens is writing single-file components in Vue, where the recommended style is to write the entire script portion of your component within an export default block.
Code
const test = {
  testFn () {
    const testVar = 'test'
    return testVar
  }
}

export default {
  testFn () {
    const testVar = 'test'
    return testVar
  }
}

Screenshot

The scope from non default testVar is:
Scope:                         source.ts
                               meta.var.expr.ts
                               meta.objectliteral.ts
                               meta.method.declaration.ts
                               meta.block.ts
                               meta.var.expr.ts
                               meta.var-single-variable.expr.ts
                               meta.definition.variable.ts
                               variable.other.constant.ts

and the scope for testVar in default block is:
Scope:                         source.ts
                               meta.export.default.ts
                               meta.objectliteral.ts
                               meta.method.declaration.ts
                               meta.block.ts
                               meta.var.expr.ts
                               meta.var-single-variable.expr.ts
                               meta.definition.variable.ts
                               variable.other.constant.ts

I don't think there is anything here we need to do. Theme needs to handle scopes correctly instead.

Thanks @sheetalkamat! :wave: :smile:
@rmtracey  I'll check into this further on the theme side when time allows.


Cannot display photo/image in iOS

I installed cordova-plugin-ionic-migrate-localstorage and cordova-plugin-ionic-webview to keep local storage record during migration from UIWebView to WKWebView. However, image cannot be display and I am not okay to use window.Ioniic.WebView.convertFileSrc(path) as I am using ExtJS. below is the setting in config.xml:
 <preference name="iosScheme" value="httpsionic" />
    <allow-navigation href="httpsionic://*" />
    <allow-navigation href="file://*" />
    <allow-navigation href="file:///*" />
    <allow-navigation href="*" />
    <feature name="CDVWKWebViewEngine">
        <param name="ios-package" value="CDVWKWebViewEngine" />
    </feature>
   <preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />

Error:

[discovery] errors encountered while discovering extensions: Error Domain=PlugInKit Code=13 "query cancelled" UserInfo={NSLocalizedDescription=query cancelled}

What should I do to show photo correctly?

You have to use window.Ionic.WebView.convertFileSrc(path), that's regular javascript, should work with any framework or none at all.

@jcesarmobile , I am using mentioned 2 plugins but faced below error:
TypeError: undefined is not an object (evaluating 'window.Ionic.WebView.convertFileSrc') which I cannot handle path successfully. How can I fix it and why I have this problem? FYI, cordova-plugin-ionic-migrate-localstorage 0.0.2 "Migrate WebView Data" & cordova-plugin-ionic-webview 1.2.1 "cordova-plugin-ionic-webview"

The convertFileSrc function is available on 2.x and newer, if you are in 1.2.1, there was a similar function called normalizeURL or something like that. We don’t support 1.x.x of the plugin

@jcesarmobile I tried to use "cordova plugin add cordova-plugin-ionic-webview@latest" to download latest version but it still 1.2.1. Why don't let me download 4.0.1 for latest one?

Did you remove it first? If not, Cordova won’t update it.
If you removed it first but still got the old one, make sure you are on cordova >=7.1.0, cordova-ios >=4.0.0, cordova-android >=6.4.0.
No idea about the migration, sorry

I used cordova-plugin-ionic-migrate-localstorage v0.0.2 with cordova-plugin-ionic-webview v1.2.1. Then used normalizeURL() suggested by you then solve the problem. Thanks!