Fritz!Box device tracker fails to install fritzconnection

After adding the device tracker, this happens upon starting hass:
INFO:homeassistant.loader:Loaded device_tracker.fritz from homeassistant.components.device_tracker.fritz
INFO:homeassistant.util.package:Attempting install of fritzconnection==0.4.6
Command "/usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-a75y6hpj/lxml/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-symu1gz8-record/install-record.txt --single-version-externally-managed --compile --home=/tmp/tmpjomu9sru" failed with error code 1 in /tmp/pip-build-a75y6hpj/lxml
ERROR:homeassistant.bootstrap:Not initializing device_tracker.fritz because could not install dependency fritzconnection==0.4.6

It "hangs" for more than a minute after Attempting install of fritzconnection==0.4.6, I suppose because trying to compile lxml takes a while. I'm running a headless Ubuntu server with 14.04.1 on it, python3-lxml is installed, so I'm not sure why it's even trying to compile that.
Installing fritzconnection manually (sudo pip3 install fritzconnection) works fine and installs 0.4.6 of it. Running hass afterwards results in this error:
INFO:homeassistant.loader:Loaded device_tracker.fritz from homeassistant.components.device_tracker.fritz
ERROR:homeassistant.components.device_tracker:Error setting up platform fritz
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/homeassistant/components/device_tracker/__init__.py", line 124, in setup_platform
    scanner = platform.get_scanner(hass, {DOMAIN: p_config})
  File "/usr/local/lib/python3.4/dist-packages/homeassistant/components/device_tracker/fritz.py", line 34, in get_scanner
    scanner = FritzBoxScanner(config[DOMAIN])
  File "/usr/local/lib/python3.4/dist-packages/homeassistant/components/device_tracker/fritz.py", line 61, in __init__
    import fritzconnection as fc
  File "/usr/local/lib/python3.4/dist-packages/fritzconnection/__init__.py", line 3, in <module>
    from fritzconnection import (
ImportError: cannot import name 'FritzConnection'

If there is any other information I need to provide please let me know. :)

This is an issue with the fritzconnection library not being updated for python3. See fix here. You can apply these changes yourself like that:
sudo nano /usr/local/lib/python3.4/dist-packages/fritzconnection/__init__.py
# -*- coding: utf-8 -*-

from .fritzconnection import (
    FritzConnection,
    FritzInspection,
    print_servicenames,
    print_api,
)
from .fritzhosts import (
    FritzHosts,
    print_hosts,
)
from .fritzstatus import (
    FritzStatus,
    print_status,
)

Unfortunately then you'll encounter the next error, but I gave up and going to try nmap now.

@thunfischbrot
Hey I was the one to start the fritzboxdevice scanner. What is the error you encounter after adding the fix you show?
I made a fork of fritzconnection with the fix you showed. It can be found here. If you install from this repo, it should work.
git clone git@github.com:deisi/fritzconnection.git
cd fritzconnection
sudo python3 setup.py install

I remember to add this for to requirements of HA, but there have been some changes to the way HA handles requirements. Maybe during this something went wrong.

@deisi I Have applied the fixes but now i'm getting the next error?

16-02-22 10:31:42 homeassistant.components.device_tracker: Error setting up platform fritz
Traceback (most recent call last):
File "c:\python34\lib\site-packages\homeassistant\components\device_tracker_init_.py", line 124, in setup_platform
scanner = platform.get_scanner(hass, {DOMAIN: p_config})
File "c:\python34\lib\site-packages\homeassistant\components\device_tracker\fritz.py", line 34, in get_scanner
scanner = FritzBoxScanner(config[DOMAIN])
File "c:\python34\lib\site-packages\homeassistant\components\device_tracker\fritz.py", line 87, in init
self.update_info()
File "c:\python34\lib\site-packages\homeassistant\util_init.py", line 275, in wrapper
result = method(*args, **kwargs)
File "c:\python34\lib\site-packages\homeassistant\components\device_tracker\fritz.py", line 115, in _update_info
self.last_results = self.fritz_box.get_hosts_info()
File "c:\python34\lib\site-packages\fritzconnection\fritzhosts.py", line 57, in get_hosts_info
while index < self.host_numbers:
File "c:\python34\lib\site-packages\fritzconnection\fritzhosts.py", line 39, in host_numbers
result = self.action('GetHostNumberOfEntries')
File "c:\python34\lib\site-packages\fritzconnection\fritzhosts.py", line 31, in action
return self.fc.call_action(SERVICE, actionname, **kwargs)
File "c:\python34\lib\site-packages\fritzconnection\fritzconnection.py", line 361, in call_action
action = self.services[service_name].actions[action_name]
KeyError: 'Hosts'

I would Attempt myself but don't have the knowledge to fix it unfortunately...

can you show me the line of your homeassistant.config file you use to set up the device scanner.

yep
`device_tracker:
platform: fritz
host: <IP_ADDRESS>
If new discovered devices are tracked by default (default: yes)
track_new_devices: yes
Seconds between each scan for new devices (default: 12)
interval_seconds: 12
Seconds to wait till marking someone as not home after not being seen
(default: 180)
consider_home: 180`

Okay I need to check this from home. I can tell you this evening. Did the intendations after the device_tracker:  got lost in copy paste or dont you need them?

yeah the indentations are there in the config file

okay, I think I found the issue. Its due to a missing password. So try adding the password of the fritzbox with:
device_tracker:
  - platform: fritz
    host: <IP_ADDRESS>
    password: password

After this the Key Error: Host was gone for me. Plz report if it helps.
PS:
I'm a bit confused by this error. I know it was possible to read the fritz_box.get_hosts_info() without a valid password. This might have changed from FritzOS 5 to 6.
So the import error at the beginning is because the pip version ist still not updated to contain the fix of this issue
It is likely that this will be changed in the future but I dont know when. In the mean time I think we should keep using my fork from here
The problem is, I dont know how to tell the new REQUIREMENTS variable to use the forked version.

Hi!
You can use a pip string like this, to install directly from github:
REQUIREMENTS = ['https://github.com/deisi/fritzconnection/archive/b5c14515e1c8e2652b06b6316a7f3913df942841.zip#fritzconnection==0.4.6']

The hash in the string is the hash of the commit you want to use. Notice the version spec at the end. You'll need to update the version of the package whenever you want homeassistant to use another commit or version, so that pip --upgrade will work.

Okay, I make a PR with it. Thanks for the information.

@deisi working fine now thanks

@deisi did you create a PR for your changes?

Hey year I did, but I dind't fill it in to the end. I redo it ASAP.
On 13.04.2016 12:05, Fabian Affolter wrote:

@deisi https://github.com/deisi did you create a PR for your changes?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/home-assistant/home-assistant/issues/1323#issuecomment-209350062

I was just curious because REQUIREMENTS = ['fritzconnection==0.4.6'] is still there.

Hi,
sorry that I have to pick this thread up again. I've checked and done everything described here (installed python3-lxm, installed fritzconnection manually, fixed the library) but on hass startup I still keep getting the following error:
16-11-09 23:17:37 homeassistant.bootstrap: Not initializing device_tracker.fritz because could not install dependency https://github.com/deisi/fritzconnection/archive/b5c14515e1c8e2652b06b6316a7f3913df942841.zip#fritzconnection==0.4.6
I'm running hass 0.32.2 installed on a pi2 using the Raspberry Pi All-In-One Installer.
Any ideas?

Hmmmm, why is ist not installing. Cant tell right away. I have to check.
On 09.11.2016 23:34, domlen wrote:

Hi,
sorry that I have to pick this thread up again. I've checked and done
everything described here (installed python3-lxm, installed
fritzconnection manually, fixed the library) but on hass startup I
still keep getting the following error:
|16-11-09 23:17:37 homeassistant.bootstrap: Not initializing
device_tracker.fritz because could not install dependency
https://github.com/deisi/fritzconnection/archive/b5c14515e1c8e2652b06b6316a7f3913df942841.zip#fritzconnection==0.4.6|
I'm running hass 0.32.2 installed on a pi2 using the Raspberry Pi
All-In-One Installer.
Any ideas?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/1323#issuecomment-259546441,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFL2NPoH700tVwaVOAGA-vG9W84fBlwCks5q8kplgaJpZM4HdbzY.

Hi, just wanted to double down on what @domlen reported. I'm getting the same error running hass on an Ubuntu server...
Also, as of mid-July the original repository is using Python3 imports, which as far as I can tell is the only reason for your fork, @deisi. Maybe it's time to point the component requirement back to the original repo?

Also, as of mid-July the original repository is using Python3 imports, which as far as I can tell is the only reason for your fork,

That is correct, but the pypy package is still old as far as I can see. We could try installing from the bitbucket repo but I don't know how this works  right away. I'm a bit busy though, if anybody could prepare a pull request, that would be nice. I don't know when I can do it.

