React Aria Components - Popover adding unnecessary offset when used with animation

Provide a general summary of the issue here
As you can see in the codesandbox the popover is adding unnecessary offset. However, after you resize the window it get into the correct position without the offset. (You have to enable "Emulate a focused page" in the deb tools so that the popover does not hide when you resize).
https://github.com/adobe/react-spectrum/assets/28673719/6c5d6d4e-abe9-4334-8d03-8244b0b3a38d
🤔 Expected Behavior?
The popover's edge should be the same as the trigger's respective to the placement (left, right, top, bottom, center).
😯 Current Behavior
The popover renders with a small offset.
💁 Possible Solution
No response
🔦 Context
No response
🖥 Steps to Reproduce

Go to https://codesandbox.io/s/determined-dust-gx53rd?file=/src/styles.css
Click the button
And you should see that the popover is rendered with an offset.

Version
1.0.0-beta.0
What browsers are you seeing the problem on?
Chrome
If other, please specify.
No response
What operating system are you using?
macOS
🧢 Your Company/Team
No response
🕷 Tracking Issue
No response

Looks like transform animations such as scale don't trigger resize observers. I'm not entirely sure what we can do about this. We wouldn't just wait for the animation to end and check again, that'd result in a jarring jump from the wrong position to the correct one.
We could set 'right' instead of 'left' when positioned 'bottom right', but that wouldn't solve the problem for centered elements.
You could create a wrapper element that is already the "correct" size, then transform the contents of it. I know that's less ideal.
We could check for an animation and then use raf polling to adjust the position each frame, that might keep it in the right spot in relation to the trigger while the animation is happening.
open to other ideas

Hey @snowystinger! Thanks for the quick reply and the suggestion.
I've successfully applied your suggestion and it works as expected. So I'll be closing this issue for now.


Remove lazy-static in favor of once_cell

What was changed
Removed dependencies on lazy-static in favor of once_cell. Use a workspace dependency to manage the once_cell dependency in one place.
Why?
lazy-static is effectively deprecated and the ecosystem has largely moved over to once_cell. once_cell has a more ergonomic API.
Checklist

How was this tested: still compiles
Any docs updates needed: don't think so?

Cleaned up the formatting and the missed lazy_static in the integration tests.

Ugh -- what's the reason cargo check --all-targets doesn't find the integration tests? Would be nice not to require the use of custom aliases for basic checks like this.

Ugh -- what's the reason cargo check --all-targets doesn't find the integration tests? Would be nice not to require the use of custom aliases for basic checks like this.

There are a handful of off-by-default features and there was no simple way to get every combo of feature/target to actually test compilation all at once


Python3.5: Absolute "import from" of a module was not supported

Hello Kay,
I think I found a bug in the way Nuitka handles local scope namespaces.
Here's what I got so far

Nuitka version, full Python version and Platform (Windows, OSX, Linux ...)

0.6.8rc2
Python: 3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 00:42:30) [MSC v.1916 64 bit (AMD64)]
Executable: c:\Python37-64\python.exe
OS: Windows
Arch: x86_64

How did you install Nuitka and Python (pip, anaconda, deb, rpm, from source,
what is a virtualenv ...), this is very important usually.

Installed via python.exe -m pip install "https://github.com/Nuitka/Nuitka/archive/factory.zip
I tried (for the first time) to compile a simple hello world project that uses FastAPI and uvicorn ASGI server.
Here's the SSCEE
from fastapi import FastAPI
import uvicorn

app = FastAPI()

@app.get("/")
async def read_root():
    return {"Hello": "World"}

@app.get("/items/{item_id}")
async def read_item(item_id: int, q: str = None):
    return {"item_id": item_id, "q": q}

if __name__ == "__main__":
    uvicorn.run("fapi_test:app", host="<IP_ADDRESS>", port=5000, log_level="info")

Both nuitka 0.6.7 and 0.6.8rc2 crash with the following output:
C:\TEST\fapi\fapi>c:\Python37-64\python.exe -m nuitka --standalone fapi_test.py
Traceback (most recent call last):
  File "c:\Python37-64\lib\site-packages\nuitka\__main__.py", line 186, in <module>
    main()
  File "c:\Python37-64\lib\site-packages\nuitka\__main__.py", line 179, in main
    MainControl.main()
  File "c:\Python37-64\lib\site-packages\nuitka\MainControl.py", line 739, in main
    main_module = createNodeTree(filename=filename)
  File "c:\Python37-64\lib\site-packages\nuitka\MainControl.py", line 142, in createNodeTree
    Optimization.optimize(main_module.getOutputFilename())
  File "c:\Python37-64\lib\site-packages\nuitka\optimizations\Optimization.py", line 619, in optimize
    finished = makeOptimizationPass(initial_pass=False)
  File "c:\Python37-64\lib\site-packages\nuitka\optimizations\Optimization.py", line 530, in makeOptimizationPass
    changed = optimizeModule(current_module)
  File "c:\Python37-64\lib\site-packages\nuitka\optimizations\Optimization.py", line 168, in optimizeModule
    changed = optimizeCompiledPythonModule(module)
  File "c:\Python37-64\lib\site-packages\nuitka\optimizations\Optimization.py", line 127, in optimizeCompiledPythonModule
    Plugins.considerImplicitImports(module=module, signal_change=signalChange)
  File "c:\Python37-64\lib\site-packages\nuitka\plugins\Plugins.py", line 160, in considerImplicitImports
    plugin.considerImplicitImports(module, signal_change)
  File "c:\Python37-64\lib\site-packages\nuitka\plugins\PluginBase.py", line 167, in considerImplicitImports
    signal_change=signal_change,
  File "c:\Python37-64\lib\site-packages\nuitka\plugins\PluginBase.py", line 462, in recurseTo
    reason=reason,
  File "c:\Python37-64\lib\site-packages\nuitka\importing\Recursion.py", line 167, in recurseTo
    reason=reason,
  File "c:\Python37-64\lib\site-packages\nuitka\importing\Recursion.py", line 83, in _recurseTo
    is_shlib=module_kind == "shlib",
  File "c:\Python37-64\lib\site-packages\nuitka\tree\Building.py", line 924, in decideModuleTree
    source_ref=source_ref,
  File "c:\Python37-64\lib\site-packages\nuitka\nodes\ModuleNodes.py", line 264, in __init__
    setLocalsDictType(self.module_dict_name, "module_dict")
  File "c:\Python37-64\lib\site-packages\nuitka\nodes\LocalsScopes.py", line 31, in setLocalsDictType
    assert locals_dict_name not in locals_dict_handles, locals_dict_name
AssertionError: globals_pydantic$__init__

My installed app list with the relevant FastAPI packages:
python.exe -m pip list
Package                 Version
----------------------- ----------
certifi                 2019.11.28
cffi                    1.13.2
chardet                 3.0.4
Click                   7.0
colorama                0.4.3
cryptography            2.8
**fastapi                 0.48.0**
h11                     0.9.0
idna                    2.8
multiprocessing-logging 0.3.0
Nuitka                  0.6.8rc2
pip                     20.0.2
progress                1.5
psutil                  5.6.7
pyarmor                 5.8.6
pycparser               2.19
pycryptodomex           3.9.4
**pydantic                1.4**
pyminifier              2.2
pyOpenSSL               19.1.0
python-tr               0.1.2
pywin32                 227
requests                2.22.0
requests-pkcs12         1.6
requests-toolbelt       0.9.1
setuptools              41.2.0
six                     1.13.0
**starlette               0.12.9**
tblib                   1.6.0
urllib3                 1.25.7
**uvicorn                 0.11.2**
vboxapi                 1.0
websockets              8.1
WMI                     1.4.9

I thought of a second SSCEE which would be simpler and triggers the same result
import pydantic

print('hello world')

When compiled with python.exe -m nuitka pydantic.py I get the same error.
Hope this might help identifying what's going on.
Best regards.

Just as an side, don't file against factory version, it's supposed to be known broken many times. But that's not an issue right now. There is nothing problematic on it right now.
Yes, definitely a core bug. I wasn't able to get your first reproducer to not give another error (an ImportError for routing) yet, but I was on Linux then. I wondered if it is related to the filename and casing on Windows, where two modules can relatively well collide for names.

So, seems like the pydantic modules gets loaded twice, clearly something that should never happen:

<Node 'COMPILED_PYTHON_MODULE' with {'filename': 'C:\Python37_64\lib\site-packages\pydantic\init.py', 'module_name': }>
<Node 'COMPILED_PYTHON_MODULE' with {'filename': 'C:\Python37_64\lib\site-packages\pydantic\init.py', 'module_name': }>

I was expecting paths to be different or something, but clearly not the case. Something really smelly is happening here. Still suspicious why this only happens on the case sensitive system.

So this might not be a Nuitka problem but a pydantic one ?
Should I open an issue there?

No doubt a Nuitka problem, I just don't know which one yet. There is an internal caching mechanism that ought to prevent loading already loaded modules again, that must fail, and it's all our fault surely.

Ok, so for reasons that most probably had to do with inabilities regarding unicode paths, Nuitka is using relative paths to reference modules, to key them in the import cache. Also the import cache handles the __init__.py by removing it, where as when checking it, it's not removed. This allows for the double load of the Python package there.
Making the paths unique, so they serve as a key, makes sense, but having two places with an algorithm for how to do it, not a good idea. I am unsure, why this doesn't happen more often, it apparently needs a module that becomes unused and then used again, but pydantic wouldn't be that special there. But it's also not a CompiledPythonPackage, but only a module there, so this is maybe why this becomes visible, and that would be another bug.

Ok, we defined an implicit dependency do pydantic.__init__ for pydantic by mistake.  That would include the code of pydantic twice, once as this module, and then as the proper package, only the top level, no big harm therefore, and the module is very probably very unused, and remains an issue. I suspect this might be some form of buggy output of hinted compilation for packages, but that's only a guess.

I remain puzzled why this only happens on Windows still. It is not special in any other way than that relpath is less often usable, but it falls back to abspath there, when two disks are used, but that's not what I am doing.

My ImportError for fastapi.routing is what I get immediately after. @JorjMcKie mentioned seeing something similar with new pandas. Nuitka claims to have it included, but it fails at import time, this seems serious too. That has also happened on Linux, and apparently is cross platform problem. The importing code seemed very robust, but alas ... there is never a last bug apparently.

After some trials it seems to me now that there is a pattern like this:

pandas.core.groupby.generic imports pandas.core.frame
pandas.core.frame then imports in turn pandas.core.groupby.generic

When it comes to point 2, the import fails allthough both modules are part of the binary (confirmed via --show-modules).

@JorjMcKie It seems there is a bug of Nuitka, that I hope to find shortly. The relative import is done with the proper level 1 as from .routing import something, but I have no evidence of the meta path based importer being asked about it at all. So I am getting this:

ImportError: cannot import name 'routing' from 'fastapi' (C:\Users\kayha\repos\Py2C\MINILD~1.DIS\fastapi_init_.py)

after these:

import fastapi.utils # considering responsibility
import fastapi.utils # claimed responsibility (compiled)
Loading fastapi.utils
import dataclasses # considering responsibility
import dataclasses # claimed responsibility (compiled)
Loading dataclasses

What normally always happens is that you get a trace that says "denied responsibility", definintely a "considering responsibility" for all modules, it gets asked about. But it does not appear to happen.
Maybe the common denominator is something messing with the meta path at run time, or starting to claim responsiblity of everything and having placed itself before Nuitka's, must be. Otherwise I cannot explain the lack of traces from  --python-flag=-v. I will enable import tracing now, just to see if the __import___ call is to blame (but Nuitka must be asked about non-found modules for sure).

What you describe, @JorjMcKie is a cyclic dependency then?

What you describe, @JorjMcKie is a cyclic dependency then?

yes, look at this (dist folder name abbreviated for better readability):
$ pandas-test
Traceback (most recent call last):
  File "$DIST\pandas-test.py", line 2, in <module>
  File "$DIST\pandas\__init__.py", line 54, in <module pandas>
  File "$DIST\pandas\core\api.py", line 29, in <module pandas.core.api>
  File "$DIST\pandas\core\groupby\__init__.py", line 1, in <module pandas.core.groupby>
  File "$DIST\pandas\core\groupby\generic.py", line 60, in <module pandas.core.groupby.generic>
  File "$DIST\pandas\core\frame.py", line 100, in <module pandas.core.frame>
ImportError: cannot import name 'generic' from 'pandas.core.groupby' ($DIST\pandas\core\groupby\__init__.py)

(Pandas seems to always fully quality where it imports stuff from, i.e. not using "." or ".." references.)
pandas.core.groupby.generic in line 60 imports something from pandas.core.frame, which gets imported for the first time at this point. This guy then tries to import (some other) things from pandas.core.groupby.generic again in its line 100.

So, this should be something we can make a simple reproducer out of. I believe the __spec__ has a _initializing field, that is set to True during module execution in Nuitka), to False only after the module finished. This could cause it to not exist when the cylic import happens.
I need to research, but I image the attribute does not get set that way precisely in CPython. So this would be a minor compatibility bug then with large effect.

I see this function on the call stack doing the diff, and I think CPython goes into the first branch:

def _load_unlocked(spec):
    # A helper for direct use by the import system.
    if spec.loader is not None:
        # not a namespace package
        if not hasattr(spec.loader, 'exec_module'):
            return _load_backward_compatible(spec)

    module = module_from_spec(spec)
    with _installed_safely(module):
        if spec.loader is None:
            if spec.submodule_search_locations is None:
                raise ImportError('missing loader', name=spec.name)
            # A namespace package so do nothing.
        else:
            spec.loader.exec_module(module)

    # We don't ensure that the import-related module attributes get
    # set in the sys.modules replacement case.  Such modules are on
    # their own.
    return sys.modules[spec.name]

The Nuitka loader has no exec_module, but Python 3.7 might have them, from what I see. This will be possible to cause such control flow differences, and Nuitka emulating _initializing in either case, on its own, may not be a good idea and even become unnecessary if we let importlib do its spiel here.
So, adding exec_module will be a kind of stunt, but improves compatibility, plus I need to check which Python version should have it and which not. I am pretty sure at 3.4/5 things were not that way yet.

Nah, all of Python3 from 3.4 definitely did it this way, so basically the since the __spec__ was invented.
But I think at one point, they started to allow these recursive imports, that would give errors. In fact, I vaguely remember dealing with similar stuff before. Maybe it's just that the solution is not working anymore in latest versions, anyway, this is possible to get under control. Just need to implement exec_module and create_module for Nuitka's loader it seems.

Funny side not, for plugins we have code like this:
def importFilePy3NewWay(filename):
    """ Import a file for Python versions 3.5+.
    """
    import importlib.util  # pylint: disable=I0021,import-error,no-name-in-module

    spec = importlib.util.spec_from_file_location(filename, filename)
    user_plugin_module = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(user_plugin_module)
    return user_plugin_module

That ends up being used for user plugins and probably works. The SourceFileLoader must have seen changes that disallow the use. I guess, if we make a test, we would find that 3.5 is the cut off for this being done for source modules, which then allowed the cyclic dependency to work so that new code increasingly is not worried in using it, and we find more and more cases.

I am pretty sure at 3.4/5 things were not that way yet.

When I mentioned Linux having the same thing happening, it was Python 3.6 which I meant ...

The 2 step initialization process, is kind of a bigger change. Module gets created first, and then executed. Due to being created first, I assume, it's sooner in sys.modules and therefore usable for the import statements during its execution.
The preload and postload code of course need to still be run at appropiate times, and this will take some re-factoring, and of course, the module object creation becomes then version dependent and name dependent, since __main__ works differently of course (not loaded by import). But I might want to split this off for older Python as well, simply because it saves boiler plate C code, then it's probably not as bad. Let's see if I get something working soonish.

But this theory took a hit when I saw this in module code very early on, before any code runs:
// Seems to work for Python2.7 out of the box, but for Python3, the module
// doesn't automatically enter "sys.modules", so do it manually.
#if PYTHON_VERSION >= 300
    {
        int r = PyDict_SetItemString(PyImport_GetModuleDict(), module_full_name, module_%(module_identifier)s);
        assert(r != -1);
    }
#endif

So this has to be about something else then, we will see. That of course is among the boiler plate code that can be moved to our static C code then.

As an side, the standalone import hinting is giving very different outputs that the pure Python one, mostly because of $PYTHONPATH replacements not done with the dist folder. I am not sure, but I guess, we ought to use a similar replacement for the binary directory, or maybe adding it to sys.path before tracing will do. I found it surpringly useless in its current form for comparative standalone diagnosis. It was the first time I tried to use it for that, mostly because I was initially expecting a import argument deviation.
But basically @JorjMcKie how about we get there to be able to run the program compiled and uncompiled, in standalone, and see the first difference reported. There are a couple of imports, only Nuitka does, e.g. os early on, I think for path name manipulations, or maybe importlib, these are tricky too. But a meaningful diff would be a valuable debug tool. Then on top of that, I think there is a way to trace failed DLL loads, is there? If we traced those as well, even if only on Windows, we would be good. But for Linux, with strace, I would nearly know how to get there too.

I just noted, that trigger modules for pre- and postload must be compiled, or they might not get used, in case they were included as bytecode (which often makes a lot of sense though), they would be skipped. I am removing the special handling, but making those go through the same handling recursively.

Ok, this is very strange. I am very nearly sure, this cannot have happened, but the asyncio package, that is included as bytecode started to fail with relative imports in non-package. Nothing was setting __package__, right. But this ought to not have worked before. I was very confused by that. The fix is obviously to set it for __packages__ because PyModule_New won't do it. But why am I seeing this now?!

And in relatively bad news, the 2 step loading doesn't change the error for recursion. Back to square one?

My line of attack for this is for now to make the import tracing properly support standalone programs, and to minimize the differences to normal Python. I am absolutely uncertain where and why it happens that the cycle leads to this kind of error. I thought we make sure it's in sys.modules and that ought to be enough. But apparently that is not the case.

I succeeded at making the hint tracing more compatible with standalone mode. So far I had only used for some standard programs and modules, to see where levels, etc. default to, and how details must be handled for __import__.
In the course of it, I enhanced Nuitka to only use the FrozenImporter at the very start, and then to remove its other frozen modules, and to include them as the normal bytecode loader, which is more compatible. I didn't figure out why, but FrozenImporter uses the current directory in its tracebacks, which is weird. So I just limited it, and then added current directory to be considered PYTHONPATH for import tracing when running compiled in standalone.

So, of course from .fastapi import routing should actually consider the module fastapi.routing but the error says cannot import name 'routing' from 'fastapi' which is strange. There is code in Nuitka that does this:
        if level and python_version >= 350:
            emit(
                """\
if (PyModule_Check(%(from_arg_name)s)) {
   %(to_name)s = IMPORT_NAME_OR_MODULE(
        %(from_arg_name)s,
        (PyObject *)moduledict_%(module_identifier)s,
        %(import_name)s,
        %(import_level)s
    );
} else {
   %(to_name)s = IMPORT_NAME(%(from_arg_name)s, %(import_name)s);
}
"""

I am not sure, why level is checked for non-zero here. The absolute imports of Python3 ought to also do this, so there would be no point. Probably when I first came across this, it was that way, so this can probably be safely removed.

Also, my goodness, I am bad at this:
            PyObject *fromlist = PyTuple_New(1);
            PyTuple_SetItem(fromlist, 0, import_name);

            result = IMPORT_MODULE5(const_str_empty, globals, globals, fromlist, level);

            Py_DECREF(fromlist);

I think this just looses a reference to the imported name, which probably looses a reference. I need to add a test to prove this, but definitely a source of corruption. The PyTuple_SetItem steals a reference only, and we were none given in that code. :/

So, for level 0, different code is needed, where the name is built from the original module, the level 1 is entirely different. I think I will be able to add this shortly. Woohoo. :)

I just pushed code that ought to work with this to factory, but right now I am on the road, unable to test with our case here.

It seems to work, but it reveals more hidden dependencies of uvicorn once it runs, e.g. uvicorn.logging is dynamically imported by uvicorn.config which at first fooled me into thinking that something had regressed.

So, on factory there is a solution for this. The extract that I made, refuses to run, missing fapi_test or so, but that is the same for Python and Nuitka, so probably just some incompleteness.
I added a missing dependency, removed a wrong one for pydantic, and most importantly, I added support for absolute imports to also be able to import modules. This allows for cyclic imports of modules, because the module needs no name assigned.
In case a package imported its child and was run first, this never became visible, as the mere attribute lookup was good enough.
Very complicated stuff, and like the root cause of a couple of issues we recently saw, @JorjMcKie . I am going to ignore these, and ask people to re-test once I did a pre-release, which should be soon now.

This is now on develop, and going to be part of the next release.

I can confirm that pydantic / fapi now compiles with Nuitka 0.6.8rc4.
As you suggested, uvicorn ASGI server won't run, but that wasn't your target for the issue.
Maybe as a side effect of https://github.com/Nuitka/Nuitka/issues/613, the error message stating that it cannot run ASGI app has some unicode signs in it:

Just for the records, when using hinted compilation, fastapi + uvicorn works great with Nuitka 0.6.8rc5, since we catch the dynamic imports :)
Closing this issue since pydantic now compiles with circular imports.

The release 0.6.8 was just made and contains the correction.

I got ERROR:    Error loading ASGI app. Could not import module "fapi_test".  when used the demo.
Python 3.7.10 FastAPI Uvicorn Nuitka all the newest version on Ubuntu 18.04

@Leezj9671 make a new issue


CppWinRT failed due to error C2039: 'IUnknown': is not a member of 'xlang::Foundation' on MSVC

Hi All,
The MSVC team build CppWinRT as a part of RWC testing to detect compiler regressions, recently CppWinRT failed due to error C2039: 'IUnknown': is not a member of 'xlang::Foundation'. Can you help look at this?
Repro steps:

open VS2109 x64 tools command
git clone https://github.com/microsoft/xlang F:\xlang
mkdir F:\xlang\build_amd64
cd F:\xlang\build_amd64
cmake -G Ninja -DCMAKE_SYSTEM_VERSION=10.0.17134.0 -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=cl -DCMAKE_CXX_COMPILER=cl -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX=install ..\src
cmake --build .\

Build log: build.log
Failures:
F:\xlang\build_amd64\test\cppx\xlang/impl/Foundation.Collections.0.h(241): error C2039: 'IUnknown': is not a member of 'xlang::Foundation'
F:\xlang\build_amd64\test\cppx\xlang/impl/Foundation.Collections.0.h(5): note: see declaration of 'xlang::Foundation'
F:\xlang\build_amd64\test\cppx\xlang/impl/Foundation.Collections.0.h(267): note: see reference to class template instantiation 'xlang::impl::consume_Foundation_Collections_IMapView<D,K,V>' being compiled
F:\xlang\build_amd64\test\cppx\xlang/impl/Foundation.Collections.0.h(282): error C2039: 'IUnknown': is not a member of 'xlang::Foundation'
F:\xlang\build_amd64\test\cppx\xlang/impl/Foundation.Collections.0.h(5): note: see declaration of 'xlang::Foundation'
F:\xlang\build_amd64\test\cppx\xlang/impl/Foundation.Collections.0.h(308): note: see reference to class template instantiation 'xlang::impl::consume_Foundation_Collections_IMap<D,K,V>' being compiled

The xlang repo contains a few projects, but C++/WinRT is certainly the most actively developed. We’re in the process of splitting them out into separate repos, but for now it’s a bit of a chore to build as some of these other projects aren’t that stable or complete.
If you limit cmake to build the cppwinrt_test target you should be able to build just C++/WinRT and avoid the other projects. Alternatively, you can use msbuild as follows:

Clone the repo:

C:\git> git clone https://github.com/microsoft/xlang

Build the x64 Release configuration of the C++/WinRT compiler (used to generate the C++/WinRT library):

C:\git\xlang\src\tool\cppwinrt> msbuild /m /p:Configuration=Release,Platform=x64 cppwinrt.sln /t:cppwinrt

Build the library (a projection of the Windows API) directly:

C:\git\xlang\src\tool\cppwinrt> build_projection.cmd

This simply invokes cppwinrt.exe to generate the headers.
At this point you can create your own console app and include the headers as needed or build the entire cppwinrt solution using x64 Debug to build all of the tests:
C:\git\xlang\src\tool\cppwinrt> msbuild /m /p:Configuration=Debug,Platform=x64 cppwinrt.sln

Hope that helps.

@kennykerr Thank you for providing the steps, I try them, but I got the below error from step 5(more detail see attachment), it seems that the headers conflict with windows's, how can I avoid this?

git clone https://github.com/microsoft/xlang d:\winrt_bak
pushd D:\winrt_bak\src\tool\cppwinrt
msbuild /m /p:Configuration=Release,Platform=x64 cppwinrt.sln /t:cppwinrt
build_projection.cmd
msbuild /m /p:Configuration=Debug,Platform=x64 cppwinrt.sln

build log:winrt.log
error:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\cppwinrt\winrt\impl\Windows.Foundation.Numerics.2.h(33): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int [D:\winrt_bak\src\tool\cppwinrt\old_tests\UnitTests\Tests.vcxproj]
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\cppwinrt\winrt\impl\Windows.Foundation.Numerics.2.h(33): error C2086: 'int WINRT_EXPORT': redefinition [D:\winrt_bak\src\tool\cppwinrt\old_tests\UnitTests\Tests.vcxproj]
D:\winrt_bak_build\Windows\x64\Debug\tool\cppwinrt\winrt\Windows.System.h(2601): error C2039: 'DispatcherQueue': is not a member of 'winrt::Windows::System' [D:\winrt_bak\src\tool\cppwinrt\old_tests\UnitTests\Tests.vcxproj]
D:\winrt_bak_build\Windows\x64\Debug\tool\cppwinrt\winrt\Windows.System.h(2601): error C2065: 'DispatcherQueue': undeclared identifier [D:\winrt_bak\src\tool\cppwinrt\old_tests\UnitTests\Tests.vcxproj]

@kennykerr Thanks for the info. I try VS2019 + Windows SDK 18362, CppWinRT is built successfully.

👍


Couldn't able to deploy the Python Azure function App through zip file and with package facing an Module Error

Hi ,
I am trying to deploying the python Azure Function app in cd/ci pipeline.
When I Archive the required files and published in the Build pipelines , Used the Artifact in the release pipeline.
The release pipeline was successful and in logs also I can see  Syncing triggers for function app ,Sync triggers for function app completed successfully   these but in the azure portal couldn't able to se the function app(or pushed files) in functions tab
So I have tried to Copy the required folder and published in the Build pipeline and gave the folder path in release pipeline where I am deploying the function app and the release got successful and now I can see the function app (or the pushed files ) in function tab.
When I am trying to trigger the function through service bus queue , I am facing an error with ModuleNotFoundError but I am installing the requirmnets.txt file before archive or copying the files in build pipeline
Exception while executing function: Functions.juecfunapp Result: Failure
Exception: ModuleNotFoundError: No module named 'requests'. Troubleshooting Guide: https://aka.ms/functions-modulenotfound
Stack:   File "/azure-functions-host/workers/python/3.9/LINUX/X64/azure_functions_worker/dispatcher.py", line 315, in _handle__function_load_request
    func = loader.load_function(
  File "/azure-functions-host/workers/python/3.9/LINUX/X64/azure_functions_worker/utils/wrappers.py", line 42, in call
    raise extend_exception_message(e, message)
  File "/azure-functions-host/workers/python/3.9/LINUX/X64/azure_functions_worker/utils/wrappers.py", line 40, in call
    return func(*args, **kwargs)
  File "/azure-functions-host/workers/python/3.9/LINUX/X64/azure_functions_worker/loader.py", line 85, in load_function
    mod = importlib.import_module(fullmodname)
  File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/home/site/wwwroot/juecfunapp/__init__.py", line 5, in <module>
    from juecfunapp.trigger import get_output
  File "/home/site/wwwroot/juecfunapp/__init__.py", line 5, in <module>
    from juecfunapp.trigger import get_output
  File "/home/site/wwwroot/juecfunapp/trigger.py", line 2, in <module>
    from juecfunapp.engine import ListJobs, RunJobs, RunOutputs, RunState
  File "/home/site/wwwroot/juecfunapp/engine.py", line 1, in <module>
    import requests

Tried with different runtimes also
Function app details:- linux, python 3.7, 3.8 and 3.9
Can so please help me where the problem is
Thanks and regards

This has happened to me before.
Some things to try:
0. If using venv, be sure to activate the venv then pip install requests

From within the Function directory, pip freeze > requirements2.txt

Note the "2"
You don't want to pip freeze over your existing requirements.txt file
Diff these two files. Be sure requests is there.

There is a Formal doc on what to do with ModuleNotFound errors

Hello, are you still facing this issue?


Improve logging

Add more logs to reflect the user activity

@sivaprasadreddy
I would be interested in working on it. This seems like a great opportunity for me to engage more with open-source projects. Could you please assign this issue to me?
Thanks

@maelstrom0x8 Assigning this to you.

Add logs to capture the key details in every controller methods.
Make sure we are not logging any sensitive data like passwords.


Implement nnUNet test case inference

After nnUNet training is complete, provide functionality to run inference on test cases.

Hey team! Please add your planning poker estimate with Zenhub @dalmouiee @fahimirfanalam @LoisHolloway


Update metrics API

Update the metrics API to reflect the latest version:
https://github.com/open-telemetry/opentelemetry-specification/blob/a131ae1ccabee8cc8f3b8cf109b81be378006fea/specification/api-metrics.md
and
https://github.com/open-telemetry/opentelemetry-specification/blob/5802f6e33644c5996c2fb46ef9f444f81ac2b158/specification/api-metrics-user.md

Remaining work here is to add tests. I'll get that done tonight/tomorrow morning, and aim to get this merged by tomorrow's SIG meeting.

Tests added. This is ready for review again.


Explorer view causes switching tabs

VSCode Version: 1.23.0
OS Version: macOS 10.13.4

Steps to Reproduce:

Open "compare" tab (compare any two files)
Press Cmd+Shift+E (Explorer view)
VS Code opens preview of the file selected in explorer view (automatically switches from compare tab)

@isidorn I like our current behaviour of reselecting whatever was last active in the explorer when clicking back to it. The intention was that you might have been doing some diff-work in the SCM viewlet and when you are done you click on the explorer to open your last active file. I actually rely on this behaviour quite often.

@bpasero I think we already had this discussion. Makes sense, I probably also rely on this. Thanks for claryfing.
@bam sorry will have to close as desigend as most users open explorer to get rid of the diff view.


PSR\Log 3.0.0

Updated version of PSR\Log has been released (simply adding void return types). We should update our third party version.

This might sit for a while as psr/log v2 and v3 both require PHP 8 as min version.

Ah shoot I missed that! I looked at the v2 to v3 diff and all the 8.0 stuff was v1.1.4 to v2. This is way down the road, closing.

I think it is planned for version 4.4 to drop PHP 7.4 support, so we can consider raising Psr/log to v3 again.

This is not easy.
php-coveralls/php-coveralls requires psr/log v1 or v2.

v2 is a good step, let's see what comes of the PHP Coveralls major release PR.


Extend the REST API endpoints so that they can me parameterized

🚀 The feature
Currently, there are 4 endpoints (detection, kie, ocr, recognition) which only take the image file as parameter. Ideally, they would be extended to support the same basic options as the streamlit app (detection model, recognition model, threshold, straight pages assumption), and they also could return the same JSON as the streamlit app does (including confidence for detected elements)
Motivation, pitch
I would like to use doctr deployed in docker container, and the endpoints don't have enough flexibility.
Alternatives
Installing doctr in the same docker container as the main (compiled) app and call external python process for the detection, without REST API. It will work, but there is less separation, independent upgrades will be more difficult, which is especially relevant due to to the size of doctr dependencies.
Additional context
No response

Hi @eudoxos :wave:,
Good idea i have already started to update the api a bit in https://github.com/mindee/doctr/pull/1522
We could in a follow up PR integrate the rest of the ocr_predictor options :)

done :)


Capture user input via internal API

Context
See https://github.com/gradle/gradle/issues/2837.
Branch build: https://builds.gradle.org/project.html?projectId=Gradle_Check&branch_Gradle_Check=bm%2Fcapture-user-input
Overview

Internal API for capturing user input
Capturing user input works in plain and rich console (if interactive)
Capturing user input works with and without daemon
User input can be requested for any answer
User input can be requested for a restricted list of answers
User input is sanitized
Entering ctrl-d during user input returns null (though we could think about failing the build via GradleException or skipping the task with StopExecutionException)
Currently unhandled: Detection of non-interactive console throws an exception (right now return null for user input). How exactly were you planning to handle that situation?