@deisi, I contacted the maintainer of the repo on bitbucket, asking him to update the version of the package on PyPi. Hopefully he'll respond soon...
In the meantime, I tried a manual install of the package with
pip install 'https://bitbucket.org/kbr/fritzconnection/get/default.zip#egg=fritzconnection-0.5.1' and while the syntax worked to begin the installation from bitbucket (meaning it should also be acceptable for the requirements file), the installation itself ultimately failed with multiple errors relating to building lxml, which unfortunately I couldn't make sense of.
I then cloned the 0.5.1 version of the repo and ran its setup.py, which installed the package successfully. However, I still get the Not initializing device_tracker.fritz because could not install dependency https://github.com/deisi/fritzconnection/archive/b5c14515e1c8e2652b06b6316a7f3913df942841.zip#fritzconnection==0.4.6 error when I add fritz as a device tracker to my config.
What's totally confusing to me at the moment is that the line in the requirements file designating the deisi github repo as the source for fritzconnection req is commented out, so at the moment it's a mystery to me how the dep is being resolved and where the code needs to be changed.
Unfortunately my background is with JavaScript, node and npm; Python and pip are new to me. I'll keep exploring, however, and see if I can get to the bottom of this, but any help/advice is greatly appreciated.

Ah, the resolution of the requirement to the deisi repo is hardcoded in /components/device_tracker/fritz.py. Will inquire on gitter dev channel if this duplication is an anti-pattern...

Hi, I found this issue by chance but wanted to point out that fritzconnection has just been updated to 0.6 on PyPI: https://pypi.python.org/pypi/fritzconnection

Hi all,
I just did a fresh all-in-one installation of HA 0.38.2 on a new RPi3, copied my existing HA config and the only thing not working is the fritz device tracker. The error is very similar again:
17-02-13 22:43:46 ERROR (Thread-1) [homeassistant.bootstrap] Not initializing device_tracker.fritz because could not install dependency fritzconnection==0.6
Any ideas how to fix that?

Hi, just to be sure: did you first execute the steps described in the "warning" box on this page?

Hi, just to be sure: did you first execute the steps described in the "warning" box on this page?

D'Oh! How embarrassing... Totally forgot this one this time since I was so focused on migrating my existing config and setup. Works fine now....
Sorry for the confusion! Thanks for the hint @DavidMStraub!


Fix depreciation warnings on 0.4, windows compatible

Fix many depreciation warnings and also switch from using unix shell
commands to their julia versions.

Can you add a top-level REQUIRE file that says julia 0.4 ?

Done.  I'll also try to work out some tests to include in a future pull request.


jetty: 9.4.35.v20201120 -> 9.4.36.v20210114

Motivation for this change
fixes https://github.com/NixOS/nixpkgs/issues/102797
Things done

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

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

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

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 111410 run on x86_64-darwin 1

1 package built:

jetty


runtime_error

got this error running on AMD Radeon Pro 555
_Z5rsqrtd is called, but not defined
This is probalby a bug in Coriander. Please file an issue at https://github.com/hughperkins/coriander/issues/new
basicblockdumper.runGeneration got exception whilst processing:
  %97 = tail call double @_Z5rsqrtd(double %96) #5

generateOpenCL failed to generate opencl sourcecode
kernel name orig=_ZN5Eigen8internal15EigenMetaKernelINS_15TensorEvaluatorIKNS_14TensorAssignOpINS_9TensorMapINS_6TensorIfLi1ELi1EiEELi16ENS_11MakePointerEEEKNS_19TensorCwiseBinaryOpINS0_20scalar_difference_opIffEEKS8_KNS9_INS0_17scalar_product_opIffEEKNS9_INSD_IKfSF_EEKNS_20TensorBroadcastingOpIKNS_5arrayIiLm1EEEKNS_17TensorReshapingOpIKNS_5SizesIJLl1EEEEKNS4_INS_15TensorFixedSizeISF_NSM_IJEEELi1EiEELi16ES7_EEEEEEKNS4_INS5_ISF_Li1ELi1EiEELi16ES7_EEEEKNS_18TensorCwiseUnaryOpINS0_15scalar_rsqrt_opIfEESC_EEEEEEEENS_9GpuDeviceEEEiEEvT_T0_
kernel name short=_ZN5Eigen8internal15
kernel name unique=_ZN5Eigen8internal15EigenMetaKernelINS_15TensorEvaluatorIKNS_14TensorAssignOpINS_9TensorMapINS_6TensorIfLi1ELi1EiEELi16ENS_11MakePointerEEEKNS_19TensorCwiseBinaryOpINS0_20scalar_difference_opIffEEKS8_KNS9_INS0_17scalar_product_opIffEEKNS9_INSD_IKfSF_EEKNS_20TensorBroadcastingOpIKNS_5arrayIiLm1EEEKNS_17TensorReshapingOpIKNS_5SizesIJLl1EEEEKNS4_INS_15TensorFixedSizeISF_NSM_IJEEELi1EiEELi16ES7_EEEEEEKNS4_INS5_ISF_Li1ELi1EiEELi16ES7_EEEEKNS_18TensorCwiseUnaryOpINS0_15scalar_rsqrt_opIfEESC_EEEEEEEENS_9GpuDeviceEEEiEEvT_T0__1_2_2_2_2_2
writing ll to /tmp/failed-kernel.ll
caught runtime error _Z5rsqrtd is called, but not defined => cannot continue.  Sorry :-(
libc++abi.dylib: terminating with uncaught exception of type std::runtime_error
Abort trap: 6

Well... what it probably means is, you're using doubles, instead of floats. If thats the case, you're probably going to run up against a ton of never-ending problems, one behind the other. So, in that case, you'd probably want to switch to use floats instead.
If you're already using floats, please add a line to this file https://github.com/hughperkins/coriander/blob/master/src/function_names_map.cpp#L25, like:
    knownFunctionsMap["_Z5rsqrtd"] = ... hmmm... oh... *r* sqrt, ok that wont work :P

Hmmm
What happens if you remove this line:  https://github.com/hughperkins/coriander/blob/master/include/cocl/fake_funcs.h#L139
__device__ double rsqrt(double x);

... since rsqrt is in theory in OpenCL 1.2 anyway: https://www.khronos.org/registry/OpenCL/specs/opencl-1.2.pdf

oh wait .. :-P :-D
Ok, so:

rsqrt is in opencl 1.2 anyway, so dont change the includes, leave the include as it is
having the rsqrt in the includes means it'll get all the way through the clang parsing step, and then as far as the opencl generation step, which is a good thing
in the opencl generation step, the rsqrt will have 'magically' become _Z5rsqtd, for whatever reason (probably being called from C++ code, etc)
and therefore, the correct fix should, I think be, as I nearly wrote, right at the start:
in https://github.com/hughperkins/coriander/blob/master/src/function_names_map.cpp#L25, add a line:

    knownFunctionsMap["_Z5rsqrtd"] = "rsqrt";

this will write out the _Z5rsqrtd function as the opencl function rsqrt, which should in theory exist, and therefore work. hopefully :-)


Don't make ResourceDictionary inherit from AvaloniaDictionary

What does the pull request do?
ResourceDictionary inheriting from AvaloniaDictionary is going to be problematic in future when we want to add deferred/lazy loading of resources as we will need to transform the contents of the dictionary on read.
Remove the inheritance and use a simple inner Dictionary<object, object?> to store the values.
Breaking Changes
ResourceDictionary no longer implements INotifyCollectionChanged but hopefully this won't be so much as a problem because INCC is very problematic anyway with dictionaries (as INCC is index-based).

You can test this PR using the following package version. 0.10.999-cibuild0021483-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]


Support redirection to a specific page

Support redirection to a specific page after successful authentication. For example, if the user requested Update Campaigns page in the url, instead of going to Devices page after authentication, go to Update Campaigns.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>7
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls


xf_floatbar use XmbDrawString instead of XDrawString

#7392
This commit enable Chinese character as title.

@freerdp-bot

@freerdp-bot test

@amazingfate pleaes use clang-format to apply correct formatting to your PR

@amazingfate sorry to be picky but please squash the changes into 1 commit (so we don't pollute the history for formatting commits) - thanks!


poisson_log cdfs

From @bob-carpenter on April 29, 2015 13:47
Requested by Henrik Mannerström on stan-users:
Add:

[ ] poisson_log_cdf
[ ] poisson_log_cdf_log
[ ] poisson_log_ccdf_log

And then we can do truncations.
Copied from original issue: stan-dev/stan#1432

From @bob-carpenter on April 29, 2015 14:18
Even if there's no computational benefit, it's conceptually
cleaner to have them match, and it also allows people to
write truncated models, as in:
y ~ poisson_log(alpha) T[3,];
So even a simple implementation in terms of just exp()
transforming the alpha argument would be worth adding for
convenience.

Bob

On Apr 30, 2015, at 12:06 AM, Michael Betancourt<EMAIL_ADDRESS>wrote:
There’s no computational benefit to having inputs
on the log scale for the CDFs as they’re typically
given by transcendental functions and not amenable
to the analytic simplifications the PDFs are.
On Apr 29, 2015, at 2:47 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

Add:
poisson_log_cdf
poisson_log_cdf_log
poisson_log_ccdf_log
And then we can do truncations.
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

From @betanalpha on April 29, 2015 14:6
There’s no computational benefit to having inputs
on the log scale for the CDFs as they’re typically
given by transcendental functions and not amenable
to the analytic simplifications the PDFs are.
On Apr 29, 2015, at 2:47 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

Add:
poisson_log_cdf
poisson_log_cdf_log
poisson_log_ccdf_log
And then we can do truncations.
—
Reply to this email directly or view it on GitHub.

Question: in the stan manual at E.6 it says we're moving from say, poisson_cdf_log to poisson_lcdf etc.
It seems like this happened in the stan language as of 2.10 but not at all in the math library. Advice on how to proceed?

The library should continue with the _log convention, then
we'll change them all in one big pull request.  The code
generator isn't set up to understand built in _lpdfs yet.

Bob

On Oct 12, 2016, at 3:46 PM, thelseraphim<EMAIL_ADDRESS>wrote:
Question: in the stan manual at E.6 it says we're moving from say, poisson_cdf_log to poisson_lcdf etc.
It seems like this happened in the stan language as of 2.10 but not at all in the math library. Advice on how to proceed?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or mute the thread.


can you add altitude to kalman filter?

Hello!
I have rocket model with gps and use your module with kalman filter but it does not use altitude\height. Can you add altitude to filter too?
Thanks

Hmm, yes that would be no problem to add, but I wonder what the practical benefit is. The altitude of GPS is by nature very inaccurate and would need to be fused with an external sensor, like an air-pressure sensor (BMP180 or the like), especially for a model rocket, where the altitude is crucial. So I think deriving the KF for your special use case would be of more value. If you need help with the math, I can help on that.


the performance of different backbones

The official code uses the Alextnet as the backbone. Do you use the other backbone to evaluate the performance?

官方代码使用 Alextnet 作为主干。您是否使用另一个主干来评估性能？
I tried to replace it with another backbone, but without weights, the training time was very long.


! compiler-explorer The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

Hello, since compiler-explorer is written on ts i'm trying to run in on macbook m1 pro
Could you please advice what could go wrong?
gcc-arm64/aarch64 exists. So...?
% git clone https://github.com/madduci/docker-compiler-explorer
Cloning into 'docker-compiler-explorer'...
remote: Enumerating objects: 105, done.
remote: Counting objects: 100% (52/52), done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 105 (delta 31), reused 23 (delta 20), pack-reused 53
Receiving objects: 100% (105/105), 18.98 KiB | 4.75 MiB/s, done.
Resolving deltas: 100% (51/51), done.
% cd docker-compiler-explorer
% ls
Dockerfile		LICENSE			README.md		cpp.properties		docker-compose.yml
% docker-compose up -d
[+] Running 0/1
⠏ compiler-explorer Pulling                                                                                2.8s
[+] Building 972.3s (5/8)
[+] Building 973.8s (5/8)
[+] Building 1039.8s (9/9) FINISHED
=> [internal] load .dockerignore                                                                                0.0s
=> => transferring context: 2B                                                                                0.0s
=> [internal] load build definition from Dockerfile                                                                                0.0s
=> => transferring dockerfile: 986B                                                                                0.0s
=> [internal] load metadata for docker.io/madduci/docker-linux-cpp:latest                                                                                3.4s
=> [1/4] FROM docker.io/madduci/docker-linux-cpp:latest@sha256:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7                                                                               229.4s
=> => resolve docker.io/madduci/docker-linux-cpp:latest@sha256:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7                                                                                0.0s
=> => sha256:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7 1.37kB / 1.37kB                                                                                0.0s
=> => sha256:f026f1c8af76b78ee1278dbe5ac2d3e5ffd7586fe7e84b21e79fff00bb3b92fb 3.22kB / 3.22kB                                                                                0.0s
=> => sha256:675920708c8bf10fbd02693dc8f43ee7dbe0a99cdfd55e06e6f1a8b43fd08e3f 28.57MB / 28.57MB                                                                                6.4s
=> => sha256:74704bd53b1936f5065728c754be98b286e7bc55c848129aeca1cc2590f576a8 103B / 103B                                                                                1.2s
=> => sha256:bba5f99a361177ea5af75f5f0d2b5ea62bda7b93f3cb8dcc616a354b940b1327 76.14MB / 76.14MB                                                                                58.4s
=> => sha256:27885923d3c9487aaaf1ed41ecc3f27afb55763c4affbfa0fbc7617a6230536c 419B / 419B                                                                                2.1s
=> => sha256:8c90143907eb36c43b1ccd9ce439732e6b9bd6088b33210f15e08c32c3323481 844.72MB / 844.72MB                                                                                217.6s
=> => extracting sha256:675920708c8bf10fbd02693dc8f43ee7dbe0a99cdfd55e06e6f1a8b43fd08e3f                                                                                0.8s
=> => extracting sha256:74704bd53b1936f5065728c754be98b286e7bc55c848129aeca1cc2590f576a8                                                                                0.0s
=> => extracting sha256:bba5f99a361177ea5af75f5f0d2b5ea62bda7b93f3cb8dcc616a354b940b1327                                                                                0.9s
=> => extracting sha256:27885923d3c9487aaaf1ed41ecc3f27afb55763c4affbfa0fbc7617a6230536c                                                                                0.0s
=> => extracting sha256:8c90143907eb36c43b1ccd9ce439732e6b9bd6088b33210f15e08c32c3323481                                                                                11.5s
=> [internal] load build context                                                                                0.0s
=> => transferring context: 1.86kB                                                                                0.0s
=> [2/4] RUN echo "*** Installing Compiler Explorer ***"     && DEBIAN_FRONTEND=noninteractive apt-get update     && apt-get install -y curl     && curl -sL https://deb.nodesource.com/setup_18.x | bash -   796.2s
=> [3/4] ADD cpp.properties /compiler-explorer/etc/config/c++.local.properties                                                                                0.0s
=> [4/4] WORKDIR /compiler-explorer                                                                                0.0s
=> exporting to image                                                                                10.6s
=> => exporting layers                                                                                10.6s
=> => writing image sha256:f5ac0b3c11ff83544ae9d43323f65e96c8f965583bc868bcb94ccee26752729c                                                                                0.0s
=> => naming to docker.io/madduci/docker-compiler-explorer:latest                                                                                0.0s
[+] Running 3/3
✔ Network docker-compiler-explorer_ce_network                                                                                Created                                      0.0s
✔ Container compiler-explorer                                                                                Started                                      0.4s
! compiler-explorer The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

Hi
The problem is that the base image is built only for amd64. I've never
thought that arm64/V8 was a thing and I'm not sure if Compiler Explorer
itself can work on Arm.
This requires some spare time and build the first image with the required
compilers and then this one, both with target Arm64.
Il sab 6 mag 2023, 11:00 Man on the moon @.***> ha
scritto:

% git clone https://github.com/madduci/docker-compiler-explorer
Cloning into 'docker-compiler-explorer'...
remote: Enumerating objects: 105, done.
remote: Counting objects: 100% (52/52), done.
remote: Compressing objects: 100% (30/30), done.
remote: Total 105 (delta 31), reused 23 (delta 20), pack-reused 53
Receiving objects: 100% (105/105), 18.98 KiB | 4.75 MiB/s, done.
Resolving deltas: 100% (51/51), done.
% cd docker-compiler-explorer
% ls
Dockerfile LICENSE README.md cpp.properties docker-compose.yml
% docker-compose up -d
[+] Running 0/1
⠏ compiler-explorer Pulling 2.8s
[+] Building 972.3s (5/8)
[+] Building 973.8s (5/8)
[+] Building 1039.8s (9/9) FINISHED
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 986B 0.0s
=> [internal] load metadata for docker.io/madduci/docker-linux-cpp:latest
3.4s
=> [1/4] FROM
@.:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7
229.4s
=> => resolve
@.:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7
0.0s
=> =>
sha256:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7
1.37kB / 1.37kB 0.0s
=> =>
sha256:f026f1c8af76b78ee1278dbe5ac2d3e5ffd7586fe7e84b21e79fff00bb3b92fb
3.22kB / 3.22kB 0.0s
=> =>
sha256:675920708c8bf10fbd02693dc8f43ee7dbe0a99cdfd55e06e6f1a8b43fd08e3f
28.57MB / 28.57MB 6.4s
=> =>
sha256:74704bd53b1936f5065728c754be98b286e7bc55c848129aeca1cc2590f576a8
103B / 103B 1.2s
=> =>
sha256:bba5f99a361177ea5af75f5f0d2b5ea62bda7b93f3cb8dcc616a354b940b1327
76.14MB / 76.14MB 58.4s
=> =>
sha256:27885923d3c9487aaaf1ed41ecc3f27afb55763c4affbfa0fbc7617a6230536c
419B / 419B 2.1s
=> =>
sha256:8c90143907eb36c43b1ccd9ce439732e6b9bd6088b33210f15e08c32c3323481
844.72MB / 844.72MB 217.6s
=> => extracting
sha256:675920708c8bf10fbd02693dc8f43ee7dbe0a99cdfd55e06e6f1a8b43fd08e3f 0.8s
=> => extracting
sha256:74704bd53b1936f5065728c754be98b286e7bc55c848129aeca1cc2590f576a8 0.0s
=> => extracting
sha256:bba5f99a361177ea5af75f5f0d2b5ea62bda7b93f3cb8dcc616a354b940b1327 0.9s
=> => extracting
sha256:27885923d3c9487aaaf1ed41ecc3f27afb55763c4affbfa0fbc7617a6230536c 0.0s
=> => extracting
sha256:8c90143907eb36c43b1ccd9ce439732e6b9bd6088b33210f15e08c32c3323481
11.5s
=> [internal] load build context 0.0s
=> => transferring context: 1.86kB 0.0s
=> [2/4] RUN echo "*** Installing Compiler Explorer ***" &&
DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y curl &&
curl -sL https://deb.nodesource.com/setup_18.x | bash - 796.2s
=> [3/4] ADD cpp.properties
/compiler-explorer/etc/config/c++.local.properties 0.0s
=> [4/4] WORKDIR /compiler-explorer 0.0s
=> exporting to image 10.6s
=> => exporting layers 10.6s
=> => writing image
sha256:f5ac0b3c11ff83544ae9d43323f65e96c8f965583bc868bcb94ccee26752729c 0.0s
=> => naming to docker.io/madduci/docker-compiler-explorer:latest 0.0s
[+] Running 3/3
✔ Network docker-compiler-explorer_ce_network Created 0.0s
✔ Container compiler-explorer Started 0.4s
! compiler-explorer The requested image's platform (linux/amd64) does not
match the detected host platform (linux/arm64/v8) and no specific platform
was requested
—
Reply to this email directly, view it on GitHub
https://github.com/madduci/docker-compiler-explorer/issues/11, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAC2SYSC4ZZK4Y3ZBMKGY53XEYHMLANCNFSM6AAAAAAXX7GNTE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi @madduci,
I'd like to help cause i have some spare time,
could you please clarify what image are you speaking about and point the place in documentations i have to start/try with?

Hi The problem is that the base image is built only for amd64. I've never thought that arm64/V8 was a thing and I'm not sure if Compiler Explorer itself can work on Arm. This requires some spare time and build the first image with the required compilers and then this one, both with target Arm64. Il sab 6 mag 2023, 11:00 Man on the moon @.> ha scritto:
…
% git clone https://github.com/madduci/docker-compiler-explorer Cloning into 'docker-compiler-explorer'... remote: Enumerating objects: 105, done. remote: Counting objects: 100% (52/52), done. remote: Compressing objects: 100% (30/30), done. remote: Total 105 (delta 31), reused 23 (delta 20), pack-reused 53 Receiving objects: 100% (105/105), 18.98 KiB | 4.75 MiB/s, done. Resolving deltas: 100% (51/51), done. % cd docker-compiler-explorer % ls Dockerfile LICENSE README.md cpp.properties docker-compose.yml % docker-compose up -d [+] Running 0/1 ⠏ compiler-explorer Pulling 2.8s [+] Building 972.3s (5/8) [+] Building 973.8s (5/8) [+] Building 1039.8s (9/9) FINISHED => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 986B 0.0s => [internal] load metadata for docker.io/madduci/docker-linux-cpp:latest 3.4s => [1/4] FROM @.:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7 229.4s => => resolve @.:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7 0.0s => => sha256:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7 1.37kB / 1.37kB 0.0s => => sha256:f026f1c8af76b78ee1278dbe5ac2d3e5ffd7586fe7e84b21e79fff00bb3b92fb 3.22kB / 3.22kB 0.0s => => sha256:675920708c8bf10fbd02693dc8f43ee7dbe0a99cdfd55e06e6f1a8b43fd08e3f 28.57MB / 28.57MB 6.4s => => sha256:74704bd53b1936f5065728c754be98b286e7bc55c848129aeca1cc2590f576a8 103B / 103B 1.2s => => sha256:bba5f99a361177ea5af75f5f0d2b5ea62bda7b93f3cb8dcc616a354b940b1327 76.14MB / 76.14MB 58.4s => => sha256:27885923d3c9487aaaf1ed41ecc3f27afb55763c4affbfa0fbc7617a6230536c 419B / 419B 2.1s => => sha256:8c90143907eb36c43b1ccd9ce439732e6b9bd6088b33210f15e08c32c3323481 844.72MB / 844.72MB 217.6s => => extracting sha256:675920708c8bf10fbd02693dc8f43ee7dbe0a99cdfd55e06e6f1a8b43fd08e3f 0.8s => => extracting sha256:74704bd53b1936f5065728c754be98b286e7bc55c848129aeca1cc2590f576a8 0.0s => => extracting sha256:bba5f99a361177ea5af75f5f0d2b5ea62bda7b93f3cb8dcc616a354b940b1327 0.9s => => extracting sha256:27885923d3c9487aaaf1ed41ecc3f27afb55763c4affbfa0fbc7617a6230536c 0.0s => => extracting sha256:8c90143907eb36c43b1ccd9ce439732e6b9bd6088b33210f15e08c32c3323481 11.5s => [internal] load build context 0.0s => => transferring context: 1.86kB 0.0s => [2/4] RUN echo " Installing Compiler Explorer " && DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y curl && curl -sL https://deb.nodesource.com/setup_18.x | bash - 796.2s => [3/4] ADD cpp.properties /compiler-explorer/etc/config/c++.local.properties 0.0s => [4/4] WORKDIR /compiler-explorer 0.0s => exporting to image 10.6s => => exporting layers 10.6s => => writing image sha256:f5ac0b3c11ff83544ae9d43323f65e96c8f965583bc868bcb94ccee26752729c 0.0s => => naming to docker.io/madduci/docker-compiler-explorer:latest 0.0s [+] Running 3/3 ✔ Network docker-compiler-explorer_ce_network Created 0.0s ✔ Container compiler-explorer Started 0.4s ! compiler-explorer The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested — Reply to this email directly, view it on GitHub <#11>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC2SYSC4ZZK4Y3ZBMKGY53XEYHMLANCNFSM6AAAAAAXX7GNTE . You are receiving this because you are subscribed to this thread.Message ID: @.>

Hello

Thanks for helping.
I'm referring to this image indeed:
https://github.com/madduci/docker-compiler-explorer/blob/57b29d416dbadef37d8fbb9b8e376516ebb0bc74/Dockerfile#L1
Which is built from this project automatically:
https://github.com/madduci/docker-linux-cpp
For the sake of easiness, you might want to build a multi-stage Dockerfile,
combining everything together.
I hope it helps. Best regards
Il sab 6 mag 2023, 12:47 Man on the moon @.***> ha
scritto:

Hi @madduci https://github.com/madduci,
I'd like to help cause i have some spare time,
could you please clarify what image are you speaking about and point the
place in documentations i have to start/try with?
Hi The problem is that the base image is built only for amd64. I've never
thought that arm64/V8 was a thing and I'm not sure if Compiler Explorer
itself can work on Arm. This requires some spare time and build the first
image with the required compilers and then this one, both with target
Arm64. Il sab 6 mag 2023, 11:00 Man on the moon @.
> ha scritto: … <#m_8270489851475683338_m_-9121309893676544472_> % git
clone https://github.com/madduci/docker-compiler-explorer
https://github.com/madduci/docker-compiler-explorer Cloning into
'docker-compiler-explorer'... remote: Enumerating objects: 105, done.
remote: Counting objects: 100% (52/52), done. remote: Compressing objects:
100% (30/30), done. remote: Total 105 (delta 31), reused 23 (delta 20),
pack-reused 53 Receiving objects: 100% (105/105), 18.98 KiB | 4.75 MiB/s,
done. Resolving deltas: 100% (51/51), done. % cd docker-compiler-explorer %
ls Dockerfile LICENSE README.md cpp.properties docker-compose.yml %
docker-compose up -d [+] Running 0/1 ⠏ compiler-explorer Pulling 2.8s [+]
Building 972.3s (5/8) [+] Building 973.8s (5/8) [+] Building 1039.8s (9/9)
FINISHED => [internal] load .dockerignore 0.0s => => transferring context:
2B 0.0s => [internal] load build definition from Dockerfile 0.0s => =>
transferring dockerfile: 986B 0.0s => [internal] load metadata for
docker.io/madduci/docker-linux-cpp:latest
http://docker.io/madduci/docker-linux-cpp:latest 3.4s => [1/4] FROM @.:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7
229.4s => => resolve @.:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7
0.0s => =>
sha256:4fa8a2bdfd4ace72ecf7c0733211ce327917d9dfc3b068adb4368e04cc1745c7
1.37kB / 1.37kB 0.0s => =>
sha256:f026f1c8af76b78ee1278dbe5ac2d3e5ffd7586fe7e84b21e79fff00bb3b92fb
3.22kB / 3.22kB 0.0s => =>
sha256:675920708c8bf10fbd02693dc8f43ee7dbe0a99cdfd55e06e6f1a8b43fd08e3f
28.57MB / 28.57MB 6.4s => =>
sha256:74704bd53b1936f5065728c754be98b286e7bc55c848129aeca1cc2590f576a8
103B / 103B 1.2s => =>
sha256:bba5f99a361177ea5af75f5f0d2b5ea62bda7b93f3cb8dcc616a354b940b1327
76.14MB / 76.14MB 58.4s => =>
sha256:27885923d3c9487aaaf1ed41ecc3f27afb55763c4affbfa0fbc7617a6230536c
419B / 419B 2.1s => =>
sha256:8c90143907eb36c43b1ccd9ce439732e6b9bd6088b33210f15e08c32c3323481
844.72MB / 844.72MB 217.6s => => extracting
sha256:675920708c8bf10fbd02693dc8f43ee7dbe0a99cdfd55e06e6f1a8b43fd08e3f
0.8s => => extracting
sha256:74704bd53b1936f5065728c754be98b286e7bc55c848129aeca1cc2590f576a8
0.0s => => extracting
sha256:bba5f99a361177ea5af75f5f0d2b5ea62bda7b93f3cb8dcc616a354b940b1327
0.9s => => extracting
sha256:27885923d3c9487aaaf1ed41ecc3f27afb55763c4affbfa0fbc7617a6230536c
0.0s => => extracting
sha256:8c90143907eb36c43b1ccd9ce439732e6b9bd6088b33210f15e08c32c3323481
11.5s => [internal] load build context 0.0s => => transferring context:
1.86kB 0.0s => [2/4] RUN echo " Installing Compiler Explorer " &&
DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y curl &&
curl -sL https://deb.nodesource.com/setup_18.x
https://deb.nodesource.com/setup_18.x | bash - 796.2s => [3/4] ADD
cpp.properties /compiler-explorer/etc/config/c++.local.properties 0.0s =>
[4/4] WORKDIR /compiler-explorer 0.0s => exporting to image 10.6s => =>
exporting layers 10.6s => => writing image
sha256:f5ac0b3c11ff83544ae9d43323f65e96c8f965583bc868bcb94ccee26752729c
0.0s => => naming to docker.io/madduci/docker-compiler-explorer:latest
http://docker.io/madduci/docker-compiler-explorer:latest 0.0s [+] Running
3/3 ✔ Network docker-compiler-explorer_ce_network Created 0.0s ✔ Container
compiler-explorer Started 0.4s ! compiler-explorer The requested image's
platform (linux/amd64) does not match the detected host platform
(linux/arm64/v8) and no specific platform was requested — Reply to this
email directly, view it on GitHub <#11
https://github.com/madduci/docker-compiler-explorer/issues/11>, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAC2SYSC4ZZK4Y3ZBMKGY53XEYHMLANCNFSM6AAAAAAXX7GNTE
https://github.com/notifications/unsubscribe-auth/AAC2SYSC4ZZK4Y3ZBMKGY53XEYHMLANCNFSM6AAAAAAXX7GNTE
. You are receiving this because you are subscribed to this thread.Message
ID: @.>
Hello
—
Reply to this email directly, view it on GitHub
https://github.com/madduci/docker-compiler-explorer/issues/11#issuecomment-1537114534,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAC2SYTWF77SRK2WM7WRE7LXEYT4ZANCNFSM6AAAAAAXX7GNTE
.
You are receiving this because you were mentioned.Message ID:
@.***>


When ever I run the ShaderConverter.sh Script it deleted all the strings.

Hi is the script working still? When ever I run it, it makes the entire file empty.

I'm having the same issue. did you resolve ?

ahhh..
because we are typing in terminal:
./ShaderConverter.sh
instead of
./ShaderConverter.sh *


test_periodogram::test_assign_periods() causes sqrt errors

Problem description
test_assign_periods(), in its call to lc.to_periodogram(frequency=frequency), fails to pass the freq_units.  I was able to stop the sqrt() errors and allow the test to proceed as intended by supplying matching units:
frequency = np.arange(1, 100) * u.Hz
p = lc.to_periodogram(frequency=frequency, freq_unit=u.Hz)

Environment

platform: Xubuntu 18.04.3
lightkurve version: downloaded from github today
installation method: downloaded from github today

Comments
I would suggest that from_lightcurve() in both BoxLeastSquaresPeriodogram and LombScarglePeriodogram (periodogram.py) protect themselves from erroneous frequency input by requiring freq_unit be specified when frequency is specified.

The docstring for from_lightcurve states the defaults for frequency units, which depends on the normalization:

   frequency :  array-like

        The regular grid of frequencies to use. If given a unit, it is
        converted to units of freq_unit. If not, it is assumed to be in
        units of freq_unit. This over rides any set frequency limits.

     freq_unit : `astropy.units.core.CompositeUnit`

        Default: None. The desired frequency units for the Lomb Scargle
        periodogram. This implies that 1/freq_unit is the units for period.
        With default normalization ('amplitude'), the freq_unit is set to
        1/day, which can be overridden. 'psd' normalization will set
        freq_unit to microhertz.

The context-dependent units is a bit funky, but was designed to satisfy the disparate conventions in different astronomical subfields.  We may be revisiting the units as part of discussion of #570.
For the purposes of suppressing a warning, it's fine to explicitly add freq_units, as long as the test coverage remains undiminished.

By the way, a related problem is that in Jupyter notebooks (and maybe most editors?), one cannot easily view the informative docstring from the convenience functions, so I worry that a lot of these valuable from_lightcurve docstrings are missed by typical users that use to_periodogram.

I understand the defaults.  The goal is not just to suppress a warning; if the frequency units are not consistent with the frequency value, then the test result is invalid.
I believe that the above code change allows the test to complete as intended.


Create coloradocollege.edu

I don't know if I have tried to get  /edu/coloradocollege.txt done correctly this time.  I hope so.

@veirs No, you did not create a necessary file. However I just created necessary file for you manually. I close the request.
Please start requesting the licenses in about an hour, to let the changes to propagate through our system. Thank you.


Feature Request: Customizable Dashboard

Add ability to customize the dashboard to add/remove specific information. Older children wouldn't need tummy time tracking for instance.

Missed that this issue already exists basically on my initial skim of issues.


Add a page for Prometheus metrics

Signed-off-by: Ben Clapp<EMAIL_ADDRESS>As suggested here, easier for project if we host the cert-manager-mixin in a different repo, and can reference it from the docs.
Have also added some high level docs around the Prometheus metrics exposed by cert-manager.

Looks good!
/ok-to-test
/lgtm
/approve

/lgtm


Add Repr trait

This PR adds the Repr trait that was mentionned in this comment.
Description
The Repr trait is currently implemented for i64, f64, Str and Symbol.
It is used when:

Converting a float to a string using str(f),
Displaying an integer, a float, a string or a symbol.

Open questions

Should Repr be implemented for more types?
Should Repr::repr be used in other places?

The idea was to have this function backed by the new Repr trait instead of Debug:
https://github.com/typst/typst/blob/0198429e63d288b992624b0fb615fc5af5aa6cb6/crates/typst/src/eval/value.rs#L190-L193
For that to work, Value would need to implement Repr, all of its variants would need to implement Repr and Dynamic would need to be bounded on Repr instead of (or in addition to) Debug. That's quite a bit of work, hence my comment that it might be too complicated for the other PR to incorporate.
Fundamentally, Repr should define the output of the repr(..) function in Typst. Right now, it's all shoe-horned into the Debug impls, which makes them strange from a Rust-facing perspective. Basically: Value::display / Show is the equivalent to Display and Value::repr / Repr is the equivalent to Debug.
This means that for Str it should render quotes and the escape sequences the Typst supports for strings, for arrays the adequate array literal, etc. In particular, this means that Value::display for Value::Str shouldn't use repr because it should not add quotes or add escape sequences.
PS: There are quite a few private struct Repr in the codebase as you have seen with Symbol. That's a bit of an unfortunate collision, but I would prefer for them to keep their name. The Repr impl can still be added with impl crate::eval::Repr for ...

Oh, right. I indeed misunderstood what the purpose of this trait was.
After working on it, I can confirm that it makes perfect sense to have this in a separate PR.
I've modified the original comment to describe the new changes.

Looks good overall! The main comment I have is that now that we have Repr, a lot of previous Debug impls could be turned into derives or some stuff like Array could use Rust's typical f.debug_list() thing. That way, Repr returns the Typst-like representation and Debug the Rust-like one and we have less duplication.

I have removed custom Debug implementations and replaced them with #[derive(Debug)] when appropriate.

Thanks a lot for taking care of this!


libnetwork really really really slow on startup in some cases

When starting up docker, if --cluster-store is set to an IP address that belongs to a container, and that container is not using --net=host, initializing libnetwork takes a VERY VERY (VERY x10) long time.
Example:
$ docker daemon -D
...
$ docker network create --subnet <IP_ADDRESS>/24 test
$ docker run -d --name etcd --ip <IP_ADDRESS> --restart=always quay.io/coreos/etcd --listen-client-urls http://<IP_ADDRESS>:2379 --advertise-client-urls http://<IP_ADDRESS>:2379
$ kill $(pidof dockerd)
$ docker daemon -D --cluster-advertise <IP_ADDRESS>:2375 --cluster-store etcd://<IP_ADDRESS>:2379

The last line takes a couple of minutes.
Meanwhile if I use --net=host and <IP_ADDRESS> for the etcd url it's as fast as it normally is.

@cpuguy83 I think we should document this scenario and recommend not to use such configurations.
That is especially true because, one should NOT assume direct container reachability through its ip-address from the host networking stack. It will vary between network drivers. For example, host cannot reach the containers running in networks created using Overlay or Vlan drivers.
Can you please confirm if the bootup time improves if the kv container is run with port-mapping and the --cluster-advertise is configured to access the localhost or via host-ip (and mapped-port) ?

@cpuguy83 It has been detected that this issue has not received any activity in over 6 months. Can you please let us know if it is still relevant:

For a bug: do you still experience the issue with the latest version?
For a feature request: was your request appropriately answered in a later version?

Thank you!
This issue will be automatically closed in 1 week unless it is commented on.
For more information please refer to https://github.com/docker/libnetwork/issues/1926

I think we can close this. WHile it is a problem, it is marginalized by swarm-mode.


Removing retired Security Hub controls tse cccs

*Issue #317 *
Description of changes:
AWS Security Hub retired controls Lambda.4 and PCI.EC2.3. Removing them from the CCCS and TSE sample configs. See https://docs.aws.amazon.com/securityhub/latest/userguide/doc-history.html
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hi @ColinL2021 , thank you for your contribution to the LZA and your patience. Since this PR was opened, the CCCS and TSE sample configurations have been moved to their own respective repositories:

https://github.com/aws-samples/landing-zone-accelerator-on-aws-for-cccs-medium
https://github.com/aws-samples/landing-zone-accelerator-on-aws-for-tse-se

Since this repository no longer has ownership of those configurations, I'll be closing this PR. Please feel free to reopen this PR against those two sample configuration repositories.


Fixed sandbag barricades being repairable

About the PR

See title.
Why / Balance

Fixes #2898
Technical details

Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

:cl:

fix: Fixed sandbag barricades being repairable with a welder.


renderer to dom, draw features and GeoJson example broken on mobile

i tested two mobile deivce
samsung S3 (android 4.1.2) => devicePixelRatio 1.3
HTC ONE M7 (android 4.4.4) => devicePixelRatio 1.5
http://openlayers.org/en/v3.1.1/examples/draw-features.html?renderer=dom

fiddle.jshell.net/67rrb6ge/show/

Thanks @ChouGary for reporting this. See #3117 for a fix.


Tiles not loading on Android Emulator

This issue has already been reported, but closed here: https://github.com/openlayers/openlayers/issues/6500
without being resolved.
Across Openlayers versions (including the latest), android devices and android os versions, Openlayer Maps do not load tiles on Android Emulators in Android Studio (both 2.3.3 and 3).
This does however only occur on Windows machines.
There is no error output, neither on the android-, nor the remote chrome console. I guess this may not be an Openlayers, but an emulator-bug, but I felt it was worth mentioning.
Again, the issue only occurs on emulated Android devices on Windows, it works fine on real devices and Mac- and Linux machines.

Cheers, David

Do you have any error reported ?

Yes, sorry, I just spotted them now in Logcat:
5638-5704/com.example.me.myapplication E/eglCodecCommon: glUtilsParamSize: unknow param 0x000088ff
6124-6199/com.example.me.myapplication E/EGL_emulation: tid 6199: eglChooseConfig(840): error 0x3004 (EGL_BAD_ATTRIBUTE)
6124-6199/com.example.me.myapplication E/chromium: [ERROR:gl_surface_egl.cc(289)] eglChooseConfig failed with error EGL_BAD_ATTRIBUTE
6124-6199/com.example.me.myapplication E/chromium: [ERROR:gl_surface_egl.cc(441)] No suitable EGL configs found.
There are no errors in the chrome console though and I can even see that the tiles are being served - they can be displayed in the network-preview tab.

So the last three errors also occur on a mac (where the tiles are showing).
The first seems to be due to the host gpu and is supposed to be fixable by disabling the emulated device from using the host gpu.
I disabled it, but am still getting it afterwards.
But I don't think it's related.

I had the same problem on my emulator (API 25). Adjusting the settings for OpenGL solved the problem.

@williwasser thanks for the information

closing

Changing my OpenGL settings does not solve this issue for me.


Blackbox IO doesn't actually "exist"

Related: #249 and #282.
The root cause of both issues is that the BlackBox IO object itself doesn't actually get emitted as FIRRTL, only its children are. So operations on that IO object would become invalid if emitted to FIRRTL, and any properties of it (like flipped-ness) are dropped.
The second is possible to fix by special-case logic in the emitter, and the first is (probably?) already worked around by resolving bulk-connects at the Element (leaf) level in Chisel. But the underlying issue is still there, and if we ever start emitting bulk connects again it will break.
Potential solutions:

More and more special casing. Very ugly, high likelihood of missed edge cases and bugs.
Deprecate the "legacy" BlackBox interface in favor of ExtModule, which supports multiple top-level IO objects and doesn't do this special IO unwrapping. Possibly also introduce an "all IOs" function that returns all the top-level IOs as a record or record-act-alike object. Side note: this may be of interest to MultiIoModule users?
Have the top-level BlackBox IO be dummy object that emits connects and stuff at its immediate children level, instead of being an actual object in the hardware graph. Unclear if this can work without requiring changes to user BlackBox code, since the IO Bundle would no longer be a Bundle.
Something else?

Resolution: fix #282 with a hack-patch and figure out a long term solution later (either more hack-patching for #249, when chisel3 starts emitting bulk connects again, or pushing towards ExtModule)

I believe I am hitting against this issue.
I am trying to create a LazyModuleBlackBox, and the existing LazyModuleImps extend Modules that have ios. However, if I attempt to make a LazyBlackBoxModuleImp I get an error that there is no io and thus my class must be abstract.
https://github.com/freechipsproject/rocket-chip/blob/master/src/main/scala/diplomacy/LazyModule.scala#L183-L185
What I would like to do (I think) is:
class LazyBlackBoxModuleImp(val wrapper: LazyModule) extends BlackBox with LazyModuleImpLike {
  val (auto, dangles) = instantiate()
}
``


clean up the Dockerfile

there should be a simpler way to install python3 and snakemake, and the existing dockerfile might not follow good docker practices

Align with the changes we are making to the installation instructions in https://github.com/coderefinery/installation

Ok, the Dockerfile is not related to the installation instructions.

Dockerfile in optional "Creating and sharing a container image" episode has been updated and simplified


fix(dev): pin the Go version to 1.11.5

A workaround for #3551. It is not clear to me how the upgrade managed to pass CI, but builds fail locally on both macOS and Linux after #3548.

Updating Gazelle seems like it would also fix this: https://github.com/bazelbuild/bazel-gazelle/releases/tag/0.17.0

Updating Gazelle seems like it would also fix this: https://github.com/bazelbuild/bazel-gazelle/releases/tag/0.17.0

So it does. Released 2 hours ago, sounds like a hotfix to me. But I'll take it! 👍

Superseded by #3555.


Jsonb - Visor takes too long to display the JSONB

Description
When select a column with jsonb type, is too long for to charge the data in the visor and the program does not respond. I'd had to install the old version 24.0.5.
DBeaver Version
Community Edition 24.1.0 and 24.1.1
Operating System
Windows 10 Pro 21H2
Database and driver
Postgresql  with driver jdbc
Steps to reproduce
No response
Additional context
No response

I don't know what Visor is, but FWIW, Dbeaver has always been excruciatingly slow to render large json payloads in the "Results cell value viewer". Plus it does it in the UI thread, which locks the entire app, to the point that I sometimes have to kill DBeaver when clicking accidentally somewhere in a json column. Known issue?

Thank you for report. We weren't aware of this issue.

I have the same problem. Earlier versions respond much faster, from 1-2 seconds (before update) to >20 seconds (after update)

Thanks @serge-rider for your quick reply. I does the trick!
It's not very practical though, and it's surprising that a monospace text area struggles so much calculating text layout with wordwrap enabled :/

We use the "Word wrap" feature for styled text, which comes from the platform that Beaver is built on. There is a bug related to this feature at https://bugs.eclipse.org/bugs/show_bug.cgi?id=168557. Unfortunately, it doesn't appear that anyone from Eclipse will be fixing this issue. Perhaps WE should consider trying to fix it. Or create our own "Word wrap" solution.

We improved panel editor so word wrap won't freeze UI. However this fix is more like a workaround.

Thanks a bunch @serge-rider for the improvement.
As for longer-term priorization of this issue, I can only re-iterate how important it is to be able to visualize JSON data from within our SQL client, not having to copy cell data and paste it to another editor every time one need to simply look at the data or do basic text search in it.


chore(deps): update dependency nuget.protocol to 6.12.1

This PR contains the following updates:

Package
Type
Update
Change

NuGet.Protocol (source)
nuget
minor
6.11.1 -> 6.12.1

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Branch automerge failure
This PR was configured for branch automerge. However, this is not possible, so it has been raised as a PR instead.

Branch has one or more failed status checks


Cake uses wrong MSBuild verbosity parameter

When using the extension method MSBuildSettings.SetVerbosity(Verbosity.Verbose), MSBuild is called with /v:verbose instead of /v:detailed.
MSBuild("./Project.sln", settings =>
    settings.SetVerbosity(Verbosity.Verbose));

Correct mapping should be:

Quiet => quiet
Minimal => minimal
Normal => normal
Verbose => detailed
Diagnostic => diagnostic

@patriksvensson Should this change keep the Cake enum, or should it define a new type to match MSBuild?

@ChrisMissal No, I think it's OK to keep Cake's enum since they represent the same thing. At least for now :smile:

Ok, sounds good. That approach will also prevent a breaking change for existing scripts. :+1:

@ChrisMissal Exactly :+1:


State and jti attributes should not be in BoxApplication

The attributes state and jti should not be in the BoxApplication entity. The values for these attributes should be automatically generated when requesting a token from Box.
Especially the state attribute. When requesting a token for a normal user with OAuth, the Box platform will respond with a request containing the same state value. Therefore, our application needs to wait for this response and compare the state value returned by Box with the one that was given.
Also, the value for jti should be created when requesting a token. The documentation says: "A unique identifier specified by the client for this JWT". If Box sticks to the rules of JWT, the platform should check if the given jti has not been used before. Therefore, we have to make sure to create some unique random string for each request.
P.S.  I created this issue in the Nokavision repo, because the mendix repo doesn't let me create an issue.

May I suggest the following persisten entities in the domain model?

This can also be found in the branch I created: TokenRequestAdditions

I agree, the jti at least should be random and moving them out of the Application makes sense.
As for Box refusing to honor a request with a previously used jti, it doesn't seem to be the case, but this shouldn't stop use from using random values.
@MxAdmin:  the mendix/BoxConnector repo currently serves as a fork for deploying to the mendix appstore, all changes will be proposed in the Nokavision/BoxConnector repo.

This issue will be solved later when the Service Account will be fully implemented.


[Enhancement] v10 - Replace async storage with mmkv

Overview

Remove @react-native-async-storage/async-storage
Install react-native-mmkv
Make adjustments utils/storage.ts
Add Cookbook recipe to revert to async storage

Depends on #2638

not compatible with Expo

@SlideeScherz not compatible with Expo Go is correct, we're aware but we have plans :)

Closed by #2660


Access and analyse templates for chefs forms

Describe the task
Examining transferring these templates to our proposed system, and gaining access
Acceptance Criteria

[ ] first
[ ] second
[ ] third

Additional context

Valentina may have access to these templates
Or here

Closed as duplicate for #43.


Current status

I noticed the last commit was pushed in 2018. Is this project still in development?

Originally this was intended to reproduce some of the functionality of Clusterfuzz which was not (at that time) open-sourced. Since then Google has released more of that project to the internet, and there is no longer a need for this project.

Thanks for the clarification!


LLMLingua and LongLLMLingua parameters question

I read the issue #7, #12 and #49,
I guess the right papameters that LLMLingua uses are :
prompt  = compressor.compress_prompt(       context=xxx,       instruction=xxx,       question=xxx,       ratio=0.75,      iterative_size=100,       context_budget="*2",   )   ,
and LongLLMLingua is
prompt  = compressor.compress_prompt(       context=xxx,       instruction=xxx,       question=xxx,       ratio=0.75,      iterative_size=200,       condition_compare=True,       condition_in_question='after_condition',       rank_method='longllmlingua',       reorder_context='sort',       dynamic_context_compression_ratio=0.3,       context_budget="*2",   )
I have some questions：

In #7   , you said context_budget should be *1.3 or +300 in LongLLMLingua, and #12 ,you said context_budget should be +200 in LongLLMLingua, so I am confused by the setting of context_budget, and meanwhile, in the LLMLingua and LongLLMLingua papers, the context_budget seems to be *2 (in #49). So I want to know how to set context_budget in LLMLingua and LongLLMLingua.
in #49, you said context_budget and token_budget_ratio can be considered part of the control coefficient parameter k. Can I think I  just need to control the context_budget? Because in #7 and #12, you do not change the token_budget_ratio.
What does dynamic_context_compression_ratio parameter correspond to in LongLLMLingua paper? I do not find it in the implementation details.
The most important thing I want to know is whether the parameters I describes above are correct, and I want to get your LLMLingua and LongLLMLingua parameters you used actually in the paper, and i want to use TRUE parameters to run LLMLingua and LongLLMLingua experiments.

Please forgive my too long questions, because your LLMLingua and LongLLMLingua work are very interesting for me!
Looking forward to your reply.

Hi @XiaoFengbing,
Thank you for your question. I've shared the parameters we used in LongLLMLingua in issues #7 and #12, which you can refer to.

In fact, as I mentioned in issue #49, the "granular control coefficient" k in the paper equals “context_budget” plus “token_budget_ratio”. In LongLLMLingua, we mostly use “context_budget” = “+200”, whereas in LLMLingua, it’s “context_budget” = “*1.5”.
You can leave “token_budget_ratio” unchanged for most tasks.
The “dynamic_context_compression_ratio” corresponds to δτ in Equation(5) of the LongLLMLingua paper.
If you have more questions, please feel free to ask.

Hi, @iofu728, thanks for your response very much!

I confused about context_budget after reading #7 and #12.

context_budget are different number in LongLLMLingua, so i am confused.
So I will set context_budget to be +200 in LongLLMLingua, thanks!

I see dynamic_context_compression_ratio seems to be 0.25 by default in LongLLMLingua paper B.2 OTHER IMPLEMENTATION DETAILS. I am confused why it is set to be 0.3 or 0.4 in #7 and #12.

Thanks for the LongLLMLingua parameters you shared in issues #7 and #12. I want to know the LLMLingua parameters you used—— prompt  = compressor.compress_prompt(   context=xxx,   instruction=xxx,   question=xxx,   ratio=0.75,  iterative_size=100,   context_budget="*1.5",   )    Is it right?

Hi @XiaoFengbing, sorry for the late reply.

Yes, we stated in the paper that it's 0.25. However, for tasks like MultiDocument QA, a setting of 0.3 or 0.4 tends to perform better.
That matches the parameters I use.


WIP: add format support to numeric types

PR: for discussion
See https://github.com/epoberezkin/ajv/issues/291 for context.

@epoberezkin Perhaps it is okay to only apply the format if the type is explicitly declared in the schema?

see comment above

I think it makes sense to restrict it to just string/numeric types explicitly declared in the schema

I think there should be a way to define format for any types. Type that the format applies to should be a part of format definition with string being the default (if type is not present in the definition).

Thank you, it's getting there it seems :) Some more tests and docs and it's done. Also, I am going to merge it into 5.0.0 branch - I will release the next beta version once it's finished.

@nimerritt finished and merged in 5.0.0

Thanks for finishing this up for me :) Actually needed it again today, so 👍