I'd like to hear your feedback as the build scan plugin will be first consumer of the functionality.

that was me ☝

Do we plan to store answers in the future (I don't want to agree on a license over for every build again, though we could hint how to apply the license in the build script persistently)

IMHO that is somewhat out of scope for this change. I'd expect the plugin using the API to implement such functionality. We can't really anticipate what the logic is going to do with the value after it was entered by the user. To conclude: not planned right now. In the long run we could think about the capability in Gradle core that stores value (however, we'd have to consider aspects like TTL, encryption of captured value etc). This sounds more like something we'd want to add with https://github.com/gradle/gradle/issues/2842.

Is checking for non interactive console enough to ensure this doesn't block for example CI builds?

The behavior at the moment: If you run in a non-interactive mode then the returned value from the API is going to be null. Even if you call the API in a non-interactive mode then it wouldn't block. We could provide some mechanism that a plugin can use to ask if the environment is interactive.

Should we probably provide a default mechanism?

That's not a bad idea. I was actually thinking about it as well but didn't want blow up the change. I think we can probably add something like that fairly easily. Will look into it.

Do we consider having a timeout on providing user input?

Was also wondering about it but couldn't really come up with a use case. In a non-interactive environment the user would not be asked. In an interactive environment the build would block on the question until the user enters ctrl-c/ctrl-d or enters an answer. Right now I can't think of reason why that wouldn't be sufficient.

Do we plan to store answers in the future (I don't want to agree on a license over for every build again, though we could hint how to apply the license in the build script persistently)

IMHO that is somewhat out of scope for this change. I'd expect the plugin using the API to implement such functionality. We can't really anticipate what the logic is going to do with the value after it was entered by the user. To conclude: not planned right now. In the long run we could think about the capability in Gradle core that stores value (however, we'd have to consider aspects like TTL, encryption of captured value etc). This sounds more like something we'd want to add with https://github.com/gradle/gradle/issues/2842.

Sounds good to me and shouldn't block build scan plugin adoption for this feature. We can provide a hint how to make this persistence for now by accepting license in the plugin.

Is checking for non interactive console enough to ensure this doesn't block for example CI builds?

The behavior at the moment: If you run in a non-interactive mode then the returned value from the API > is going to be null. Even if you call the API in a non-interactive mode then it wouldn't block. We could provide some mechanism that a plugin can use to ask if the environment is interactive.

that's good enough from my point of view and not blocking build scan plugin adoption.

Should we probably provide a default mechanism?

That's not a bad idea. I was actually thinking about it as well but didn't want blow up the change. I think
we can probably add something like that fairly easily. Will look into it.

nice!

Do we consider having a timeout on providing user input?

Was also wondering about it but couldn't really come up with a use case. In a non-interactive environment the user would not be asked. In an interactive environment the build would block on the question until the user enters ctrl-c/ctrl-d or enters an answer. Right now I can't think of reason why that wouldn't be sufficient.

I was more concerned by non interactive environments. It seems not necessary right now.
From my point of view this PR looks good. would be great if @ldaley can have a look to I think

Sounds good to me and shouldn't block build scan plugin adoption for this feature. We can provide a hint how to make this persistence for now by accepting license in the plugin.

As an alternative to capturing user input from the console I could envision us just asking the user to create a property file in a specific location with a mandatory key/value pair. A message on the console would clearly indicate where the file should exist and how the contents should look like. If the property file or the key/value does not exist then fail the build if --scan was requested without the necessary configuration.

I was more concerned by non interactive environments. It seems not necessary right now.

Certainly something we should make sure is working properly when you integrate the feature.

@oehme Would you mind giving this a review as well?

There needs to be a way that is as easy as possible for the user. Creating a properties file is not. We could provide the properties file approach as a secondary path, but definitely not as the first path of choice.

Regarding the scope of this story: I'd propose we keep it simple and provide a way for the scan plugin to ask one specific question: "Do you accept the license? Yes/No". The scan plugin can build code around this that

looks up a property before asking the question
stores the answer in gradle.properties so it doesn't have to ask again

We can enhance these capabilities later so that the user input API also takes over property lookup and storing answers.

@oehme Thanks for your additional feedback. I addressed your comments. Can you have another look?

I'd propose we keep it simple and provide a way for the scan plugin to ask one specific question.

I removed the default value functionality for now to keep the changes to a minimum.

Instead there should be a very simple service above the domain layer that solves exactly the issue that the scan plugin needs to solve.

Good point, done.

Do we have an issue to make it public?

Yes, see the attached epic.


Missing 00-init-schema migration

Bug report
Describe the bug
When trying to start a GoTrue instance with an external database the first migration 00_init_auth_schema.up.sql fails because the auth schema is not defined. In the supabase documentation and repo a volume is mounted with a sql script 00-initial-schema.sql responsible for creating the user supabase_admin, roles and extensions. While the first script 01-auth-schema.sql has as its first instruction the creation of the auth schema. It might be useful to bring it into the GoTrue repo as well to allow instances to be launched without manual intervention.
Expected behavior
Migrations should have everything needed.

Hi @claudioquaglia, does it mean we'd just need to add a line to create the schema if it doesn't exists in your local?

Hi @bariqhibat yup like it's done here. Btw I think it's needed an initial migration like is done here to create the user as well and enable needed extensions. This allow to have a full up and running instance without need to run scripts.

Hey all,
Apologies on the confusion -- going to go ahead and close this issue for now.
Going to close the issue as per: https://github.com/supabase/gotrue/pull/458#issuecomment-1111585758
As documentation improves hopefully this will be less of an issue. Feel free to reopen if you have any questions/concerns though.
Thanks!


type fileArgs -> rename to type FileDescription (in server/actions.ts)

type names should normally start capitalized. Also, FileDescription is a better name.

https://github.com/wasp-lang/open-saas/commit/2098add01e4c99cbb6db399a4d924259e89078a1


Build error when disabling easylogging

SDK Version 2.54.1
If I disable easylogging i get the following build error using gcc10
src/librealsense/src/terminal-parser.cpp: In member function ‘std::vector<unsigned char> librealsense::terminal_parser::parse_command(const string&) const’:
src/librealsense/src/terminal-parser.cpp:37:13: error: ‘cout’ was not declared in this scope
   37 |             cout << hex << fixed << setfill('0') << setw(2) << (int)b << " ";
      |             ^~~~
src/librealsense/src/terminal-parser.cpp:5:1: note: ‘std::cout’ is defined in header ‘<iostream>’; did you forget to ‘#include <iostream>’?

maybe specifically include  in terminal-parser.cpp ?

Hi @GrubbyHalo  Have you experienced this issue in the previous SDKs 2.53.1 or 2.51.1?
The most recent change to easylogging that is listed in the SDK release notes is 'Add easylogging include cmake' in SDK 2.51.1 - see https://github.com/IntelRealSense/librealsense/pull/10388

I haven't tested previous releases. This is the first time I have disabled easylogging, with release 2.54.1 I'm assuming that in the presence of easylogging that  is brought into the include list for terminal-parser among its dependencies and that in its absence it isn't ?

There were previously problems with -DBUILDEASYLOGGINGPP=OFF in 2020 but this was fixed by an update to the SDK, as described at https://github.com/IntelRealSense/librealsense/pull/7554 and there have not been reports of problems with easylogging since then.  Looking at the history of this support forum, it looks as though this flag is very rarely used and so you could likely use the SDK fine without setting this flag to off.
In regard to your question about the workings of easylogging, I don't know the answer to that.

I noticed that the fix you refered to included the missing  include file. subsequent to that it was removed again about 6 months ago in this commit. (Compare that commit and the one just before it)

I will highlight your finding about a missing include file to my Intel RealSense colleagues to seek their advice.

Hi @GrubbyHalo  Thanks very much for your patience.  My Intel RealSense colleagues were able to replicate your problem with easylogging=off and will discuss it.  Thanks again for your report of the issue!

Fix merged : #11962

Hi @GrubbyHalo  As a fix for the easylogging=off issue was merged into the RealSense SDK last week - see https://github.com/IntelRealSense/librealsense/pull/11962 - do you require further assistance with this case, please?  Thanks!

No further assistance required thanks.


Wrong path in MSFT_xSCSMARunbookWorkerServerSetup.psm1

On line 56 & 176:
$Path = Join-Path -Path (Join-Path -Path $SourcePath -ChildPath $SourceFolder) -ChildPath "\SMA\WebServiceSetup.exe"
As this is the setup for RunbookWorker I asume this should be:
"\SMA\WorkerSetup.exe"

I'll take care of this and the other related issue together.

This should have been resolved in PR #17.


Dyanmic group membership provider

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

:exclamation: No coverage uploaded for pull request base (main@46bd69e). Click here to learn what that means.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #205   +/-   ##
=======================================
  Coverage        ?   90.66%
=======================================
  Files           ?        4
  Lines           ?      418
  Branches        ?        0
=======================================
  Hits            ?      379
  Misses          ?       39
  Partials        ?        0

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


--file couldn't find the coverage file on Azure pipelines CI with a git repo

@bheemvennapureddy can you share

the commit SHA
the command you are using to run the uploader
have you changed that the file actually exists?


Remove jQuery

Firsty, many thanks to those that review this PR on a fairly antiquated codebase 🙏
This PR removes jQuery from Twine. It's part of a greater effort to remove jQuery from shopify.com. After researching our dependency chain we realised that until jQuery is removed from Twine we wouldn't be able to achieve that goal.
This PR contains a few "random" commits needed to work on the project locally and in CI (ea80b36 and 3751e55).
Otherwise, cc22591 migrates the event handlers from on/off and moves to native event handling. This required the most amount of changes so was isolated from the remaining migration in 929acdc.
As far as I can tell this change is compatible with earlier Twine releases with two exceptions:

Using jQuery.trigger(eventName, data) will no longer work. This was used in Twine tests but I haven't seen it in the wild yet.
data-bind-attribute will no longer process values that are functions. This behaviour seemed to be inadvertently possible because this logic will fall to jQuery's attr method which would handle executing functions before setting the resulting value. A Grok search for data-bind-attribute across Shopify's codebases didn't show any usage for this behaviour but I wouldn't say that was super exhaustive.

Given those two "regressions", I'd probably recommend that this should be released as Twine v2.

I have tophatted this on Brochure2 by checking that 3F still works as expected (this is the only place in Brochure we use Twine) 🎉

Using jQuery.trigger(eventName, data) will no longer work

I think there must be spots within admin doing things like $('.some-selector').trigger('click') or $someNode.trigger(...).  It's been a heck of a long time, but I believe that's roughly equivalent to jQuery.trigger(...).  I'd argue that we should not be bumping Twine within admin at this point, so while this is a breaking change of sorts

A Grok search for data-bind-attribute across Shopify's codebases didn't show any usage for this behaviour but I wouldn't say that was super exhaustive

You probably also need to search for bind-attribute as well (IIRC, at one point I believe we didn't have namespace our attributes with data-*)

I think we will also want to bump the Twine version, maybe using a major version in this case

I'd argue that we should not be bumping Twine within admin at this point, so while this is a breaking change of sorts, we don't need to break admin.

Definitely agree.
I'll push another commit which brings back data using event.detail. This won't prevent the regression as users would still have to modify their application to start dispatching custom events but at least there is some sort of upgrade path if folks are in that position.
I'll then push a "final" commit releasing this branch as v2.0.

I've pushed 9e91930 which bumps to v2.0.0 as per the Releasing notes.
Steps 4 & 5 look like they need to be done once the branch is in master (and I'm a bit unclear if I'll actually have permissions to run them locally 😅)

Steps 4 & 5 look like they need to be done once the branch is in master

IIRC yes

Great, well let me know how you want to proceed :) From the looks of things @lemonmade was the last to push a release (back in 2018 🙈)

https://github.com/Shopify/twine/releases as well


Escape strings in jupyter-config-data json

On Windows, following the CONTRIBUTING.md instructions in jupyterlab fails when loading JupyterLab on a json parse exception.  The jupyter-config-data JSON includes Windows paths where slashes are not escaped.  Calling json.dumps on all page_config values fixes this.

Thanks!  Patch release coming.

Released as v0.2.5.


Fix panic for nil-pointer dereference

Closes #1755

Codecov Report

Merging #1757 into master will decrease coverage by 0.05%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #1757      +/-   ##
==========================================
- Coverage   51.53%   51.47%   -0.06%
==========================================
  Files         161      161
  Lines       12528    12528
==========================================
- Hits         6456     6449       -7
- Misses       5076     5083       +7
  Partials      996      996

Impacted Files
Coverage Δ

internal/archiver/tree_saver.go
81.15% <0%> (ø)
:arrow_up:

internal/archiver/buffer.go
92.3% <0%> (-2.57%)
:arrow_down:

internal/backend/s3/s3.go
60.76% <0%> (-2.31%)
:arrow_down:

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 2a67258...fd77646. Read the comment docs.


Building site locally returns ERROR on google_analytics_async.html

Hello! I added a new blog post to my site on May 23, 2024 with no issues, but when I try to add another one and test it today, I'm getting the following error.
ERROR render of "section" failed: execute of template failed: html/template:_default/list.html:40:18: no such template "_internal/google_analytics_async.html"
ERROR render of "page" failed: execute of template failed: html/template:_default/single.html:40:18: no such template "_internal/google_analytics_async.html"
Built in 143 ms
Error: error building site: render: failed to render pages: render of "home" failed: execute of template failed: html/template:index.html:40:18: no such template "_internal/google_analytics_async.html"

I see there was a commit in this theme to fix that problem, but I've installed this theme as a submodule in my repository, and I'm not sure why it's not pulling in the change. I've linked my repository (as it was, working on 05/23/2024). https://github.com/JMHReif/jmhreif-website
Could someone assist with determining what I'm missing? Thank you!

Hello! I cloned your repo and reproduced the problem on my local machine. I got rid of the error message by creating an _internal/google_analytics_async.html file. I consider this a temporary solution. I came here looking for help with another problem, but I figured I could help you as well. I have a very similar blog. Could you tell us more about the changes made since the last working version?

I added the _internal/google_analytics_async.html file, but it's still throwing the error. Do I need to add that in a specific place in my repo?

As far as the changes made, I added a new blog post under the content folder, added a new image under the static folder (both are things I do all the time). I also updated a few of my old blog post names to start with a date, so that they have a consistent order under the blog folder. I wouldn't think renaming posts would cause that particular error, but maybe?

The Bug is fixt in Main but not in the newest release. :-(

I'm sorry, @DevTown, my frontend skills are less than stellar.....do I need to copy the whole baseof.html file from the theme repo into my repo and then modify there for it to pick up the change?

@DevTown and @ricardopoffo, I don't have Google Analytics enabled on my repo. The theme is a submodule in my repo, but I haven't pulled all the files into my repository (folder placeholder only). Could someone explain a bit more how this should work? I would really appreciate a bit more explanation! :)

@regisphilibert Could you deploy a fixed version from the main plz ?
@JMHReif : When you want to create your site local you can go to your checkout theme folder .
Where you go to the ananke\layouts_default Folder .
There you open the file baseof.html  in a editor of your choice .
Now delete line 40 and past the following line in it:
{{ template "_internal/google_analytics.html" . }}
After you save the file you can run hugo again.
The problem is not that you are using google_analytics or not. The theme has the possibility to use it and the theme has a bug.  It is fixed in the githubrepo but not i a released.

Thank you for the help, @DevTown! My site can be updated again. :)

Identical setup and problem for me. When is the next ananke release planned for this?

To get this theme to work with hugo v0.126 (as installed from nix packages 24.05) I had to revert the theme to the v2.9.2 tag and then apply DevTown's patch above.

This can be closed. Resolved with https://github.com/theNewDynamic/gohugo-theme-ananke/commit/26a78654fabfe49c29db831f74963564175ecc2d. Available in v2.10.0.

@jmooring thank you!


RxJS not configured correct in "system-config.ts"

angular-cli: 1.0.0-beta.5
node: 6.0.0
os: linux x64
$ ng new testngcli

Added to file: testngcli.component.ts
import { Component } from '@angular/core';
// Imported "Subject"
import { Subject } from 'rxjs';

@Component({
  moduleId: module.id,
  selector: 'testngcli-app',
  templateUrl: 'testngcli.component.html',
  styleUrls: ['testngcli.component.css']
})
export class TestngcliAppComponent {
  title = 'testngcli works!';
  // Instantiated a Subject
  test  = new Subject<any>();
}

mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create es6-shim.js:1541:11
GET
XHR
http://localhost:4200/vendor/rxjs/index.js [HTTP/1.1 404 Not Found 3ms]
Unhandled Promise rejection: "patchProperty/desc.set/wrapFn@http://localhost:4200/vendor/zone.js/dist/zone.js:769:27
	Zone</ZoneDelegate</ZoneDelegate.prototype.invokeTask@http://localhost:4200/vendor/zone.js/dist/zone.js:356:24
	Zone</Zone</Zone.prototype.runTask@http://localhost:4200/vendor/zone.js/dist/zone.js:256:29
	ZoneTask/this.invoke@http://localhost:4200/vendor/zone.js/dist/zone.js:423:29

	Error loading http://localhost:4200/vendor/rxjs/index.js as "rxjs" from http://localhost:4200/app/testngcli.component.js" ; Zone: <root> ; Task: Promise.then ; Value: Error: patchProperty/desc.set/wrapFn@http://localhost:4200/vendor/zone.js/dist/zone.js:769:27
	Zone</ZoneDelegate</ZoneDelegate.prototype.invokeTask@http://localhost:4200/vendor/zone.js/dist/zone.js:356:24
	Zone</Zone</Zone.prototype.runTask@http://localhost:4200/vendor/zone.js/dist/zone.js:256:29
	ZoneTask/this.invoke@http://localhost:4200/vendor/zone.js/dist/zone.js:423:29

	Error loading http://localhost:4200/vendor/rxjs/index.js as "rxjs" from http://localhost:4200/app/testngcli.component.js zone.js:461:14

Error: Uncaught (in promise): Error: patchProperty/desc.set/wrapFn@http://localhost:4200/vendor/zone.js/dist/zone.js:769:27
	Zone</ZoneDelegate</ZoneDelegate.prototype.invokeTask@http://localhost:4200/vendor/zone.js/dist/zone.js:356:24
	Zone</Zone</Zone.prototype.runTask@http://localhost:4200/vendor/zone.js/dist/zone.js:256:29
	ZoneTask/this.invoke@http://localhost:4200/vendor/zone.js/dist/zone.js:423:29

	Error loading http://localhost:4200/vendor/rxjs/index.js as "rxjs" from http://localhost:4200/app/testngcli.component.js
Stack trace:
resolvePromise@http://localhost:4200/vendor/zone.js/dist/zone.js:538:32
resolvePromise@http://localhost:4200/vendor/zone.js/dist/zone.js:523:18
scheduleResolveOrReject/<@http://localhost:4200/vendor/zone.js/dist/zone.js:571:18
Zone</ZoneDelegate</ZoneDelegate.prototype.invokeTask@http://localhost:4200/vendor/zone.js/dist/zone.js:356:24
Zone</Zone</Zone.prototype.runTask@http://localhost:4200/vendor/zone.js/dist/zone.js:256:29
drainMicroTaskQueue@http://localhost:4200/vendor/zone.js/dist/zone.js:474:26
ZoneTask/this.invoke@http://localhost:4200/vendor/zone.js/dist/zone.js:426:22
 zone.js:463:10

The problem is that systemjs is configured to reference rxjs from the "main" file index.js
const cliSystemConfigPackages: any = {};
barrels.forEach((barrelName: string) => {
  cliSystemConfigPackages[barrelName] = { main: 'index' };
});

But the the main file of rxjs is actually named "Rx.js"
So of course you could do a:
import { Subject } from 'rxjs/Rx';

But that would be a bit tedious.
I got it to work by doing:
const cliSystemConfigPackages: any = {};
barrels.forEach((barrelName: string) => {
  let main: string = barrelName === 'rxjs' ? 'Rx' : 'index';
  cliSystemConfigPackages[barrelName] = { main: main };
});

I guess you could also simply remove "rxjs" from the "barrels" array, and put it directly into the "cliSystemConfigPackages" to avoid overhead in the iteration.
cliSystemConfigPackages['rxjs'] = { main: 'Rx' };

But maybe there should be a "thirdpartyBarrels" process, or some other long term solution for angular2 dependencies that don't have a "index.js" as a main file?.. never know if there might be other than RxJS in the future.

Not sure if it is related, but I have insufficient methods on Observable. E.g. no filter() method on params field of ActivatedRoute.

Issue made obsolete by #1455.


Avalondock Anchorables could not be dragged inside MetroWindow

HI. I noticed that when Iam  using MetroWindow with avalondock, I cannot drag AnchorableGroup out of the WIndow. It just moves th whole window itself. But with standart WPF window, everything working correct.
Could this issue be fixed somehow?
For me its critical, because it affect features of docking control.

it would be nice if you create a small test application, to demonstrate the issue

here is the link on 2 apps demostrating the issue.
https://onedrive.live.com/?id=650F345C1F75A314!7115&cid=650F345C1F75A314&group=0

@punker76 are there any updates to this issue?


Tabs don't appear after adding a lot of them

Environment
Windows build number: 10.0.18362.0
Windows Terminal version: 0.5.2762.0

Steps to reproduce

Keep adding tabs until the newest tabs are no longer visible

Expected behavior
The new tabs should be visible
Actual behavior
The new tabs are not visible

I believe this no longer exists with #3027 .

If that's the case please close this issue.


Bug in single-precision linear system solving

Description
I initially found the bug solving AX=B in PyTorch, out of curiosity I then tried TensorFlow and Jax, which I rarely use.
The Jax fp32 solution was much more reasonable than those from PyTorch or TensorFlow, but still wrong for practical purposes, while NumPy was able to produce the correct  answer with single precision.
A,B as python lists can be copied from here https://gist.github.com/lddllddl/6621ce796e09903e7794366d60449ea4
For Jax the reproducing code is
import jax
Xj32 = jax.numpy.linalg.solve(jax.numpy.array(A,dtype='float32'),jax.numpy.array(B,dtype='float32'))
print('jax (numpy API) 32',jax.__version__,Xj32.min(),Xj32.max(),
    ((jax.numpy.array(A,dtype='float32') @ Xj32 - jax.numpy.array(B,dtype='float32'))**2).sum())
Xj32 = jax.scipy.linalg.solve(jax.numpy.array(A,dtype='float32'),jax.numpy.array(B,dtype='float32'))
print('jax (scipy API) 32',jax.__version__,Xj32.min(),Xj32.max(),
    ((jax.numpy.array(A,dtype='float32') @ Xj32 - jax.numpy.array(B,dtype='float32'))**2).sum())
Xj64 = jax.numpy.linalg.solve(jax.numpy.array(A,dtype='float64'),jax.numpy.array(B,dtype='float64'))
print('jax (numpy API) 64',jax.__version__,Xj64.min(),Xj64.max(),
    ((jax.numpy.array(A,dtype='float64') @ Xj64 - jax.numpy.array(B,dtype='float64'))**2).sum())
Xj64 = jax.scipy.linalg.solve(jax.numpy.array(A,dtype='float64'),jax.numpy.array(B,dtype='float64'))
print('jax (scipy API) 64',jax.__version__,Xj64.min(),Xj64.max(),
    ((jax.numpy.array(A,dtype='float64') @ Xj64 - jax.numpy.array(B,dtype='float64'))**2).sum())

import numpy as np
Xn = np.linalg.solve(np.array(A),np.array(B))
print('numpy',np.__version__,Xn.min(),Xn.max(),((np.array(A) @ Xn - np.array(B))**2).sum())
Xn32 = np.linalg.solve(np.array(A,dtype=np.float32),np.array(B,dtype=np.float32))
print('numpy 32',np.__version__,Xn32.min(),Xn32.max(),((np.array(A,dtype=np.float32) @ Xn32 - np.array(B,dtype=np.float32))**2).sum())
Xn64 = np.linalg.solve(np.array(A,dtype=np.float64),np.array(B,dtype=np.float64))
print('numpy 64',np.__version__,Xn64.min(),Xn64.max(),((np.array(A,dtype=np.float64) @ Xn64 - np.array(B,dtype=np.float64))**2).sum())

Results
jax (numpy API) 32 0.4.31 -414.1447 684.9193 20.846794
jax (scipy API) 32 0.4.31 -414.1447 684.9193 20.846794
jax (numpy API) 64 0.4.31 -114.81414097641223 4.718772190879267 1.157631242020755e-16
jax (scipy API) 64 0.4.31 -114.81414097641223 4.718772190879267 1.157631242020755e-16

numpy 2.1.0 -114.81414097641219 4.718772190879264 7.079649230705617e-17
np.array(B,dtype=np.float32))**2).sum())
numpy 32 2.1.0 -114.81414 4.7187724 5.3344417
np.array(B,dtype=np.float64))**2).sum())
numpy 64 2.1.0 -114.81414097641219 4.718772190879264 7.079649230705617e-17
>>>