Error when using batch_size.

System Info / 系統信息
Thank you for providing a way to finetune LTX-video. Training seems to work well, but when I try changing batching (in this case to 4), I encounter this exception. I'm using the suggested example script in the repo. Running on diffusers from github, updated two days ago.
This is the exception:
12/21/2024 12:38:27 - ERROR - finetrainers - Traceback (most recent call last):
  File "/some_path/train.py", line 34, in main
    trainer.train()
  File "/some_path/trainer.py", line 424, in train
    noisy_latents = (1.0 - sigmas) * latent_conditions["latents"] + sigmas * noise
RuntimeError: The size of tensor a (4) must match the size of tensor b (128) at non-singleton dimension 2

Also hijacking my own issue:
I tried adding --resume_from_checkpoint since that worked with the old cogvideox-factory trainer. But it doesn't seem to do anything now. Is that correct?
Thanks!
Information / 问题信息

[X] The official example scripts / 官方的示例脚本
[ ] My own modified scripts / 我自己修改的脚本和任务

Reproduction / 复现过程
Change   --batch_size 1 to something other than 1
Expected behavior / 期待表现
Training would continue with batching enabled

Oh interesting, thanks for reporting! I'll look into this shortly.
--resume_from_checkpoint support will be added soon too. I think #130 has it working, so it will be in main soon hopefully


Incomplete/partial Vietnamese translation and not fit at all with original

Vietnamese translation is incomplete and not fil at all with the original in english since #5826 was introduced.
Take english file as reference and complete and rewording
So task is translate again. Anybody?

hey can I work on this , if not done already?

use the issue comments, please

On Sep 28, 2022, at 9:18 AM, Shivam Purohit @.***> wrote:
hey can I work on this , if not done already?
—
Reply to this email directly, view it on GitHub https://github.com/EbookFoundation/free-programming-books/issues/6783#issuecomment-1260901890, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHCGMLDOGS5TBOEBIHABSTWARAUFANCNFSM5Q6IODIQ.
You are receiving this because you are subscribed to this thread.

@davorpa Can you please assign this issue to me?


Add examples for Card

#35
Feed is done currently with base semantic-ui. A separate issue will be to update that once the feed component is completed.

Everything works on these except for the ImageCard2 example. I'm having trouble getting the dimmer event to trigger. I'll keep working on it, but if you have any ideas, I'd love to hear them!

Everything works on these except for the ImageCard2 example. I'm having trouble getting the dimmer event to trigger. I'll keep working on it, but if you have any ideas, I'd love to hear them!

Sorry, I missed the comment, but it seems you found the solution... great!

Released in v0.0.26