System info (python version, jaxlib version, accelerator, etc.)
jax:    0.4.31
jaxlib: 0.4.31
numpy:  2.1.0
python: 3.12.5 (main, Aug 22 2024, 13:11:09) [GCC 14.2.0]
jax.devices (1 total, 1 local): [CpuDevice(id=0)]
in a Docker container running the official ubuntu image

Cross references:
https://github.com/pytorch/pytorch/issues/134905
https://github.com/tensorflow/tensorflow/issues/74965

The fact that you’re seeing the same issue in so many frameworks makes me suspect that your matrix is ill-conditioned at float32 precision. You can compute its condition number to be sure - it’s probably around 10^9 or larger.
Note that unlike JAX, torch, or tensorflow, NumPy will always do its computations at 64-bit precision even for 32-bit inputs, which would explain why you get better results there.

You are correct, and the condition number is indeed 5e9 - Interesting though why only JAX gets so much closer?

The fact that you’re seeing the same issue in so many frameworks makes me suspect that your matrix is ill-conditioned at float32 precision. You can compute its condition number to be sure - it’s probably around 10^9 or larger. If so, then these results are expected: an ill-conditioned system cannot be solved.
Note that unlike JAX, torch, or tensorflow, NumPy will always do its computations at 64-bit precision even for 32-bit inputs, which would explain why you get different results there.