Add React setup and configuration

I've hacked React into a project or two, but I'll be the first to admit I'm not React setup expert. I would love if someone who knows and understands the React ecosystem submitted a pull request that included the necessary elements in our front end tooling for building projects using React.
Requirements:

This would have to be an option definined in cookiecutter.json. I would like to default to React and make Angular an option.
Documentation: How to on glue React into a template or two. I want more than just one, because per https://github.com/petehunt/react-howto, the first step to getting good is to replace individual components in React, not build a single-page app from scratch.

+1 to this.

+1

Do you have feelings about the asset pipeline?
Normally, I don't tie into staticfiles and treat my client source as a separate project (driven by grunt, gulp, webpack, et al).

cookiecutter-django currently uses Gulp for front end asset management, and it's bundled in. We're not adverse to switching to something else, but will want to keep the bundling in.

I'm wondering if it'll even be possible to come up with a de facto implementation for this out of the gate. My projects, again, split client and backend entirely. As such, I handle identity and authorization via something similar to JWT (provided by django rest framework). This also relies on CORS being configured.
DRF has competitors, so you'll potentially want flavors for different backends. Additionally, there's a spectrum of ways to go about SPAs with Django, my preference being one of the extremes.
That all said, it's easier to decide what you like or don't like about a thing when you have the thing already in front of you. Maybe we throw something against the wall and see what sticks?