You are correct, and the condition number is indeed 5e9

In that case, this is behaving as expected, and I think this issue (and the similar issues in the TF & pytorch repositories) can be closed.

Interesting though why only JAX gets so much closer?

It's probably an accident of implementation. For ill-conditioned linear systems, floating point rounding error dominates, and as you change the details of the implementation (even small things like order of operations) the numerical output can change substantially.


[IOS] Google sign in crashes the flutter app

I have same problem as this one: https://groups.google.com/forum/#!topic/flutter-dev/DFRfU2Nlv4k

Hi all,
google_sign_in 4.0.11 plugin crashes on the IOS device with the exception, but it works OK on the simulator.
PlatformException(google_sign_in, -[NSNull stringByAddingPercentEncodingWithAllowedCharacters:]: unrecognized selector sent to instance 0x38bb1978, NSInvalidArgumentException)
Example:
final GoogleSignIn _googleSignIn = GoogleSignIn();
final googleUser = await _googleSignIn.signIn();  //Crashing here

I'm using google_sign_in 4.0.14, and IOS Simulator on iPhone 5s.

dup of https://github.com/flutter/flutter/issues/44564

downgrade google_sign_in to 4.0.7, working now.

Hi @mingwugmail
thank you for noticing the duplicate
Please follow up on that issue,
I'm closing the current one as duplicate.
If you disagree please write in the comments
and I will reopen it.

All that manipulation with downgrading are wrong. You can keep all packages up-to-date. Problem is some genius developer forgot to check null before accessing variables, so you must use
GoogleSignIn googleSignIn = GoogleSignIn(
scopes: ['email', 'https://www.googleapis.com/auth/contacts.readonly'],
hostedDomain: "",
clientId: "",);
instead of
GoogleSignIn googleSignIn = GoogleSignIn(
scopes: ['email', 'https://www.googleapis.com/auth/contacts.readonly']);
each will lead to crash.
I lost one day of my life due to this silly bug. Hope you all doing better.
Please someone fix this simple bug, or update sample app and documentation. Thanks

Thank you :)

Could everyone who still has this problem please file a new issue with the exact description of what happens, logs and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.

@iapicca I was just testing my app (built with XCode 12) on the iOS 10 simulator and it had a similar crash.
iOS 11+ works fine.

@cpboyd please follow the indications above


click-default-group>=1.2.3

Now available as a wheel:

https://github.com/click-contrib/click-default-group/issues/21

:books: Documentation preview :books:: https://datasette--2173.org.readthedocs.build/en/2173/

Running tests to see if Pyodide works - that was the reason I switched to my click-default-group-wheel package originally.