I would prefer to have a really strong DRF setup for React on cookiecutter-django than provide alternative options for REST support. Less complexity, and keeps this already large project from growing more.

+1

+1

+1
\o/,
Eraldo
--
/============================================
| E r a l d o    E n e r g y
| Coach: Personal Development
| Dancer: Salsa, Bachata, Kizomba & Co.
| Developer: Python/Django

Legend: coLegend.org http://www.colegend.org

M: +49 176 97 99 44 80 <004917697994480>

E<EMAIL_ADDRESS>

W: www.eraldo.org

S: www.facebook.com/Eraldo

============================================

Be Awesome! Love with an Open Heart! And Live a Legendary Life.. Today!

On Sun, Jan 17, 2016 at 9:22 PM, Peter Rosemann<EMAIL_ADDRESS>wrote:

+1
—
Reply to this email directly or view it on GitHub
https://github.com/pydanny/cookiecutter-django/issues/466#issuecomment-172377078
.

Okay, we have enough +1's on this issue. Please only comment if you have something meaningful to add or a pull request.

I have tried to find some discus on the web about this subject.
Found this GitHub project Python-React I think it can be of help.
There is a Reddit discussion about Flask, Reactjs and Django Rest Framework.
Also there is this blog post for Django, DjangoREST and ReactJS, and this is by mine opinion the best tutorial about this subject that @pydanny start about React + Django, link to the blog, and there is some official React blog post about using Python + ReactJS, but I don't know if this can be off help, because it is an old post.

Is someone working on this? I'd be happy to assist if there are any problems.

@jayfk Not directly on it, but this mayl simplify integration: https://github.com/pydanny/cookiecutter-django/issues/538

Resolved in #610 by @goldhand.


Can Not Create Generate Draft Model Node

I have completely reinstalled ComfyUI, with only this custom node and the manager installed, but still, I get an undefined node, which appears to be the Generate Draft Model node, because I can create other nodes in this package.
Environment: Python 3.12.7, torch2.4.1_cu12.4

OK. Let me update the workflow image. Before that, I think you can get the node from menu.

OK. Let me update the workflow image. Before that, I think you can get the node from menu.

Not really, I can't create the Generate Draft Model node even from the menu, nothing appears. As I mentioned before, I can only create the other five nodes from this package.

It seems that ComfyUI disqualifies the format ("INT",)


Missing module Javascript error or some users

I've got a handful of users on Windows and Steam reporting a Javascript error on launch, even after verifying files with Steam and reinstalling, etc:

Uncaught exception: Error: The specified module could not be found.
?\C:\Program Files(x86)\Steam\steamapps/common\cyberpunkdreams\r...\steamworksjs.win32-x64.msvc.node

It's working fine for everyone else so it can't be a problem with the build (?) Any thoughts?

Further to this, one user has now said that they're using Linux with Proton 9 instead of native support. I guess this is the problem.

I've just realised that I only package the native modules for each release, so the problem is downloading for Linux and trying to run on Proton, which then can't find the Windows modules.


Compilation error with dependently-typed functions when the return type is a record type with a dependently-typed field

Description:
$title. Fails with an "unknown type" error.
Steps to reproduce:
function foo(typedesc<any|error> td) returns map<td> = external; // Works.

function bar(typedesc<any|error> td) returns record {| td x; |} = external; // ERROR [test.bal:(3:56,3:58)] unknown type 'td'

Affected Versions:
slalpha2

This is the same as #23491. Affects objects and errors as well.

This is the same as #23491. Affects objects and errors as well.

Thanks, missed this.
Closing this issue since it is a duplicate of #23491.


Update lodash to v 4.17.12

Hi all,
is it possible to update one of the dependencies 'lodash' to version '4.17.12' as a patch was released to fix prototype pollution
Thanks!

turns out my npm cache just needed clearing - issue resolved!


Dialog not working with Vue 3

Dialog not working with Vue 3

@Godofbrowser any plans for a Vue 3 compatible version of vuejs-dialog?

@Godofbrowser any plans for a Vue 3 compatible version of vuejs-dialog?

@TheJaredWilcurt @ifarooq Thanks for continued interest in VuejsDialog. Although I had to dedicate my time to other things at some point, I have the intention of not only making this work with Vue3 but also a rewrite of some parts of the plugin to address issues from the previous versions. As a first step, I'd bootstrap the plugin this weekend for Vue3 and have an estimate of how much effort it will take to complete. Will update this issue.

@TheJaredWilcurt @ifarooq Thanks for continued interest in VuejsDialog. Although I had to dedicate my time to other things at some point, I have the intention of not only making this work with Vue3 but also a rewrite of some parts of the plugin to address issues from the previous versions. As a first step, I'd bootstrap the plugin this weekend for Vue3 and have an estimate of how much effort it will take to complete. Will update this issue.

Ok thanks much.

Sorry to bother but, any news?

Yes, I resumed work on vue3 migration. Sorry for the long wait https://github.com/Godofbrowser/vuejs-dialog/tree/dev-v3


Different dockerfiles between this and the main repo

I just started using mumble, and first I used the Dockerfile available at the main repo (https://github.com/mumble-voip/mumble/blob/master/Dockerfile) but then I discovered this which automatically builds and pushes the image to Docker Hub.
I checked the Dockerfiles and they are slightly different, is there a reason for that? Should one be used over the other?

The reason is simply that this repo is more recent than the Dockerfile in the main repo. I would recommend using this repo though, as we intend to remove the Dockerfile from the main repo in the future (in favor of this one)

Perfect, thanks for the clarification!

You're welcome :)


bump version to 0.4.2

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

Comparison is base (cf4a456) 96.42% compared to head (b8a3624) 96.42%.
Report is 3 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #49   +/-   ##
=======================================
  Coverage   96.42%   96.42%
=======================================
  Files           5        5
  Lines         112      112
=======================================
  Hits          108      108
  Misses          4        4

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


Bump to 0.5.0.

should this also add calls to kubectl proxy for the namerd config?

It's already there: https://github.com/BuoyantIO/linkerd-examples/pull/14/files#diff-f4e146ea786cfa276ff176b9e093d796R40

:star: doh

⭐ 🐌


Invalid Oauth Redirect URI

I am sure I did everything pretty perfect. But still it says invalid oauth redirect url. Pls  help me

this is no longer maintained

i woulnt count on much working

whatever url you put in the dev portal isnt right


Add test script to show behavior with $push and query selectors

Description
See #1855.
This PR shows that we return a ErrBadValue when the field is not an array. However, when upsert is true we should not attempt to insert the query predicate unless it is an array. This prevents query selectors from working correctly.

I need to fix the test script.

It passes now!


⚠ Mobitopup has degraded performance

In f007d03, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 4297 ms

Resolved: Mobitopup performance has improved in 089d59b.