Surprising error:
  blacken-docs -l 60 docs/*.rst
  shell: /usr/bin/bash -e {0}
  env:
    pythonLocation: /opt/hostedtoolcache/Python/3.11.4/x64
    PKG_CONFIG_PATH: /opt/hostedtoolcache/Python/3.11.4/x64/lib/pkgconfig
    Python_ROOT_DIR: /opt/hostedtoolcache/Python/3.11.4/x64
    Python2_ROOT_DIR: /opt/hostedtoolcache/Python/3.11.4/x64
    Python3_ROOT_DIR: /opt/hostedtoolcache/Python/3.11.4/x64
    LD_LIBRARY_PATH: /opt/hostedtoolcache/Python/3.11.4/x64/lib
docs/writing_plugins.rst:365: code block parse error Cannot parse: 8:0: <line number missing in source>


Check links on deployments, as well as daily via cron

It's looking at the SpaceX example instead of the docs deployment.

It's looking at the SpaceX example instead of the docs deployment.

It takes the deployment URL that Vercel reports via the GitHub Deployments API and looks at that for PRs the main branch.
For the cron based runs it looks at the default URL configured in the environment variable.
If we have multiple Vercel apps connected to this repo, it might look at wrong deployments in some cases 🤔


Featurerequest, have OCO orders not be limit, but market orders

today a stop loss was not executed, since the price of BNB to FL fell too fast.
Could the OCO orders be changed to be market orders instead of limit orders, so sl is guaranteed even if the price falls fast?
Thanks a lot

Hi @joengelh,
Indeed, this is a known issue. Adding a stop price parameter that is different from the stop limit will help (at the moment in the script stop limit = stop price).
This is a future enhancement that is planned: #3.
I'm quite busy at the moment but I will have look asap 🙏
I'm closing this one to keep the first ticket opened.
Thanks.


ROX-20714: Add regression unit test for the ClusterIP issue

Description
This PR adds unit test for clusterentities.Store. The tests are simple, but they highlight the problem of intentionally dropping all past IPs for a container when an update is applied in non-incremental mode.
A change of IP address for a Service in a cluster leads to a non-incremental change to the clusterentities.Store. This causes that all past IPs of the container are forgotten and if any connection is reported by Collector to those past IPs, the egde in the Network Graph would point to "External Entities" (although the entity is/was not external).
Checklist

[x] Investigated and inspected CI test results
[x] Unit test and regression tests added

N/A

[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
Here I tell how I validated my change
It is a unit test, so I validated it by running it.
Reminder for reviewers
In addition to reviewing code here, reviewers must also review testing and request further testing in case the
performed one does not seem sufficient. As a reviewer, you must not approve the change until you understand the
performed testing and you are satisfied with it.

Current dependencies on/for this PR:

master

PR #8626   👈

PR #8648

This stack of pull requests is managed by Graphite.

The tests are looking good structure-wise, I have trouble understanding the incremental concept in the code, though.
When we fix this behaviour, it would make no difference whether the incremental flag is set or not. Does this make the flag obsolete? Do we know why it was there in the first place?

Let me explain what incremental is doing. In the context of this PR, we can add multiple IP addresses (endpoints) to a container. Calling entityStore.Apply() with incremental=true will add IP address to a set of IP addresses for that container - having N endpoints for a container and calling Apply with incremental=true would result in N+1 endpoints for that container.
Calling the same Apply with incremental=false causes all existing endpoints for a container to be deleted before adding a new endpoint - having N endpoints for a container and calling Apply with incremental=false would result in having 1 endpoint for that container.

Thanks for the explanation!
With that understanding, a follow up question that will only be relevant for the implementation, not this test:
Do we need to change the returned format of IPs? Right now, all currently known endpoints are returned. with incremental=false, we overwrite them as of today. If we change the logic to retain old IPs like you defined in your test here, the caller cannot distinguish between currently active and historical endpoint IPs, correct?
(Nit: If that is the only functionality this flag changes, I would be in favor of renaming it to something more intuitive, e.g. append in a future refactor)

Do we need to change the returned format of IPs? Right now, all currently known endpoints are returned. with incremental=false, we overwrite them as of today. If we change the logic to retain old IPs like you defined in your test here, the caller cannot distinguish between currently active and historical endpoint IPs, correct?

Yes, this is correct. I still don't know if the return format should change. I see both options (changing and not changing) as possible.

Adding ability to tell if the connection is historical or not - this would be required only if we add a new type of graph-edge to the UI. Otherwise this information is not necessary.
Returning all IPs without info which is current which is past. There are actually 2 options to implement that: 1) Returning a modified structure that would mark each endpoint as "historical", 2) Keep LookupByEndpoint as it is (and return all IPs mixed) but add another method to return only the current ones (or only the historical ones).

(Nit: If that is the only functionality this flag changes, I would be in favor of renaming it to something more intuitive, e.g. append in a future refactor)

This is a good idea and we may use it. Or split the Apply call into two Add & Replace


Directline requests (POST and GET) failed with the resultcode = 0

Directline-JS SDK: 0.10.2
Starting to see the below failures of the directline  GET/POST requests (Timestamp is in UTC)

timestamp [Local Time]
data
success
resultCode
duration

2019-02-19T15:51:02.382
POST https://directline.botframework.com/v3/directline/conversations
False
0
224

2019-02-19T15:51:22.672
POST https://directline.botframework.com/v3/directline/conversations
False
0
283

2019-02-19T15:51:43.212
POST https://directline.botframework.com/v3/directline/conversations
False
0
339

2019-02-19T15:52:18.115
POST https://directline.botframework.com/v3/directline/conversations
False
0
309

2019-02-19T15:52:38.950
POST https://directline.botframework.com/v3/directline/conversations
False
0
233

2019-02-19T15:52:59.473
POST https://directline.botframework.com/v3/directline/conversations
False
0
523

2019-02-19T15:53:19.746
POST https://directline.botframework.com/v3/directline/conversations
False
0
273

2019-02-19T15:53:40.019
POST https://directline.botframework.com/v3/directline/conversations
False
0
263

2019-02-19T17:10:56.918
GET https://directline.botframework.com/v3/directline/conversations/IYzHUYmf01kC5LNhfTWSbE?watermark=1
False
0
7,079

2019-02-19T19:34:10.268
GET https://directline.botframework.com/v3/directline/conversations/7jonzVRWwNdLeL7XJm5Pfn?watermark=1
False
0
5

2019-02-19T20:23:45.193
POST https://directline.botframework.com/v3/directline/conversations/EmACwvZmpaLBxJ8R8B77gM/activities
False
0
961

2019-02-19T21:00:29.063
GET https://directline.botframework.com/v3/directline/conversations/IYzHUYmf01kC5LNhfTWSbE?watermark=1
False
0
13

2019-02-19T21:08:53.500
GET https://directline.botframework.com/v3/directline/conversations/EmACwvZmpaLBxJ8R8B77gM?watermark=55
False
0
1,362

2019-02-19T21:09:34.400
GET https://directline.botframework.com/v3/directline/conversations/EmACwvZmpaLBxJ8R8B77gM?watermark=55
False
0
20,003

Please help check if there's any issue of the directline server? or share the thought how to resolve the issue?

@EricDahlvang any update?

Hi @huajunzhao
We are escalating this internally for further investigation.  I apologize for the delay.

@EricDahlvang our service is seriously being impacted due to this, can you please help on this with priority?

Here are some latest failures (resultcode=0) logs in UTC timestamp.

GET request failed with long duration (~17s)

2019-02-26T02:52:45.713
|FjbBQ.mouVr
directline.botframework.com
Ajax
GET /v3/directline/conversations/DMAmKzt2xWWLmjaTZXwBBH
GET https://directline.botframework.com/v3/directline/conversations/DMAmKzt2xWWLmjaTZXwBBH?watermark=35
False
0
17,523
15sec-30sec

GET reqeust failed with short duration

2019-02-26T02:16:16.703
|FjbBQ.mRJHU
directline.botframework.com
Ajax
GET /v3/directline/conversations/DMAmKzt2xWWLmjaTZXwBBH
GET https://directline.botframework.com/v3/directline/conversations/DMAmKzt2xWWLmjaTZXwBBH?watermark=35
False
0
538
500ms-1sec

POST request failed

2019-02-26T02:50:37.347
|pihqZ.vnu5+
directline.botframework.com
Ajax
POST /v3/directline/conversations
POST https://directline.botframework.com/v3/directline/conversations
False
0
9
<250ms

Can you please us understand what does this each kind of request used for and how to resolve them?
Thx,
Kevin

@huajunzhao The services team has looked over the issues you are having.  They are indicating that resultcode=0 means the requests did not make it to the server (or there would be a failure status code).  This issue is not with the Direct Line service, but with the client.  Since the service never received these calls, our server logs have nothing to indicate what the underlying problem is with the client.
Have you tried using WebSockets instead of GET polling?

Thanks for the update.
Actually we've already switched to websockets in the client, This is our code
    const botConnection: any = localStorage.conversationId === null || localStorage.conversationId === undefined || localStorage.conversationId === 'undefined'
        ? new DirectLine({
            secret: this.props.directLine.secret,
            webSocket: true,
            watermark: '-'
        })
        : new DirectLine({
            secret: this.props.directLine.secret,
            conversationId: localStorage.conversationId,
            webSocket: true,
            watermark: '-'
        });

Be noted that the GET requests which failed with resultcode = 0 was having the below patterns (without activities)
GET https://directline.botframework.com/v3/directline/conversations/DMAmKzt2xWWLmjaTZXwBBH?watermark=35:
Per the document: https://docs.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-direct-line-3-0-reconnect-to-conversation?view=azure-bot-service-4.0 they're likely the conversation reconnects. some of them are long duration, while others not.
We don't know why see have so many failures. Can you instruct us how to troubleshoot/resolve this issue if you think it's client issues?
Can i get your MS alias for internal discussion?

Also we start seeing some 404 failure.

019-02-27T14:59:45.617
|x5W1S.xmQdH
directline.botframework.com
Ajax
GET /v3/directline/conversations/KirZ9Nyg84fG28xMuSCUwt
GET https://directline.botframework.com/v3/directline/conversations/KirZ9Nyg84fG28xMuSCUwt?watermark=-
False
404
410
250ms-500ms

What's the cause we see this?

Regarding the 404: maybe the conversation has 'expired' due to no activity?
see: https://github.com/Microsoft/BotFramework-DirectLineJS/issues/119#issuecomment-445066667

Conversation messages are only stored for 24 hours in DirectLine. Conversation metadata (such as conversation id and couple other housekeeping data) are removed after a period of inactivity (between 15 to 20 days).

Please email me at the address on my profile: https://github.com/EricDahlvang

@huajunzhao, do you still require assistance? If not I'll close the issue as resolved.

Actually I still have questions which need bot team to help or explain, i will touch Eric directly, please close this for now.


Fix golint issues in maya/orchprovider/nomad/v1/api.go

File: maya/orchprovider/nomad/v1/api.go
Line 1: warning: package comment should be of the form "Package v1 ..." (golint)

Resources:
-> Contributors guide: https://github.com/openebs/openebs/blob/master/CONTRIBUTING.md
Complexity: Easy

I am working on this issue


update orderbook url and section header

Change section header "Connect to the Orderbook"
Change the orderbook urls to cow protocol ones instead of Gnosis and add link to other urls.

Looking great!


lose HDMI for 2 specific rotations every time

Hopefully someone knows this one or its something wrong with my layout for a quick easy fix.
I have 10 screens, every time the rotation gets to the last 10th screen I lose HDMI (no signal) for 30 seconds (2 rotations) and then it comes back. nothing in syslog, nothing high CPU that I can see, load average: 0.15, 0.21, 0.25
Window layout as follows
`"0 0 1280 720"
"1280 0 1920 360"
"1280 360 1920 720"
"1280 720 1920 1080" \
#off-screen
"640 720 1280 1080"
"0<PHONE_NUMBER>"
"1920 0 2560 360"
"2560 0 3200 360"
"3200 0 3840 360"
"1920 360 2560 720"
`
You can view the layout at https://pasteboard.co/J7y8rLs.png
Anyone have any idea why it doesn't like that last rotation of 1920 360 2560 720?

Post your layout.default.conf (redacted) as an attachment, please.
My guess is you're running a higher-res feed (to start) in the large left
window.  That's going to cause problems as omxplayer has to down scale that
every time you move it to a smaller window (all the others).  Your windows
are overlapping by one pixel too (which makes them 641x361 which also
creates scaling duties for omxplayer).
Andy
On Sat, May 9, 2020 at 5:09 AM icepicknz<EMAIL_ADDRESS>wrote:

Hopefully someone knows this one or its something wrong with my layout for
a quick easy fix.
I have 10 screens, every time the rotation gets to the last 10th screen I
lose HDMI (no signal) for 30 seconds (2 rotations) and then it comes back.
nothing in syslog, nothing high CPU that I can see, load average: 0.15,
0.21, 0.25
Window layout as follows
`"0 0 1280 720"
"1280 0 1920 360"
"1280 360 1920 720"
"1280 720 1920 1080" \
#off-screen
"640 720 1280 1080"
"0<PHONE_NUMBER>"
"1920 0 2560 360"
"2560 0 3200 360"
"3200 0 3840 360"
"1920 360 2560 720"
`
You can view the layout at https://pasteboard.co/J7y8rLs.png
Anyone have any idea why it doesn't like that last rotation of 1920 360
2560 720?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Anonymousdog/displaycameras/issues/50, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHIYIKOBLUTD5XD5DJXR7ILRQUMVRANCNFSM4M4W5ZPA
.


License?

Want to do a non-commercial group buy, since you don't have any license listed just want to make sure you're okay with it before going ahead.
Not trying to profit off your work, just lowering the PCB fabrication costs by splitting it with more people 🙂.

Go ahead! The PCB is intentionally released without a licence - feel free to do what you want with it :)


Add a directory parameter to the File Picker Helper

Fixes #53
I added this new option at the end of the parameter list to make it backwards compatible with existing code. Let me know if that doesn't make sense.

Thanks!


Doc: add alert not to add afterglow-* class to video element when using with lightbox

Hi @pandada8,
sorry, I've been out of office for a few days. I actually can't really get what you are trying to tell me. :-) What do you think should exactly be changed - and why?

I happened to add .afterglow class to the video, and when click the  link, just got this.el_.play is not a function error, and then after reading code of the afterglow and videojs I just realize the original video element is a Play instance already now, and just being wrapped again. Maybe you could add some alert in lightbox's document to let others know ?

Actually, this is already in the documentation: http://docs.afterglowplayer.com/docs/lightbox-player#setup. It states clearly, that the video element should not get the class afterglow but the trigger element.
Also there is an alert with the headline "Class goes to the link, not to the player".
Doesn't this match your recommendation?


Exchange section

Seems that when you set the date to a time prior to any POL for that asset, it returns something a bit weird. It should be 0/0 I would think. Talking about the column furtherest to the right.
Also, while I'm here, @parrot9design I'd say that there could be a better descriptor than "EXCHANGE", though I understand where you're coming from. I'd recommend Protocol Owned Liquidity, as anybody across the industry from any ecosystem will recognize this. Hoping new users/potential investors immediately understand what this is w/o any friction/confusion. I don't necessarily love every new piece of lingo that comes out of the industry, but I think there are tangible benefits to making this a recognizable term for the balanced target market.

UPDATE: This is only a design issue. The issue mentioned above regarding amount of POL was accurate. It was a small test amount prior to making the large deposit.

We started out with Protocol-owned liquidity, but the length was an issue as it overcomplicated the section and is difficult to read in all-caps, so we decided it would better to use a shorter alternative (the fact that it’s jargon was a tertiary issue).
Protocol-owned is actually redundant to specify in a Holdings section, as all the assets listed are protocol-owned. Liquidity doesn’t work well on its own, so Exchange was the only heading that made sense, and is consistent with the main Stats page. Was also considering its use in a sentence "How much value does the Balanced DAO hold?" "It holds $x in the DAO Fund and $x on the exchange..."
If you have any other suggestions I’m happy to consider them, but Protocol-owned liquidity didn't seem like the right choice here.

I stand by my previous comment. Nothing to fix here.


make Job class immutable and avoid side effects in TransportExecutor

Before the TaskCollectingVisitor could've called addTasks itself. Now
the process functions of the visitor can no longer add tasks directly
but have to return them.

ack


Helm Lint ignores condition on dependencies

Output of helm version:
version.BuildInfo{Version:"v3.7.2", GitCommit:"663a896f4a815053445eec4153677ddc24a0a361", GitTreeState:"clean", GoVersion:"go1.17.3"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.3", GitCommit:"816c97ab8cff8a1c72eccca1026f7820e93e0d25", GitTreeState:"clean", BuildDate:"2022-01-25T21:17:57Z", GoVersion:"go1.17.6", Compiler:"gc", Platform:"darwin/arm64"} Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.5", GitCommit:"aea7bbadd2fc0cd689de94a54e5b7b758869d691", GitTreeState:"clean", BuildDate:"2021-09-15T21:04:16Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"} WARNING: version difference between client (1.23) and server (1.21) exceeds the supported minor version skew of +/-1
I have a chart which I am deploying into different clusters. The dependencies in this chart have their condition set to false by default.
I am enabling the dependencies in the values specific to each cluster.
E.g. Chart.yaml  which is disabled by default
This component is not deployed to Cluster A but is deployed to Cluster B. This works as expected with helm upgrade etc.
However, if I helm lint with the values specific for Cluster A errors are thrown. The errors tell me required values are missing in a template file of a dependency disabled in Cluster A.
This feels like helm lint is not considering the value set for the condition of this dependency.
I did some browsing through the code for the lint plugin and it looks like the condition/ tag on a dependency should be honored.
https://github.com/helm/helm/blob/12f1bc0acdeb675a8c50a78462ed3917fb7b2e37/pkg/chartutil/dependencies.go#L157-L159
Is my understanding correct that helm lint should ignore disabled dependencies?

I started writing a testcase for this and noticed that I could not reproduce the issue. Seems to be fixed with Helm v3.8.0.


DNM: Exercise kind lane

To debug cannot open /dev/null: Operation not permitted
Signed-off-by: Quique Llorente<EMAIL_ADDRESS>
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

/hold
DNM


Add skate icon

This was made in figma, which I don't know how to share offline but will figure something out later

yup!


[BUG] Santa Clara County Environment section is empty

Describe the bug
The Santa Clara County place page environment section is empty. When you click MORE CHARTS> , the environment page does have a chart. Not sure if this is intended.

To Reproduce
URL: http://datacommons.org/place?dcid=geoId/06085

Added equivalent charts to both the topic and overview sections so this doesn't happen again


After the system hangs up, the master worker registration information of the zk cache or mysql storage will cause the restart to fail.（系统挂机后，zk缓存或mysql存储的master worker注册信息会导致重启失败）

As the title, the system restarts using start_all.sh will report, the master already registted.

如题，系统重启使用start_all.sh会报，master already registted。

1.1.0 version will fix it , thx !

This is not a bug. After the master or worker is dropped, the zk temporary node will still exist (this is the internal mechanism of zk), and if there is a prompt message. To solve the problem in two ways, either manually delete the zk temporary node information, and then start it, or wait until the zk temporary node is deleted before starting. We can't delete the temporary node at startup because the running node may be deleted by mistake.
这不是一个bug，master或者worker掉后，zk临时节点还是会存在（这是zk内部机制），这时如果启动会有提示信息。两种方式解决，要么先手动删除zk临时节点信息，然后启动，或者等到zk临时节点删除之后再启动。我们不能在启动的时候删除临时节点，因为可能会误删除正在运行的节点

This is not a bug. After the master or worker is dropped, the zk temporary node will still exist (this is the internal mechanism of zk), and if there is a prompt message. To solve the problem in two ways, either manually delete the zk temporary node information, and then start it, or wait until the zk temporary node is deleted before starting. We can't delete the temporary node at startup because the running node may be deleted by mistake.
这不是一个bug，master或者worker掉后，zk临时节点还是会存在（这是zk内部机制），这时如果启动会有提示信息。两种方式解决，要么先手动删除zk临时节点信息，然后启动，或者等到zk临时节点删除之后再启动。我们不能在启动的时候删除临时节点，因为可能会误删除正在运行的节点

This is not a bug. After the master or worker is dropped, the zk temporary node will still exist (this is the internal mechanism of zk), and if there is a prompt message. To solve the problem in two ways, either manually delete the zk temporary node information, and then start it, or wait until the zk temporary node is deleted before starting. We can't delete the temporary node at startup because the running node may be deleted by mistake.
这不是一个bug，master或者worker掉后，zk临时节点还是会存在（这是zk内部机制），这时如果启动会有提示信息。两种方式解决，要么先手动删除zk临时节点信息，然后启动，或者等到zk临时节点删除之后再启动。我们不能在启动的时候删除临时节点，因为可能会误删除正在运行的节点

master或者worker可以通过监听Disconnected 事件并注册回调方法删除masterZnode临时节点，一个建议。

done


improve the footer

What feature?
In the footer, the description I want to add and the social media icons  are missing.
Add screenshots

please assign me @pa
please label gssoc and the level
Record

[X] I agree to follow this project's Code of Conduct
[X] I want to work on this issue

Hi @jayanththalla, the description is missing, and it is required. As for the icons, the code is already implemented since currently it doesn't have any social media accounts to link.
You can work on it


UI/notifications

Build notification system (EARLY VERSION)
:recycle: Current situation & Problem
Currently, the home view is empty. Moving forward, the UI for the Home Screen will include notifications, a to-do list, most recent vitals recorded, and a button to start the biweekly survey. To begin, we implemented a notification system that pulls notifications linked to the user's document in Firebase cloud storage, then displays them at the top of the dashboard in the Home Screen.
:gear: Release Notes

Restructured the Home Screen dashboard as a sectioned list including Notifications, To-do, Vitals, and Survey
Implemented a NotificationManager class that attaches a snapshot listener to a query on the currently signed in user's notification collection in Firestore
The query retrieves notifications that are younger than 10 days old, and the snapshot listener in the NotificationManager then filters for notifications that haven't been completed yet.
The NotificationManager is an environment accessible module that is configured in the ENGAGEDelegate.

:books: Documentation
See inline documentation in NotificationManager.swift and Notification.swift.
:white_check_mark: Testing
UI Tests will be integrated shortly.
Code of Conduct & Contributing Guidelines
By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

[X] I agree to follow the Code of Conduct and Contributing Guidelines.

@nriedman Feel free to tag me here and drop me a Slack message once we have incorporated the elements we discussed about in the meeting yesterday 🚀

@PSchmiedmayer I've gone ahead and incorporated the final changes we discussed. Ready for review!


Run ApolloCacheInterceptor store write on dispatcher thread

Discussed in https://github.com/apollographql/apollo-android/issues/2402
This allows cache writes to not block the response, as with the NormalizedCache the cache write can be relatively expensive (>100ms on larger responses).
I believe this is pretty safe:

The Store is already thread safe

All side effects of saving a response are already dispatched on a new thread

Because the entire cache interceptor is first placed on the dispatcher
A new operation that is enqueued after a previous operation returns should have it's read always run after a previous operations write.

The exception which is potentially thrown does not seem to be handled by any sync code, so moving it to a dispatcher shouldn't change behavior

Thanks for diving into this!
Looking at the default dispatcher, it's a ThreadPoolExecutor. Does that guarantee a FIFO order of execution? More specifically, from SynchronousQueue:
public SynchronousQueue()
Creates a SynchronousQueue with nonfair access policy

So the queue itself doesn't seem to guarantee order. Even if it did, wouldn't there be another race condition with multiple threads reading/writing the cache?

Good find on the queue documentation. It seems like we could switch it to use a fair implementation to get ordering gaurentee?

Even if it did, wouldn't there be another race condition with multiple threads reading/writing the cache?

I don't think so - or at least the main case we want to guarantee order is that once you receive a response, if you issue a request after the response you should be guaranteed to hit the cache. If the original situation is multi-threaded we currently wouldn't have any ordering guarantees besides those imposed by the read-write lock.

That does seem valid, but given the light-weight nature of the enqueue action, I would expect that be exceedingly rare - I don't think we would care about this edge case at Airbnb, but understand that this ordering guarantee may be something you wish to provide for Apollo
I suppose we could block returning the request until we receive some signal from that the write has started? Maybe we could pass a sempahore which is unlocked when the write is started...

Put up a proof of concept, open to other ideas for a cleaner approach!

The latch might reduce the probability of the race condition happening but I don't think it removes it completely since the consumer might schedule just after the countDown():
      return apolloStore.writeTransaction(new Transaction<WriteableStore, Set<String>>() {
        @Nullable @Override public Set<String> execute(WriteableStore cache) {
          cacheWriteStarted.countDown();
          // request1 can resume here and (theorically at least), nothing would prevent a `request2` to run before the merge starts.
          return cache.merge(records.get(), request.cacheHeaders);
        }
      });

What about putting this behaviour behind some kind of "feature-flip"? Something like ApolloClient.writeToCacheAsynchronously?
That would allow performance-savvy users to enable it and monitor it knowing in full consciousness without risking weird issue for other users?

@martinbonnin Updated to make this configurable when setting the normalized cache on the apollo builder

The CI is failing for a single char 😅 . Can you wrap the line?
[ant:checkstyle] [ERROR] /Users/runner/work/apollo-android/apollo-android/apollo-runtime/src/main/java/com/apollographql/apollo/internal/RealApolloCall.java:393: Line is longer than 140 characters (found 141). [LineLength]

The CI is failing for a single char 😅 . Can you wrap the line?

I just realized I had write access to your branch so I went ahead and wrapped all the lines!