Memory access problem with 1.2.1 with Python in Linux

Hi everyone,
after roughly checking this issue for duplicates or similarities, I came to the conclusion to try to post this.
Just to be clear, I work with Python in Ubuntu 22.04 LTS in Wayland. But I also tested this issue in Xorg. Unfortunately same result.
After updating imgui-bundle from 1.1.0 to 1.2.1 via pip, I noticed that the line
imgui.create_context()
leads to a crash of my app. Now the curious part.

I've tried this with sdl2 first, since it is my main backend in use currently. It doesn't work. That's how I noticed it.
Then I tried the same with glfw3. It also crashes.
After that, I then tried the example backend files from the repository. Neither do they work.
Desperately I thought, "Maybe I did something wrong? Maybe the backends doesn't work anymore.", thus, I tried the "demo_hello_world.py" (with immapp) demo code, which can be found in the doc. Also no luck.

The app starts briefly in all cases. It shows no content. However, it either stops without any terminal output or outputs a memory access error line, which is not helpful.
I'm working on a system with Intel core i7-1365U, which comes with Iris Xe and thus in Ubuntu with Mesa Intel Graphics (RPL-P) driver. I think this is quite strange, since imgui-bundle 1.1.0 works fine.
Currently, I'm working with version 1.1.0 until this is resolved.
This is quite a bummer actually, since I really like to use the new functionality of ChildFlags to make the child area re-sizable.

Hello,
Thanks for reaching out. I cannot reproduce your issue here, so I will need your help to investigate.
Python side
Could you confirm that this fails:
from imgui_bundle import imgui
imgui.create_context()

If so, this is probably something inside imgui (or in the bindings around it).
Can you please:

reboot and check whether the problem persists
try to install from source (see https://pthom.github.io/imgui_bundle/install-instructions.html#_install_for_python) and see if that solves the issue

C++ side
Could you clone https://github.com/pthom/imgui_bundle_template and build it (it is a simple hello world with imgui bundle in C++) and tell me if it works?
# clone
https://github.com/pthom/imgui_bundle_template.git
cd imgui_bundle_template
# build
mkdir -p build && cd build
cmake ..
make -j 4
# Run
./imgui_bundle_example_integration

Follow up
If the problem persists, since I cannot reproduce it on my side, please contact me by email at pthomet at gmail dot com, I'll try to help by email.

Thank you for the very fast reply! Thus, I'll do my best to answer the effort.
Python side

The following code (pip version) fails with memory access error..

from imgui_bundle import imgui
imgui.create_context()

Reboot doesn't work either. Since it was the first thing I did after updating. Sorry for not mentioned it.
The installation from source does work. (Btw. did version 1.2.1 added impl.process_event? I wondered that clicking didn't work until I've added that. Is that something ocornut added/separated from process_inputs? Sorry for not being up-to-date)

C++ side
I did all those steps and it also seems to work. To make sure it is the right version, I've added the child windows snippet with the variable resizing. It works as intended.
Preliminary Conclusion
It seems the imgui-bundle version 1.2.1 on pip is currently faulty, since the compiled version directly from the source does work. I don't need to mention that the C++ version also has no problems.

I cannot replicate your issue on Ubuntu22.04 (but I'm using arm64 on a Mac).
I'm afraid the wheel build might be faulty, although I don't know why.
If you have time could you try to install from source at tag v1.2.1:
cd imgui_bundle
git checkout v1.2.1
git submodule update
pip install -v .

If it also works, I'll have to suspect the wheels built by github's CI...

Btw. did version 1.2.1 added impl.process_event? I wondered that clicking didn't work until I've added that. Is that something ocornut added/separated from process_inputs? Sorry for not being up-to-date

I did not understand what you are referring to. Can you clarify?

Child windows snippet with the variable resizing.

Is this a new flag in ImGui?

Now I had the chance to test this issue on another notebook, which is a Intel core i5-7200U, which entails an older Intel HD Graphics.
I tested it again with the pip version 1.2.1, but I also had the same issues. Namely the same memory access error as on the other machine..
Of course I also tried to compile everything from source (older CPU, more tea time I guess), which was again the same. I successfully got imgui-bundle to work with the main branch.
Since I'm also interested in solving this issue, I did what you suggested and tried to build against v1.2.1 by checking out that branch (or tag, whatever). But I could not. Rather an error just popped up after trying to pip install -v .
  error: subprocess-exited-with-error

  × Building wheel for imgui-bundle (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  full command: /usr/bin/python3 /usr/lib/python3/dist-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /tmp/tmpy0okxmmq
  cwd: [..]/imgui_bundle
  Building wheel for imgui-bundle (pyproject.toml) ... error
  ERROR: Failed building wheel for imgui-bundle
Failed to build imgui-bundle
ERROR: Could not build wheels for imgui-bundle, which is required to install pyproject.toml-based projects

You may be right about the wheels.. and just for the record, I successfully build the entire thing with the main branch.

About the impl.process_event. I use the sdl2-backend combination. In sdl2 impl.process_inputs() needs to be called for any inputs (mouse and key) to be recognized by imgui at all. But after updating to v1.2.1, I need to call impl.process_event(*event) instead. But since you're not aware of this, I assume that this is rather a change done in the main imgui branch I guess.
About Child Flags. Yes, this seems to be rather new, since ocornut implemented it just last year in summer it seems. With this, the parameter for imgui.begin_child changes slightly. Previously, one parameter was to determine, if it has a drawn border or not. Now it is integrated into the flags. It can be set by ChildFlags_.border. The new thing is, that you can also set imgui.ChildFlags_.resize_x for example. This allows you to resize the child directly by dragging the border on the right.
child_border_drag.webm

Now I had the chance to test this issue on another notebook, which is a Intel core i5-7200U, which entails an older Intel HD Graphics. I tested it again with the pip version 1.2.1, but I also had the same issues. Namely the same memory access error as on the other machine..

Hum, this is getting worrying.

I tried what you suggested and planned to build against v1.2.1 by checking out that branch (or tag, whatever). But I could not. Rather, an error just popped up after trying to pip install -v .

If a source build fails, this is also an issue... The log extract you inserted is not long enough and does not contain the root cause of the error. Can you please attach the full log, or a longer extract where the root cause is displayed.

About the impl.process_event. I use the sdl2-backend combination. In sdl2 impl.process_inputs() needs to be called for any inputs (mouse and key) to be recognized by imgui at all. But after updating to v1.2.1, I need to call impl.process_event(*event) instead. But since you're not aware of this, I assume that this is rather a change done in the main imgui branch I guess.

Do you mean this, when using a pure python backend?

As far as wheels built by github are concerned, I'd like to make a test: each time a modification is made on the main branch wheels are built by github. They contain an artifact which you can download, for example here, and this artifact contains wheels for all platforms.
Could you tell me if the wheels in this artifact work for you

Hi there again.
I tried to reproduce the installation of the git repo with v1.2.1 again. On the newer machine today, strangely enough, it could compile without problems. So for verification, I plan to do the same with the other machine again later today, since I don't have access to it right now. But since both machine are similar (Intel 64bit etc.), I suspect being sloppy myself yesterday for not cleaning up the build. But that would not explain why, without cleanup, a git checkout to the latest branch in the very same folder worked fine again though.
Sorry for currently not being able to provide the full log from yesterday, since I just copied it from terminal. (Forgot the proper manner of full logs)
I assume there weren't any changes since yesterday with the v1.2.1 tag?
Anyway, after the successful installation (demo says version 1.19.0), imgui-bundle works just fine. There I've wondered if I did something wrong yesterday and tried to install imgui-bundle from pip directly again. But sadly, it still crashes like yesterday.. I could reproduce the error from yesterday..

Yes exactly, I mean that pure python backend snippet! Line 40 and 41. It is strange though. I guess line 41 impl.process_inputs() could be obsolete now? I did tested it with the show_demo_window line, but every input works just fine without line 41.

About the wheels, I downloaded the example artifact from the link you've provided (#586). And just as I'm writing this line, the compilation has finished. All the example codes works just fine.

...the compilation has finished. All the example codes works just fine.

Actually, I would like you to try without compiling, by using the compiled wheel that corresponds to your python version.
i.e. you could use either:
artifact/imgui_bundle-1.2.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
artifact/imgui_bundle-1.2.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
artifact/imgui_bundle-1.2.1-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

On the newer machine today, strangely enough, it could compile without problems

Sometimes, a previous compilation left temp files inside _skbuild, and removing this folder before recompiling sometimes avoids errors.

Yes exactly, I mean that pure python backend snippet! Line 40 and 41. It is strange though. I guess line 41 impl.process_inputs() could be obsolete now? I did tested it with the show_demo_window line, but every input works just fine without line 41.

Well, the python backends are almost direct adaptions from  pyimgui bindings.
The sdl backend for pyimgui also provide process_inputs, and inside imgui_bundle process_inputs was adapted from it.
I removed the mouse handling from it, since it was done in process_events. However it still has some impact on imgui (set       io.display_size, io.display_framebuffer_scale and io.delta_time)

Okay, without compilation. No problem.
I still have Ubuntu 22.04 with Python 3.10, I went by cp310.
Now I understand what you want from me. So I went on the journey and downloaded around 11 artifacts in total and went by divide and conquer. I could pin down the problem to be in between artifact 528 and 531. As you can see, 529 and 530 was not build due to errors.
So artifact 528 is the last package, where imgui-bundle actually works (for Ubuntu). From 531 until the latest (which is 586 as of now), I get the memory access error. So I tried to compare the folders to see what differences happened, and the following might be the cause:

That is what I noticed. You can try to analyze it yourself to what to do about that. I have no knowledge about the automatic builds in github (I should invest some time for that though), but I would be glad, if you figure it out and could explain what the problem was.

Woo, many thanks for this analysis.
So, after analysing the artifacts numbers, the possible commits that cause the error are:
14faa56 update hello_imgui [Pascal Thomet]
([hello_imgui] updated from e8ec91 to 0b5027)
b722ca9 Update ImGui bindings: publish ImGuiInputTextCallback and ImGuiSizeCallback as std::function [Pascal Thomet]
191532f imgui: publish IniFileName and LogFilename as string [Pascal Thomet]
I would suspect 14faa56, but I cannot find the related history in hello_imgui. Something strange...
Anyhow, I will have to publish an update on pypi, since the latest is broken for ubuntu users. Many thanks to you!
As I cannot reliably test this on my side (as it seems),  can you please check wait until the latest wheels build is finished (now compiling, and should be ready in 1 hour), and tell me if the binary wheels work for you.
If so, I'll try to prepare a release based on this.

PS: if you have something to show, I'm always pleased to see what users are doing with imgui_bundle in the gallery

Okay, just downloaded the newest artifact 587 and tried it out. But unfortunately, the binary wheel didn't work. Same error (memory access error, or if executed from vscodium, no output at all, silent exit so to say). And as always for control, either self compiled or version 1.1.0 do work.
PS: Currently not yet, but if my experimenting phase is done and I've something developed, I could show. Since this is academic work, it might be possible to let you have a glance on it in the future. Anyway, I should be very thankful that you bundled up imgui and some really useful "batteries" like ImPlot or Node-Editor into this for python! Else I would consider to develop in C++ or something.. or not using any GUI at all.

I know this little post is not really related to this issue, but the reason for me using imgui-bundle has something to do due to pyimgui not working on Wayland at all. Due to OpenGL.error.Error: Attempt to retrieve context when no valid context error pyimgui #318. None of the suggested workarounds there works for me.
Also, they are a tad behind the updates from ocornut directly (would not be a big deal since I didn't use the new features very much). Their version 2.0.0 is currently based on 1.82. And there are currently no sign of any updates since 9 month ago (as of writing now).

Hello,
Are you available for a session where we could work together on this (we would setup a conf call with screen sharing, so that I can try to diagnose more in details).
I could be available at 4PM paris time today, i.e 3PM UTC.

If not, I'll need to setup an Intel Linux machine somewhere

Unfortunately, I'm currently not available for calls due to work.. Later I may try to replicate by forking and looking for some clues in between the artifacts. Sorry for that.

I understand

The issue seems to come from cibuildwheel.
Here are my findings:
Below is a draft for a message I intend to post to cibuildwheel

I have an issue with a wheel built on github runners when I try to install it on ubuntu 22.04.
A simple call to new fails when using the wheel, however it does work when installing from source via pip install -v .
The wheel is named imgui_bundle-1.2.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl,
i.e. it is a manylinux wheel for python 3.10 x86_64.
About the wheel:
The wheel was built like this (this is a copy-paste of the GH action provided by pypa/cibuildwheel@v2.16.2):
    pipx run --python '/opt/hostedtoolcache/Python/3.11.7/x64/bin/python' --spec '/home/runner/work/_actions/pypa/cibuildwheel/v2.16.2' cibuildwheel "." --output-dir "wheelhouse" --config-file "" --only "" 2>&1

When I install it on ubuntu 22, with
pip install wheelhouse/imgui_bundle-1.2.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

I get a segmentation fault, if I call a simple function (that mainly allocates a new object via new):
python -c "from imgui_bundle import imgui; imgui.create_context()"

The output is:
    ImGui::CreateContext 1
    ImGui::CreateContext 2
    sizeof ImGuiContext = 27792
    Segmentation fault (core dumped)

I have instrumented the for ImGui::CreateContext(), and we see that a simple call to new fails !!!!
ImGuiContext* ImGui::CreateContext(ImFontAtlas* shared_font_atlas)
{
    printf("ImGui::CreateContext 1\n");
    ImGuiContext* prev_ctx = GetCurrentContext();
    printf("ImGui::CreateContext 2\n");
    //ImGuiContext* ctx = IM_NEW(ImGuiContext)(shared_font_atlas);
    //ImGuiContext* ctx = new(ImNewWrapper2(), ImGui::MemAlloc(sizeof(ImGuiContext))) ImGuiContext(shared_font_atlas);
    printf("sizeof ImGuiContext = %lu\n", sizeof(ImGuiContext));
    ImGuiContext* ctx = new ImGuiContext(shared_font_atlas);  //IM_NEW(ImGuiContext)(shared_font_atlas);

    printf("ImGui::CreateContext 3\n");
    SetCurrentContext(ctx);
   ...

About the local install via pip:
Note: when building the package locally, with
pip install -v .

It works correctly!
python -c "from imgui_bundle import imgui; imgui.create_context()"
    ImGui::CreateContext 1
    ImGui::CreateContext 2
    sizeof ImGuiContext = 27840
    ImGui::CreateContext 3

Notable differences:
sizeof ImGuiContext = 27792    with the wheel binary
sizeof ImGuiContext = 27840    with the local pip install

This can be reproduced with the repository https://github.com/pthom/imgui_bundle,
on the branch dbg_ub and it can happen directly on the ubuntu-latest runner from GH.
Am I doing something wrong?

First time hearing about this cbuildwheel. This seems to.. ease cross compilation?
As I were tinkering around in the wheel file, I notice this cbuildwheel line. So that is where it comes from..? So the builds are relying on other projects?
Since I'm no expert in this matter, I trust you that this will lead to the culprit. Segfaults or memory access problems usually comes from somewhere in wrong bindings of video driver related library, I guess?

Update: I confirm this is a cibuildwheel issue: see https://github.com/pypa/cibuildwheel/issues/1724
As a workaround, I can disable the usage of std::string for IniFilename and LogFilename. It should hopefully be sufficient.
Wheels are being built with this change. Can you test them?

I can confirm, the change of this artifact you've done here, is working! For record, in this build, imgui is at 1.90.1, which should be the most recent what ocornut also just released.

This was my most difficult bug hunt ever.
And I only found a workaround. Let's hope it gets fixed in cibuildwheel, or if I made a mistake that I get to know where it was.

I can't even understand how you got to the conclusion of a cibuildwheel bug and also as to why not using std::string can make everything work again as a workaround. Seems quite unrelated to me.. Anyway, great job!
Are there no simple tests running after workflow builds are done to see, for example,
if a code like from imgui_bundle import imgui; imgui.create_context() works on every platform?
I mean yes, in the .github folder, there are various yaml (quite a lot actually) for building it seems. So the ci_automation_tests didn't seem to cover that..?
Anyway, let's hope the cibuildwheel team will do something about this strange building differences.

using std::string can make everything work again as a workaround

When sizeof() gives different sizes, you enter a world of pain; because you are probably facing ABI incompatibilities. I suspected the std lib (and thus std::string).

how you got to the conclusion of a cibuildwheel bug

It was long, I had to check on multiple platforms, and also check that a standard binary wheel build does not have the issue

So the ci_automation_tests didn't seem to cover that..?

No, ci_automation_tests runs a complete automated application test after pip install -v ..
I never suspected that cibuildwheel might give a result that is different from pip install...

running after workflow builds are done to see, for example, if a code like from imgui_bundle import imgui; imgui.create_context() works on every platform

Yes, I added this in this commit. I cannot do more tests with cibuildwheel, because adding a X server to run the tests with cibuildwheel would get ultra complicated.

Soo, since this is solved by a workaround, can this issue be closed or should it stay open for reference?

I'll leave it open for reference for a while

I released version 1.3.0 to correct the wheels for linux users:

release page
pypi package

Based on my tests, it works. Can you confirm?

I just made a pip install imgui-bundle -U to update to 1.3.0. I can confirm that I can successfully run the sdl2, glfw and helloimgui examples.

I found the reason for the bug, and actually it's deep in the roots of Linux systems.
See my last answer here before I closed the issue, and reopened another which is more to the point:
A wheel built with pip install

uses the SYSV ABI (older set of conventions for system calls, object files, and libraries)
sizeof(string)=8
is linked against libstdc++.so.6

> file _mylib.cpython-310-x86_64-linux-gnu.so
 ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked

A wheel built with cibuildwheel

uses the GNU/Linux ABI (newer conventions for system calls, with modifications made by the GNU project)
sizeof(string)=32
is linked against libstdc++.so.6

> file _mylib.cpython-310-x86_64-linux-gnu.so
 ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked

And std::string from the GNU/Linux ABI does not support zero-initialization, which ImGui uses a lot, like below:
    IO::IO()
    {
        // ImGui uses many C-style initializations techniques, such as this memset
        // However, the std::string provided by GNU/Linux does *not* support to be zero-initialized!!!
        memset(this, 0, sizeof(*this));

        ...

        IniFilename = "imgui.ini";  // This fails spectacularly with GNU/Linux ABI
    }

What dedication!
But also the root of the problem caught me off-guard. It goes deeper and is less straight forward that I though. To be honest, I never really used memset. Now with a bit of research, since it sounds important to know, this is one way to initialize a potentially large memory section like a struct. Because it is fast and can "initialize" the object quickly with a certain value.
But it seems that this should be avoided in C++, since it circumvents the type safety that C++ provides (by the way, imgui is around 88% C++). Since you mentioned that this sort of std::string is used alot in ImGui (not wonder, it is surely more convenient and safer than char* or similar).

Anyway, fascinating that two different compiler are used here. As I've found out, among others, clang, g++ and c++ on my Ubuntu are compiling with a SYSV type.
To test this again, I installed the imgui_bundle v1.2.1 via pip install -v .. The binary "_imgui_bundle.cpython-310-x86_64-linux-gnu" is compiled with the GNU/Linux type, but it works well. And just to be really sure, I did pip install imgui_bundle==1.2.1 to see the type:
# So I checked the _imgui_bundle.cpython-310-x86_64-linux-gnu.so file

# This is installed via pip install -v . (local compilation), works well
ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked,
[...], stripped, size 42.595.432 Bytes

# This lib installed from pip leads to the error.
ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked,
[...], stripped, size 43.718.729 Bytes

I may be wrong, but I suspect a different version of the same compiler. Or different flags or whatever. But yes, let me stop here, this issue is solved, these are only afterthoughts.


bug(ci): fix server api test typo for tag api

Description
related pr: https://github.com/star-whale/starwhale/pull/2569
error message:

Modules

[x] Others

Checklist

[ ] run code format and lint check
[ ] add unit test
[ ] add necessary doc

Add the apitest dir in the all-check rules of client?


mDNS on RPi Pico

I am trying to run the service_responder.py example program on a RPi Pico with Ethernet port and get this error:
OSError: [Errno 98] EADDRINUSE
Does this mean the mDNS service is already active in the MP firmware? If so, should I see the Pico advertising its host name in the local network? I tried with an mDNS browser but could not find the Pico.
MP version is this:
MicroPython v1.19.1-910-g4937174b4 on 2023-03-01; W5500-EVB-Pico with RP2040
Thanks.

Hello,
I am pretty sure this has to do with MicroPython having a default MDNS implementation on the RPi Pico already activated and you need to disable it before being able to use MDNS for service discovery.
However, the implementation has currently only been tested with ESP32 configuration and it has recently pointed out to me that it will likely not work on other implementations: https://github.com/cbrand/micropython-mdns/issues/8#issuecomment-1443703889
If you only want to see / have an address in WiFi for you device and not any kind of service discovery you might not want and/or need to use this library: https://github.com/cbrand/micropython-mdns#intended-audience
The hostname if you do a MDNS lookup should already advertise itself on the network: https://github.com/micropython/micropython/commit/2ccf030fd1ee7ddf7c015217c7fbc9996c735fd1 (This is for esp32 but I think the rpi pico also has something similar when this error message comes up).

I really cannot find any documentation or source code about this MDNS service built into the Pico Micropython build. And avahi-discover doesn't find the Pico advertising itself in the network.
So my guess is it actually isn't there and your MDNS package doesn't run on the Pico either (for the reasons you mentioned), so the EADDRINUSE it causes might just be misleading.

avahi-discover as far as I am aware of is searching for services not for hosts itself: https://linux.die.net/man/1/avahi-browse
What I presume is going on that it registers its host name (A Record) and that is not seen by avahi-discover (which is scanning for SRV records). You can see if the host name on MDNS is available if you know it by just doing ping {host_name}.local or also skip the local. This should be resolvable. The EADDRINUSE clealry states that there is something in the code base listening on PORT 5353 which is 95% surely an MDNS service which is embedded in the deployment of Pico.

You can see if the host name on MDNS is available if you know it by just doing ping {host_name}.local or also skip the local.

Yes, I tried that, but without success. I tried the hostname which I get from network.hostname() on the Pico.

The EADDRINUSE clealry states that there is something in the code base listening on PORT 5353

I also did a port scan of the Pico but this didn't find any open ports :roll_eyes:

Alright sorry about that then. I think without having a Pico here myself I can not help you any further.
Hope you'll find the issue and figure it out! Closing this for now. Feel free to open a new issue once you've debugged the base issues on the Pico. I would like to add support for the library for other systems, too so would be eager to hear if you get it to run and if not what error message you receive.
Good luck :)

I was able to get around that error by compiling micropython myself, and setting the include for LWIP_MDNS_RESPONDER to 0.
I got past the EADDRINUSE issue at least. Still trying to successfully resolve a service name.

If anyone is interested, here is the explanation why the MDNS port on the Pico is used by default but it is actually not advertising anything:
https://github.com/micropython/micropython/issues/8946

@captncraig  i just started my own project (my first), on the raspberry pi pico wh, i am facing the same issue. But i lack the knowlegde how i can overwrite this, like you said. Can you help me out how to get this working?

@captncraig i just started my own project (my first), on the raspberry pi pico wh, i am facing the same issue. But i lack the knowlegde how i can overwrite this, like you said. Can you help me out how to get this working?

Clone the repo from https://github.com/micropython/micropython.
go to repo-folder cd micropython
edit the include for LWIP_MDNS_RESPONDER to 0. via nano nano ./ports/rp2/lwip_inc/lwipopts.h and replace the 1 in line 35 after #define LWIP_MDNS_RESPONDER to a 0, then press ctrl + x to save and hit enter to confirm saving.
go to mpy-cross folder and build it cd mpy-cross && make
go to rp2 port folder, install external deps and built pico-uf2 file with cd ./ports/rp2 && make BOARD=RPI_PICO_W submodules && make

build-RPI_PICO_W.zip

With the tip from @captncraig i can successfully get a txtService. Thank man :)

also why is this issue closed ? @cbrand
This is not fixed at all. Would be way easier to find if its an open issue

@arag0re Hey :) Sorry but this is a bit out of scope of the library.
As this is a build issue for one specific device it makes more sense to me to track it outside of the actual library, as the library in itself is functional.
So keeping the issue open makes the management of this very hard, as I do not have any affiliation with the actual MicroPython project which seems to be the main issue facing here.
There is a caveats section in the README outlining that this is something which might be required for the individual ports for differnt boards to be done (Disabling MDNS functionality): https://github.com/cbrand/micropython-mdns?tab=readme-ov-file#caveats
I think with the information you all provided though I can also release a new version which does not only provide builds for the ESP32 but also for the RPi Pico in the next release and link this issue to make it easier findable in the future so that hopefully more people can benefit from the research done in this ticket.

Hi guys, after implementing @arag0re fix and installing mDNS from @cbrand I was able to use cbrands example for mDNS responder and was able to ping my pico at hostname.local
Can anyone provide any direction on how to integrate this into a web server? I'm fairly new to this and there is little documentation on how to implement this mDNS package into a webserver using micropython. I'm just wanting to be able to access my pico's web page using hostname.local


Add refactored basic reporter

This adds refactored basic reporter codes. Reporter reads key-value
results as input, and writes the record to external files/DBs/etc.
Add a csv reporter that writes key-value report to a csv file.

This change is

/assign @swiftdiaries @gaocegege

/lgtm
/approve

/approve


[WIP] feat(headers): Add Origin header for CORS requests

In response to #651
I've followed the pattern of using the header! macro as this header seems relatively simple. Happy to adjust if you think it's not the correct approach.

Thanks for the pull request! Just so you know, you can edit commits with git rebase -i master, and then force push to this branch to update the PR.

Looking into the spec, I found here a more in-depth ABNF, specifically allowing null or a space separated list of origins, being scheme://host[:port]. Does that match what is used in the wild?
@Manishearth you've done a bunch of the CORS stuff in Servo, is there anything here that should be considered? Or anyone else that should be pinged?

@seanmonstar Thanks!  I work on so many different things with different policies on rebasing, squashing, merging and particularly force pushing!  Good to know what works for you folks.
Happy to adjust to include the additional possibilities. Will await the feedback from the folks you've pinged.

Origin isn't really a string. It's a parsed URL, except that it doesn't have a path.
https://fetch.spec.whatwg.org/#origin-header
Origin                           = origin-or-null

origin-or-null                   = origin / %x6E.75.6C.6C ; "null", case-sensitive
origin                           = scheme "://" host [ ":" port ]

An opaque newtype around Url with equality and a constructor implemented is what we want here, really.

Also, fetch and the original Origin RFC seem to differ on whether or not Origin should be an array.
Fetch says that it supplants the original RFC but I'm not sure what that means for hyper.

@Manishearth Ah, so the fetch spec doesn't allow for a list of origins, just a single one.
My understanding of your suggestion would look something like this:
pub struct Origin(Url);

pub enum OriginError {
    Url(url::ParseError),
    PathNotAllowed
}

impl Origin {
    fn new<T: IntoUrl>(t: T) -> Result<Origin, OriginError> {
        let url = try!(t.into_url());
        if url.path().is_some() {
            return Err(OriginError::PathNotAllowed)
        }
        Ok(Origin(url))
    }
}

Well, I was going to suggest something along the lines of
pub struct Origin(Url); // field is private

impl Origin {
    fn new<T: IntoUrl>(t: T) -> Result<Origin, url::ParseError> {
        let url = try!(t.into_url());
        Ok(Origin(url))
    }
}

impl PartialEq for Origin {
 /// only compare the scheme/host/port (Origin is supposed to be an opaque identifier with equality)
}

We can also add a stringifier which strips out the path.

Thanks for contributing! Unfortunately, I'm here to tell you there were the following style issues with your Pull Request:

Commit: d48b9ce83ff6b7e1c000ee9933a43df917cd995c

Commits must be in the following format: %{type}(%{scope}): %{description}

Commit: 1e2928b789e5fc3bd7e3f3fe4a21f52a93567d96

Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/hyperium/hyper/blob/master/CONTRIBUTING.md

This message was auto-generated by https://gitcop.com

The url crate already has a Origin type. Perhaps use that one?

cool! Will .take a look!

@untitaker I don't believe it does. At least, browsing through the docs, I couldn't find one.

https://github.com/servo/rust-url/blob/66545ce19dae6d1dd7fcbce56c471e15a43a0fc3/src/lib.rs#L203
This is the correct way of handling origins (doesn't have the null thing though)

@Manishearth looks like port is required, but the spec doesn't require it.

cc @SimonSapin

@seanmonstar No port implies default port, much like URLs.
Better reference: https://tools.ietf.org/html/rfc6454
In response to your question, in particular: https://tools.ietf.org/html/rfc6454#section-4

Yes, the port number has a default based on the scheme:
https://url.spec.whatwg.org/#origin

Return a tuple consisting of URL’s scheme, its host, and its default port if its port is null, and its port otherwise.

https://tools.ietf.org/html/rfc6454#section-4

If there is no port component of the URI:
Let uri-port be the default port for the protocol given by uri-scheme.

I realize there's a default port by scheme. I should have said more. The spec for the Origin header says the port is optional. By internally using a structure that doesn't record if the port was present, re-serializing will have different output from the input.
let s = "https://rust-lang.org"
assert_eq!(s, Origin::from_str(s).unwrap().to_string())
// "https://rust-lang.org" != "https://rust-lang.org:80"

If we chose to always remove the port if it is the default, we still could change the value, since the default port may have been part of the original header.

I think the Origin type in rust-url was designed for equality testing, possibly without considering serialization or the Origin HTTP header. I’d review a rust-url PR to make a change here if you think it’s appropriate.

I don't think a change would be appropriate to Origin. This is about semantics. The representation could be nicer in that ports that equal to the default one are omitted, but it really doesn't matter. Also:
let x = Url::parse("http://example.com:80/").unwrap();
x.serialize()  // http://example.com/

Unsure if this should be addressed in rust-url. For hyper, it could be enough to define our struct like this:
struct Origin {
    origin: url::Origin,
    show_port: bool,
}

I still don't see why we need to make a distinction between implicit and explicit default ports. The flag is not needed IMO

@untitaker I'd like to agree, but I worry humans don't actually implement what the spec says (all too common).
Example: if using url::Origin, then in hyper a Origin::new("http://foo.example") would return in Origin(url::Origin("http:", "foo.example", 80)). Serializing this into a request would look like this:
GET / HTTP/1.1
Origin: http://foo.example:80

Looking in the CORS code of 2 popular nodejs libraries, I believe this would be rejected.

expressjs: https://github.com/expressjs/cors/blob/ddc7d03e12db8e74d44b73aa6136b90b2bd25640/lib/index.js#L26
hapijs: https://github.com/hapijs/hapi/blob/492e59496abcbc3d73642e5b1391bd3b8b6b1e1d/lib/cors.js#L183

They both do exact String matches, forgetting that default ports should matter as well.

I would just omit default ports during serialization. The implementations you mentioned already wrongly detect inequalities, and I think making a distinction in hyper as well would make the situation worse.
On 17 December 2015 19:49:13 CET, Sean McArthur<EMAIL_ADDRESS>wrote:

@untitaker I'd like to agree, but I worry humans don't actually
implement what the spec says (all too common).
Example: if using url::Origin, then in hyper a
Origin::new("http://foo.example") would return in
Origin(url::Origin("http:", "foo.example", 80)). Serializing this
into a request would look like this:
GET / HTTP/1.1
Origin: http://foo.example:80

Looking in the CORS code of 2 popular nodejs libraries, I believe
this would be rejected.

expressjs:
https://github.com/expressjs/cors/blob/ddc7d03e12db8e74d44b73aa6136b90b2bd25640/lib/index.js#L26
hapijs:
https://github.com/hapijs/hapi/blob/492e59496abcbc3d73642e5b1391bd3b8b6b1e1d/lib/cors.js#L183

They both do exact String matches, forgetting that default ports should
matter as well.

Reply to this email directly or view it on GitHub:
https://github.com/hyperium/hyper/pull/691#issuecomment-165545652

--
Sent from my phone. Please excuse my brevity.

Closing as inactive.

That's surprising. Which concrete change would you like to see?

@untitaker this PR has struct Origin(pub String);. The discussion in the PR suggests having an Origin that knows the scheme, host, and port (perhaps from the url crate).

Right, but it wasn't clear at all if you wanted the author to actually use
url's struct (or if you think that their impl was flawed).
On Wed, Mar 09, 2016 at 01:00:48PM -0800, Sean McArthur wrote:

@untitaker this PR has struct Origin(pub String);. The discussion in the PR suggests having an Origin that knows the scheme, host, and port (perhaps from the url crate).

Reply to this email directly or view it on GitHub:
https://github.com/hyperium/hyper/pull/691#issuecomment-194505076

It may be sufficient to use url's Origin, and in the fmt_header method, leave off the port if it is the default port.

Preparing new PR. I'll probably submit the special formatting in rust-url though.

I think the Origin type in url looks a bit different in the proposed 1.0 branch.

Ah, thanks for the hint, I was about to change some things to master...
@SimonSapin I want to to add a simple FromStr impl for Origin that just does url::Url::parse(...).map(|u| u.origin()), for the purposes of this PR. Should I wait post-1.0?

Re earlier comments, the rust-url 1.0 branch (which I hope to merge soon-ish, I still many tests and some bug fixes in setters) now implements the "ASCII serialization of an origin" and "Unicode serialization of an origin" algorithms as defined in the HTML spec. https://github.com/servo/rust-url/blob/1.0/src/origin.rs
@untitaker In what cases do you parse an origin from a string? Does a relevant specification define a parsing algorithm? Parsing as you describe would accept and ignore URL components that are not relevant to origins, e.g. http://me:secret@example.net:8080/foo?bar#baz -> https://example.net:8080. Maybe the presence of these components should be an error?

@SimonSapin I want to use rust-url's Origin type in Hyper's Origin header, so I need a way to parse it from a raw header value. You're right about extra components, this restriction could probably be applied after parsing the input as URL.

https://fetch.spec.whatwg.org/#http-origin and https://tools.ietf.org/html/rfc6454#section-7.1 both define the syntax for the Origin header. The former says it supplants the latter. They disagree in the header containing a single origin vs a space-separated list of them but they agree that one origin is scheme "://" host [ ":" port ] with each component as in URLs and without extra components like a path.
I’d recommend not using the URL parser. Instead, use this regex ^([a-zA-Z][a-zA-Z0-9.+-]*)://(.+?)(:[0-9]+)?$ (where +? is non-greedy repetition) or an equivalent hand-written parser, plus rust-url’s Host::parse for the host component.


ionic v2 run android can not support 64bit crosswalk

How to running the crosswalk 64bit application?

Hello! While we appreciate you opening an issue with us i am going to close this issue and ask that you open a new one that has the issue template filled out please. Thanks for using Ionic!


Update node version

The README recommends node 12 and the Github actions deploys the app using node 12 as well.
This version is quite old and hardly supported anymore afaik, how hard would it be to upgrade?

Just tested it locally on node 14, that seems to run fine. On node 16 I cannot do an npm ci due to a dependecy conflict, so I can upgrade to 14 first and later we can see if we can make it work for node 16 or node 18


Makefiles: Disable CGO globally

CGo is not necessary for any Cilium binaries (only proxylib), and with
the new docs builder image it's causing build issues like the following
on master for some developers:
  GEN   Documentation/cmdref
Error relocating /src/cilium/cilium: __vfprintf_chk: symbol not found
Error relocating /src/cilium/cilium: __fprintf_chk: symbol not found

Fix this by just disabling it for all targets that use $GO.

test-me-please

I guess we use it for proxylib, will need to fix that up..

test-me-please

test-me-please

test-me-please

Oh, originally I thought it was go vet but it looks like it's actually the go tests in the proxylib directory.

test-me-please

Coverage increased (+0.02%) to 45.521% when pulling 0c7f9df4bd04f79f04fc8fcad51b65ca4fe03e81 on joestringer:submit/fix-broken-master into 5ff7c51d8c58a608790c266d2de0716c36c368bd on cilium:master.

Plenty of scary-looking failures in CI, will need to investigate further:
https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/18287/

test-me-please


Fix stratisX tests

Hi @zeptin,thanks for looking into this. However I see that the X tests are still failing? Dan merged something last night that relates to how we sync from X nodes so maybe this should be merged to your branch?

A couple are still failing the CI but they all are passing locally for me.


WIP: re-organize docker cloud topics, public intro to swarm mode

First drafts of topic updates and re-organization for Docker Cloud public intro of swarm mode beta.
Signed-off-by: Victoria Bialas<EMAIL_ADDRESS>

@pkennedyr Hi Ryan, You can take a look at the first draft of the Docker Cloud swarm docs re-org here, and see what you think.
The Netlify preview under All checks have passed ^^ takes you to the top of the docs, but you can go directly to cloud swarm docs here.
The only thing missing is adding these topics to the left side TOC menu, which I can do as soon as you think these are ready for prime time.

cc: @borjaburgos @KickingTheTV

@pkennedyr @borjaburgos @KickingTheTV I've incorporated Ryan's comments on the first draft of this. Just a few questions/comments for Ryan:

Wondering if you would prefer a different screen snap for the swarms home page (docker-cloud/cloud-swarm/index.md) rather than removing it altogether - I thought you had wanted a screen snap there for the intro? If we got a picture of a Cloud account as it would appear to a new user (without the Swarm Mode toggle), would that be more useful? Or do you just not want an image there at all?

Generally, throughout the engine docs, swarm mode is lower case. But I went ahead and made this consistent throughout these Cloud docs as Swarm Mode since it seems that we are generally referring to the name of on the Docker Cloud UI, which is in fact initial caps. What do you think?

Tangent: On my own experiments with registering swarms in my Docker Cloud account,  I've run into some weird glitches; e.g., I can successfully register the swarm and connect to it, but soon after, it drops off in the sense that it's status shows as UNREACHABLE (even though the swarm is still running and reachable through the CLI). Any thoughts?

Hey @londoncalling,
Thanks for the updates - adding replies below to your earlier comments:

The Swarm mode UI is pretty bland during the beta (i.e. offers a simple list view of swarms that are registered with Cloud), so let's leave out the screenshot out for now.

Laura originally suggested referring to "Swarm Mode" (in context of Docker Cloud) as uppercase in the docs and the UI, so I'm thinking we just continue with the uppercase reference unless you see a strong reason to change.

When you register a swarm without specifying an internal_endpoint, we get the IP address from the request. So if you are in the office from your laptop, that IP address will be the router of the building and therefore when trying to contact your swarm, it fails I think you have to use some software to expose your local swarm port (like ngrok) and update the internal_endpoint att of the swarm to let DC know where to ping.

@pkennedyr that all makes sense :-) thanks for the reviews
As we discussed, next step here will be for me to add in these topics to the IA (left side menu TOC), along with further review comments and improvements.

@pkennedyr per our discussion on Friday, I've done a first pass of the following:

integrated Swarm mode topics into the IA (left side topic nav menus)
Folded these "non-Swarm mode" topics as sub-topics under the heading "Standard Cloud Node and App Management" (we can name this anything you like, just trying this on for size)

Getting Started
Managing Applications
Cloud stack file YAML

Re-factored the Cloud welcome page (About Docker Cloud) to downplay non-Swarm topics and feature Swarm mode.

Have a look at this when you get a chance, and let me know what you think, and we can go from there.

Thanks, @londoncalling - these are nice improvements!
I've added a few comments to make the delineation b/w "Swarm Mode" and "Standard Mode" a bit more clear. Feel free to have a look and let me know if you have any comments/questions.

@pkennedyr @mstanleyjones @johndmulhausen (docs cc'ed as a heads-up for  docs infrastructure point #2 below)
Hi Ryan, Thanks, great comments, I think it's getting there.
In this round:

incorporated your review comments

Cloud Home page diagram better clarifies Swarm mode vs. Standard mode (using consistent wording and structure)
Same with left nav menus
Removed "free" statement from the Swarm mode Beta banner at the top of those pages

Added a new type of "advisory" called previewdocs which uses previewflag in the topics that need it. This enables us to use a green bar message at the top of our Swarm Mode Beta docs instead of the yellow bar. (We use the yellow bar banners in other docs like Toolbox, Kitematic, and old stand-alone Swarm to indicate legacy docs, so I didn't want to cue people on a Beta with that subliminal idea. I figured green for go, yellow for slow down/old stuff.)

A good place to start this review on the Netlify preview:

Cloud Home topic with diagram

Swarms in Docker Cloud overview page

Thanks, @londoncalling. Applied a few other comments:

Let's change the "Manage Infrastructure" section name to "Manage Infrastructure (Standard Mode)" and move it below "Manage Swarms (Beta Swarm Mode)". The current "Manage Infrastructure" section is highly specific to the standard mode functionality and most of the content doesn't apply to Swarm mode.
Images appear to be missing on the following pages:
-- Builds and images overview (docker-cloud/builds/)
-- Docker Cloud repositories (docker-cloud/builds/repos/)
re: /orgs page, I don't believe a Read permission option is available for Swarms (only Admin) ... @fermayo can you confirm? If so, please remove Read and change the Admin definition to: "View swarms, manage swarms, add users"

@pkennedyr
Thanks, I pushed more changes just now:

"Manage Infrastructure" --> "Manage Infrastructure (Standard Mode)" and moved to below "Manage Swarms (Beta Swarm Mode)" in the left nav menu. Also renamed on the Welcome page diagram, but I haven't moved it in the table yet. Not sure about how to restructure that table any more or if it's needed.

I do see the missing images on Netlify preview but I haven't touched the images or the calls to them, and they render on local builds. Let's see if this doesn't iron itself out, otherwise I'll have another look tomorrow.

I went ahead and changed the description of the permissions on Swarms per your comments, and can modify more if needed.

That's all for now, we can re-group tomorrow on whatever else needs to be done.

Okay, I'm stumped by the image display problem in docker-cloud/builds and docker-cloud/builds/repos (same image not displaying in both files). It is still not showing up on the Netlify preview, but it is there in file in the branch (https://github.com/londoncalling/londoncalling.github.io/blob/cloud-docs-with-swarm/docker-cloud/builds/index.md). I'll have a look tomorrow.

Re: the missing image , I'll fix it later today by just creating a new one with a different name .

Thanks, @londoncalling. The latest changes look great.
Re: the missing images, I'm seeing random examples (e.g. on the Welcome screen), so not sure what is causing this either. I think we're good to go, once these are addressed
Thanks again and appreciate all your help!

Applied a couple content updates to docker-cloud/ diagram (i.e. swarm mode referenced the same content as the infrastructure section).

Hi @pkennedyr ,
Okay, I think i've incorporated all your latest comments:

Modified descriptions of Swarm Mode and Standard Mode on the Cloud Welcome page. (Yes I had mistakenly copied content from one place in that table to another and forgot to re-do it 😕  .. Good catch 🙂 )

Fixed repository image to render properly in "build" topics:  Builds and images overview and Docker Cloud repositories
(The image itself on GitHub repo must have been corrupted. I took a new screen snap and now it renders properly with the same image name.)

I think we are in good shape for tomorrow, and good to go. Just let me know if you and your team have any other comments, and when you want me to publish these docs.
Vicky

LGTM, merging to publish
@pkennedyr


Moved all tests into a separate test package.

The tests are discoverable in their own package and find the objects in the metroscope package to run on local with no issues.

Yup, that worked in the automated test builds too.
Time to try in prod.


Problem with non-acsii userprofile name on Windows (7)

Problem with .vcxproj file. node-gyp writes it in system codepage (non-utf8), while xml prolog specifies utf-8 in encoding attribute. This causes error while trying to build the project.
My userprofile contains cyrillic characters, so I get non-ACSII characters in paths.

@MattouFP
your "Fix encoding problems in easy_xml.py" (https://github.com/TooTallNate/node-gyp/pull/554):
+ # Fix encoding
+ xml_string = unicode(xml_string, 'latin-1').encode(encoding)

is not working with cyrillic symbols :disappointed:
for correct work in this case  :ru: need another patch:
+ # Fix encoding for cyrillc symbols
+ xml_string = unicode(xml_string, 'Windows-1251').encode(encoding)

This is not good solution in whole. Need a change solution provider maybe :interrobang:

@knyazhe1, It not helps me...=(
Windows 8.1 x64, VS 2013 sp4
Can't install loopback:
http://loopback.io/getting-started/
Output:
C:\Users\Артем\AppData\Roaming\npm\node_modules\strongloop\node_modules\strong-s
upervisor\node_modules\heapdump>if not defined npm_config_node_gyp (node "C:\nod
ejs\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.
js" rebuild )  else (rebuild)
Сборка проектов в этом решении по одному. Чтобы включить параллельную сборку, до
бавьте параметр "/m".
C:\Users\Артем\AppData\Roaming\npm\node_modules\strongloop\node_modules\strong-
supervisor\node_modules\heapdump\build\addon.vcxproj(47,46): error MSB4025: не
удалось загрузить файл проекта.  System Windows_NT 6.3.9600
gyp ERR! command "node" "C:\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\
bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\Users\Артем\AppData\Roaming\npm\node_modules\strongloop\node_mod
ules\strong-supervisor\node_modules\heapdump
gyp ERR! node -v v0.12.2
gyp ERR! node-gyp -v v1.0.3
gyp ERR! not ok
\

I.m from this issue https://github.com/TooTallNate/node-gyp/issues/404

Finally fixed!
@MattouFP, @knyazhe1, thx for the solution!
My problem was in editing of the wrong file - easy_xml.py on Roaming folder (-g flag in install), but packet file runs node-gyp in Node.js installation directory.

I believe this issue has to be re-opened.
Unfortunately, the fix provided in 39a06bc affects only Western (Latin-1) releases of Windows, as Cyrillic, Greek, Turkish, Hebrew, Arabic, Baltic and Vietnamese releases use different ANSI code pages.
There is, fortunately, a universal WinAPI method (available on Windows 2000 or higher) for detecting the default ANSI code page, GetACP(), used internally by the locale Python package. Using locale.getdefaultlocale()[1] instead of "Latin-1" fixes this issue on Cyrillic (Russian) Windows 8.1.

@Chudesnov Could you make it into a pull request, please? As it is obvious from the existence of this issue, Nathan doesn't have required skills to support this project. Even with such a deep detail on implementation it's quite unlikely this issue will get fixed.

Still valid. Merge https://github.com/nodejs/node-gyp/pull/945 to fix it please


Release 3.2 not available on Dockerhub

Is there an existing issue for this?

[X] I have searched the existing issues

Kong version ($ kong version)
3.1
Current Behavior
3.2 was released:
https://github.com/Kong/kong/releases/tag/3.2.0
However, I am not finding it available on Dockerhub and attempting to pull the image results in a failure.
Expected Behavior
The ability to pull and use Kong 3.2
Steps To Reproduce

docker pull kong:3.2
You'll find the above doesn't work

Anything else?
No response

same issue

We ran into build issues with 3.2 so that may not be available.
We failed forward and released 3.2.1 and it is available on Kong's Docker repo: https://hub.docker.com/r/kong/kong/tags?page=1&name=3.2.1.
Official image will be published soon, they generally lag behind by a few days.
Apologies for the inconvinience.

Few days passed, the 3.2.1 still not available on https://hub.docker.com//kong/tags
Is there any difference between DOCKER OFFICIAL IMAGE(https://hub.docker.com//kong/tags) and VERIFIED PUBLISHER image(https://hub.docker.com/r/kong/kong/tags)?

The build process differs just a bit but they are otherwise the same. Same license, the same bits of code.

Any idea when official image 3.2 could be available? We use both amd and arm platforms, and the latter is not available from the verified publisher.

Once this PR merges and Docker build is completed: https://github.com/docker-library/official-images/pull/14273


Add button to show/hide calendar

Research and implement button to be able to show or hide the calendar on the page.

donzo


use the RUNTIME_VERSION as it was before

as mentioned in this PR https://github.com/snowdrop/spring-boot-configmap-booster/pull/72#issuecomment-463760532 reverting the RUNTIME_VERSION change back

@metacosm please have a look

Rejected based on latest discussions.


Alamofire and cookies

Hi everyone. I know this is not the place for. But my question is very simple. I search stackoverflow but i cant found working example.
I want get cookie with alamofire request. And save this cookie on userdefaults or keychain. And i want use this cookie with new alamofire request. Any example code for this?

http://stackoverflow.com/a/34193782/1342462


Building a sample with --aot-only does not detect an application startup failure

If the application starts but an exception is thrown, it is not reported. We get an OK instead.

Fixed by cfb8e0dbaf28358aba719003a0346e03e6f1fead.


Stats on Dashboard not updating (frozen)

The stats on Dashboard are not updating (refreshing), I also can't see any workers, everything is set to the minimum in the statistic page (5sec, 5 sec, 1min) and this is what I still see after 10 mins http://i.imgur.com/exMjnJb.png
I believe this happened after I upgraded to the latest version, After some investigation I get this when I try to run  run-statistics.sh:
PHP Fatal error:  Call to undefined method mysqli_stmt::get_result() in /var/www/html/MPOS/include/classes/base.class.php on line 174
can you please assist me. Thank you.

That's not an MPOS issue. You do not run mysql-nd on your server. See requirements and quick start guide.
These lines are called from upstream mysqlnd and cause your issue: https://github.com/MPOS/php-mpos/blob/master/include/classes/base.class.php#L173-L174

yes I figured that out and fixed it, but stats are still not working !! and I can't seem to understand what is wrong, in fact I will retract what I said about upgrading causing this issue, because an upgrade in another pool didn't cause this problem.
so any other suggestions ?

Check if your API is blocking it. By default, requests to the API are throttled by IP. You can change the settings in your security.inc.php file.
Also check you don't have clashing memcache keys. And of course check any custom code you may have added.
Since it's only for a single site, it has to be a setup issue. Can't go through all options as you may be able to imagine, but those would be the ones I'd check for.

Thank you, Fixed.. it was memcache as you suggested.


retain cycle

Follow code case retain cycle:

@property (nonatomic, strong) WKWebViewJavascriptBridge *bridge;

-(WKWebViewJavascriptBridge *)bridge{
    if (!_bridge) {
        WKWebViewJavascriptBridge *bridge = [WKWebViewJavascriptBridge bridgeForWebView:self.webView];

        [bridge setWebViewDelegate:self];
        _bridge = bridge;
    }
    return _bridge;
}

Is my code wrong or WKWebViewJavascriptBridge has this bug?

I have the same issue.Did you solve the problem?

Also having the same issue. Any updates?

I fixed this by clearing the reference to the bridge when I no longer need it.

@Henry519  No yet，I do the same way like @azsuth  said

(void)viewWillDisappear:(BOOL)animated{
[super viewWillDisappear:animated];
[self.bridge setWebViewDelegate:nil];
self.bridge = nil;
}
You can do this!

(void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
if (self.bridge) {
[self.bridge setWebViewDelegate:self];
}
}

(void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[self.bridge setWebViewDelegate:nil];
}
I think it will be better！

I believe this has been fixed. Please update to latest version and check. Feel free to reopen.


Default anonymous user doesn't pass artifactory_user validation

Describe the bug
My artifactory cloud installation generated an anonymous user by default.  If I try to adopt this user into terraform, it imports successfully but then fails validation on apply because it doesn't have an email.
Requirements for and issue

[x] A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)

Import the user anonymous as below, then run an apply without adding/setting the email.  Note that it fails until you add one, even if there is no email set in the UI.
resource "artifactory_user" "anonymous" {
  email             =<EMAIL_ADDRESS># this must be set, even though by default there is no value
  name              = "anonymous"
  profile_updatable = false
}

[x] Your version of artifactory (you can curl it at $host/artifactory/api/system/version
Cloud
[x] Your version of terraform
1.0.11

Expected behavior
Apply should work as imported.  Either allow me to omit the email on anonymous or maybe create an artifactory_anonymous_user resource that doesn't require one.

On the user creation page:
ui/admin/management/users/new email is a required field. So, RT created an invalid user - I mean, @alexhung it's possible it's accepted through curl/api but I don't think a blank email will fly. If not, the question is what to do about it? get the admin email somehow and use that?

'anonymous' is a special, pre-defined user in Artifactory. The UI hides the username/email fields for that user. The API does not have any provision to manipulate an anonymous user either, since email is a required attribute in the payload schema.
Given these, I think the idea of a separate artifactory_anonymous_user resource to manage the anonymous user has merit. Can we make that resource 'read-only' somehow, i.e. only read returns data, and all other operations return 200/204? (Actually I think we can delete an anonymous user)

You can create the resource and declare all fields as computed. I think that would do the trick

I was able to update the email with the provider. It shows in the UI now.
I'm not sure that's consistent with it being read only as you've described.
On Tue, Jan 11, 2022, 12:52 PM Christian Bongiorno @.***>
wrote:

You can create the resource and declare all fields as computed. I think
that would do the trick
—
Reply to this email directly, view it on GitHub
https://github.com/jfrog/terraform-provider-artifactory/issues/265#issuecomment-1010214294,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFF3ANJQYESN4EIAMZZSP3UVRU4JANCNFSM5LURMMZQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

@jcogilvie So is this still an issue?

Yes. The field is required even after importing a valid user (anon) which
doesn't have the field.
Setting it will 'take' iirc, but it's still an inconsistency in that if I
import the server's present configuration, I can't perform an apply.
(I think it ought to reject my attempt to add an email to anon, too,
probably.)
On Thu, Jan 20, 2022, 2:58 PM Alex Hung @.***> wrote:

@jcogilvie https://github.com/jcogilvie So is this still an issue?
—
Reply to this email directly, view it on GitHub
https://github.com/jfrog/terraform-provider-artifactory/issues/265#issuecomment-1017870532,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFF3APKGGKBZAIWAJHDPV3UXBSPFANCNFSM5LURMMZQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

@alexhung - so, to dove tail this with passwords, we would have 3 resources:

anonymous_user
managed_user
unmanaged_user

This isn't directly related to the problem of passwords but is related to users.
My vote is to create a resource for this where all fields are computed

@jcogilvie FYI, I'm working on this and I've added a new resource artifactory_anonymous_user where all attributes are optional. Importing the anonymous user from Artifactory involves the following HCL:
resource "artifactory_anonymous_user" "anonymous" {
}

I've also fixed how we handle the TF state for groups which @maheshjfrog is also working on for #191. This means terraform plan after importing will show no state drift.
Of course if you alter the artifactory_anonymous_user attributes then all bets are off!


Add assisted installer crs

Fixes: https://issues.redhat.com/browse/ACM-4137

@JakobGray for approval. Thank you.

/cherry-pick backplane-2.2
This needs to be back-ported to 2.2 to fully close the issue. Currently this is only in backplane-2.3


doc: add minutes for meeting 25 March 2019

@Myles, I've never had to do that in the Node.js repos for people to push changes. I wonder if we need to adjust something in the new org?

@mhdawson you might just need to set it once in this new org?

@openjs-foundation/bootstrap  I think this can land if we get a few approvals.


Pass all issue from letsvalidate.com site

We need pass all issues on https://www.letsvalidate.com/?url=http://www.ossboard.org.

[ ] Meta description not found or empty.
[ ] Character set not found.
[ ] <html> tag should have an explicit lang attribute.
[ ] App icons for mobile devices not found.
[ ] Site map(s) not found at http://www.ossboard.org/sitemap.xml.
[ ] Content is not gzipped.
[ ] At least one of og:url, og:title, og:description, and og:image meta properties is missing.
[ ] At least one of twitter:card, twitter:title, twitter:description, and twitter:image meta properties is missing.

I am new but I'd like to help. I think I've located the solutions for most of these.

@morrme awesome, if you have any questions feel free to ask 👍

Sure.  So far:

The meta tags can be created with the og: tags , and I can get that from the current info on the site.

I can use /apps/web/assets/images/header-logo.png for the og:image tag (and twitter:image )  if that works for you.

The character set and lang attributes are quick edits

A site map can be generated via a web tool like https://www.xml-sitemaps.com/  .

Do you have a preferred app icon? Perhaps a larger version of the favico?


Sometimes I get "cannot find name foo" but it all still works.

For example:

However, navigating around (f.e. running Go To Definition on the missing object, or other actions, not sure exactly) fixes the issue and those message go away. Also not sure how the messages start showing up.
All in all, everything seems to work despite the messages sometimes being there.

Wish I knew how to. It seems a bit random as to when the message appears. I'll pay attention.


Any plans for backporting to api 14+?

I haven't checked the library's internal code but have seen the demo app & its good!
I need the same type of functionality for my App but it supports 14+.
so any plans for backporting to 14+ or any Info. that can be helpfull for me to backport?

Hi. No there are no plans of supporting backwards API's.
You are welcome to fork it and make your own version


Modeling operations become slow in large diagram

Describe the bug
Working on a large BPMN diagram there is a slowness when completing modeling actions, cf. large-diagram.bpmn.txt.

Steps to reproduce

Open large-diagram.bpmn.txt
Do any modeling operation
Perceive slowness, editor unresponsive (> 2s of wait time)

Expected behavior

[ ] No matter how big a diagram is and what the user does, the editor remains fully responsive within reasonable boundaries (sub-second at best).
[ ] Internal: As a developer I'm able root cause performance issues
[ ] Fix identified levers

[ ] https://github.com/bpmn-io/diagram-js-minimap/issues/81 (130ms)
[ ] Verify element template lint rule integration (130ms)
[ ] Consider linting improvements (130ms)
[ ] Consider marker updating improvements
[x] https://github.com/camunda/camunda-modeler/issues/4335
[x] https://github.com/bpmn-io/diagram-js/pull/910
[x] https://github.com/bpmn-io/bpmn-js/pull/2182

Environment

OS: Linux
Camunda Modeler Version: v5.23.0
Execution Platform: Camunda 8
Installed plug-ins: None

Additional context
Came up via internal feedback.

TODO

[ ] Expose metrics that allow us to debug such slowness
[ ] Trace performance issues

Analysis, executing space tool, time until editor is responsive again:

on demo.bpmn.io: ~1 second
on Desktop Modeler: ~3 seconds (93 errors detected)
on Web Modeler: ~8 seconds (963 errors detected)

Work Log
Updated core modeling dependencies to use on board (browser) facilities for critical operations (clear, closest) - https://github.com/bpmn-io/diagram-js/pull/910, https://github.com/bpmn-io/bpmn-js/pull/2182.
Simplifying clear was unfortunately a failed experiment.

Detailed Analysis
Following up on the shallow analysis, here are some more details; using
large-diagram.bpmn.txt as a test subject in different environments.
demo.bpmn.io (stock bpmn-js)

Snappy experience
Make space (single frame): 480ms

Actual computation: 300ms
marker updating 70ms (remove dragging) + 60 ms (activate selection)

Desktop Modeler
Uses the minimap which adds a 30% (!) toll on rendering :arrow_right: https://github.com/bpmn-io/diagram-js-minimap/issues/81; linting happens outside of update cycle, not the fastest, but manageable.

Feels slightly slower
Update total: ~700ms
Make space (single frame): 480ms

Actual computation: 300ms
minimap updating: 140ms
marker updating 90 ms + 100 ms

Lint (next frame): ~130ms

Web Modeler
Uses the minimap and many custom extensions, resulting in a massive performance blow. The diagram can barely be edited. Kapa.ai integration is responsible for more than 50% of the performance hit, linting everything three times completes the picture.

Really slow
Update: total 7s
Make space (single frame): 4.8s

Actual computation: 1s

minimap updating: 250ms
marker updating: 200 ms + 200ms

Kapa.ai widget computation: 2.6s
Linting (round 1, sync): 700ms

elementTemplateLintRule: 130ms
actual linting Linter#lint: 300ms
storing lint results: 70ms
another Kapa.ai update: 143ms

Linting (round 2, next frame): 700ms
Linting (round 3, next frame): 700ms

Done. We can open individual issues.


Update node version from 10 to 12

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

Superseded by #11, but thank you for the PR. Apologies - it seems we missed it at the time (and the project has recently been moved GH organisations).


Inconsistent behavior between join and joinWith leading to malformed on clause

$realFullColumnName may be either table.field or schema.table.field so the correct $realColumnName is always the last field of the exploded array and not the second.

Failing checks seem to be related to 5d5825b61d2432dbb03467d08db71fb116bd8c63 if I see this correctly?


freezing on linux

The entire OS freezes up for me. Happens on both manjaro and ubuntu (server)
After downloading a few models the os freezes up.

so it appears to be using all my memory so OS freezes. is there anyway to limit the amount of memory used by openplayground run?

works now when changing system-d config


Update internal type to adopt idl change

What changed?

Why?

How did you test it?
unit test

Potential risks

Release notes

Documentation Changes

Pull Request Test Coverage Report for Build 0186cd94-2ab8-49a5-943b-93f637de26d2

2 of 9 (22.22%)  changed or added relevant lines in 3 files are covered.
123 unchanged lines in 16 files lost coverage.
Overall coverage decreased (-0.01%) to 57.021%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

common/types/mapper/thrift/shared.go
0
2
0.0%

common/types/shared.go
0
5
0.0%

Files with Coverage Reduction
New Missed Lines
%

common/task/fifoTaskScheduler.go
2
87.63%

common/task/weightedRoundRobinTaskScheduler.go
2
89.12%

common/types/mapper/thrift/shared.go
2
63.17%

service/history/handler.go
2
47.28%

service/matching/matcher.go
2
91.46%

common/persistence/nosql/nosqlplugin/cassandra/workflow.go
3
59.1%

common/persistence/statsComputer.go
3
94.64%

common/types/history.go
4
45.35%

service/history/historyEngine.go
4
68.9%

service/history/task/fetcher.go
4
91.24%

Totals

Change from base Build 0186cd91-9a40-4c79-8fd1-c161f35ef0cd:
-0.01%

Covered Lines:
85217

Relevant Lines:
149448

💛  - Coveralls


[ja] Switch liveness image to multi-arch agnhost container image

ja equivalent for https://github.com/kubernetes/website/pull/45837

/retitle [ja] Switch liveness image to multi-arch agnhost container image

/hold
Wait until the equivalent English PR https://github.com/kubernetes/website/pull/45837 has been merged first.

/unhold
Referenced PR https://github.com/kubernetes/website/pull/45837 has now been merged

LGTM

Thank you!!
/cc
/lgtm
/assign nasa9084

/approve


Скласти таймлайн

Скласти список всіх (важливих) життєвих подій, визначних дат, досягнень, періодів, що дали приємний і неприємний досвід, тощо. В цьому конкретному випадку довгих списків не буває, натомість бувають погано згорнуті, тому пакуємо сюди все підряд, а про "лишні" події можна буде промовчати пізніше. Список повинен бути систематизованим і посортованим в такий спосіб, щоб читач швидко зрозумів "паттерн" і міг легко орієнтуватись в просторі і часі цього резюме

Experience

Kingdom of the The North | Winterfell

Warden of the North | 304 AL-Present

Participated in strategic talks regarding the threat of the White Walkers and the light King.

Used personal charm to strengthen alliance with Queen Danacrys Targaryen.

King in the North | 303 AL- 304 AL

Led a coalition of over 500.000 Northerners and Free Folk to victory against House Bolton at the Bartle of the Bastards.

Forged an alliance with Danacrys Targaryen, securing access to over 20.000 lbs of  Dragonglass reserves beneath Dragonstone.

Led expedition to capture a wight, in an effort to build consensus regarding the existence of the Night King.

Restored Stark rule and began rebuilding the North after its devastation during the War of the Five Kings.

The Night's Watch | Castle Black

Lord Commander | 302- AL- 303 Al

Negotiated improved relations between the Free Folk and the North, Offering land in exchange for protections.

Arose from the dead after being assassinated by a nativist faction of the Night's Watch.

Rescued a band of Free Folk from Hardhome where they were besieged by The Army of the Dead.

Brother of the Nights Watch | 300 AL- 302 AL

Organized the defense of Castle Black and withstood massive assault by Mance Rayder's coalition of Free Folk.

Defeated a band of Night's Watch mutincers, avenging the death of Lord Commander Jeor Mormont.

Infilerated the forces of Mance Rayder and gained valuable intelligence on the Wilding army.

Steward to Lord Commander Jeor Mormont | 298 AL-300 AL

Chosen as Steward to Lord Commander Mormont - an indication of leadership potential.

Killed a wight that was attacking Commander Mormont. Received Longelaw, a Valyrian steel blade as reward.

Assisted in cooking, cleaning, hunting, and message delivery which was vital to Castle Black's operations.

Experience

Kingdom of the The North | Winterfell

Warden of the North | 304 AL-Present

Participated in strategic talks regarding the threat of the White Walkers and the light King.

Used personal charm to strengthen alliance with Queen Danacrys Targaryen.

King in the North | 303 AL- 304 AL

Led a coalition of over 500.000 Northerners and Free Folk to victory against House Bolton at the Bartle of the Bastards.

Forged an alliance with Danacrys Targaryen, securing access to over 20.000 lbs of  Dragonglass reserves beneath Dragonstone.

Led expedition to capture a wight, in an effort to build consensus regarding the existence of the Night King.

Restored Stark rule and began rebuilding the North after its devastation during the War of the Five Kings.

The Night's Watch | Castle Black

Lord Commander | 302- AL- 303 Al

Negotiated improved relations between the Free Folk and the North, Offering land in exchange for protections.

Arose from the dead after being assassinated by a nativist faction of the Night's Watch.

Rescued a band of Free Folk from Hardhome where they were besieged by The Army of the Dead.

Brother of the Nights Watch | 300 AL- 302 AL

Organized the defense of Castle Black and withstood massive assault by Mance Rayder's coalition of Free Folk.

Defeated a band of Night's Watch mutincers, avenging the death of Lord Commander Jeor Mormont.

Infilerated the forces of Mance Rayder and gained valuable intelligence on the Wilding army.

Steward to Lord Commander Jeor Mormont | 298 AL-300 AL

Chosen as Steward to Lord Commander Mormont - an indication of leadership potential.

Killed a wight that was attacking Commander Mormont. Received Longelaw, a Valyrian steel blade as reward.

Assisted in cooking, cleaning, hunting, and message delivery which was vital to Castle Black's operations.

Languages

Languages

Dothraki Valyrian Common

Languages

Languages

Dothraki Valyrian Common

Skills and interests

Weapon: Longclaw-Valyrian Steel Blade

Pets: Ghost(Direwolf)

Supernatural: Can Rise From the Dead

Skills and interests

Weapon: Longclaw-Valyrian Steel Blade

Pets: Ghost(Direwolf)

Supernatural: Can Rise From the Dead

Strengths

Self-resurrection and recovery

Army and battle-force acquisition

Diplomacy/gaining trust of allies

Deconstructing/evaluating war strategies

Strengths

Self-resurrection and recovery

Army and battle-force acquisition

Diplomacy/gaining trust of allies

Deconstructing/evaluating war strategies

Accomplishments

Killed a While Walker (just as shocked as you)

Rose from the dead (we will see how it pans out)

998th  Lord Commander

Cared for and raised a wolf (fed, castle trained, etc.)

Accomplishments

Killed a While Walker (just as shocked as you)

Rose from the dead (we will see how it pans out)

998th  Lord Commander

Cared for and raised a wolf (fed, castle trained, etc.)

Education

Winterfell | 285 AL - 298 Al
Student of Maester Luwin & Ser Rodrick Cassel

Trained in various arms including bow and arrow, longsword, and close combat
Received a Highborn education studing statecraft, oration, military strategy, and Westerosi History

Education

Winterfell | 285 AL - 298 Al
Student of Maester Luwin & Ser Rodrick Cassel

Trained in various arms including bow and arrow, longsword, and close combat
Received a Highborn education studing statecraft, oration, military strategy, and Westerosi History


dendrite: 0.10.1 -> 0.10.3

Description of changes
I don't know if the race condition in tests still holds so let's find out.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

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

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

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

[x] Fits CONTRIBUTING.md.

I don't know if the race condition in tests still holds so let's find out.

There's, of course, a chance that it could pass in OfBorg but fail in Hydra because of the flaky tests.
Based on upstream's CI status, though, let's give it a shot.

Thanks for the quick merge!


The liveness probe will fail when the machine’s memory usage is high

Environmental Info:
K3s Version:

k3s version v1.29.2+k3s1 (86f10213)
go version go1.21.7
Node(s) CPU architecture, OS, and Version:

Linux xxg-tsgx-39 5.17.15-1.el8.x86_64 #1 SMP PREEMPT Wed Jun 15 02:07:24 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Cluster Configuration:

1 servers
Describe the bug:

When the machine’s memory usage exceeds 85% (despite there still being sufficient memory for k3s to allocate), the pod may fail the liveness probe, displaying the error message ‘Get “http:xxx”: context deadline exceeded (Client.Timeout exceeded while awaiting headers)’. However, when using curl to test the service simultaneously, it can provide the correct response.
Steps To Reproduce:

Installed K3s:
k3s.io/node-args": "["server","--kubelet-arg","kube-reserved=memory=2Gi","--kubelet-arg","system-reserved=memory=32Gi","--kubelet-arg","sync-frequency=1s","--kube-apiserver-arg","event-ttl=48h0m0s","--flannel-backend","none","--node-name","localhost","--disable-helm-controller"]
reproduce:
When a pod with a qosclass type of BestEffort consumes a large amount of memory, causing the machine’s memory usage to exceed 85% but not triggering the k3s eviction conditions or reaching the k3s oom limit, we observe the situation of the pod using the liveness probe. An error message ‘Get “http:xxx”: context deadline exceeded (Client.Timeout exceeded while awaiting headers)’ will appear.
Expected behavior:

The error message ‘Get “http:xxx”: context deadline exceeded (Client.Timeout exceeded while awaiting headers)’ won't appear when the machine’s memory usage to exceed 85% but not triggering the k3s eviction conditions or reaching the k3s oom limit
Additional context / logs:

3h25m       Warning   Unhealthy                pod/metrics-server-67c658944b-rt25v                              Readiness probe failed: Get "https://<IP_ADDRESS>:10250/readyz": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
3h24m       Warning   Unhealthy                pod/metrics-server-67c658944b-rt25v                              Liveness probe failed: Get "https://<IP_ADDRESS>:10250/livez": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
3h17m       Warning   Unhealthy                pod/metrics-server-67c658944b-rt25v                              Liveness probe failed: Get "https://<IP_ADDRESS>:10250/livez": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
3h17m       Warning   Unhealthy                pod/metrics-server-67c658944b-rt25v                              Readiness probe failed: Get "https://<IP_ADDRESS>:10250/readyz": context deadline exceeded
3h17m       Warning   Unhealthy                pod/metrics-server-67c658944b-rt25v                              Readiness probe failed: Get "https://<IP_ADDRESS>:10250/readyz": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
3h17m       Warning   Unhealthy                pod/metrics-server-67c658944b-rt25v                              Readiness probe failed: Get "https://<IP_ADDRESS>:10250/readyz": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
3h17m       Warning   Unhealthy                pod/coredns-5f4f9b8989-gxk68                                     Liveness probe failed: Get "http://<IP_ADDRESS>:8080/health": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
3h17m       Warning   Unhealthy                pod/coredns-5f4f9b8989-gxk68                                     Readiness probe failed: Get "http://<IP_ADDRESS>:8181/ready": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

I don't see that this is an issue with k3s itself, or something that we can fix in this project. I'm not sure what we're supposed to do if the node lacks sufficient resource such that the workload becomes unresponsive, or the kubelet is unable to complete the request in a timely manner due to resource contention with other processes.


refactor(store): finish migration to redux-toolkit

This PR continues #594
The Tasks store has been migrated to RTK and now all the codebase is using redux toolkit

I think the problem is solved now :)

Looks all good :D


Configuration API for Thing name, MQTT username, and password

In production, customer firmware won’t read the device Thing name, MQTT username, and password (if any) from static strings in the code. Instead, elements such as those will be read from configuration (i.e. separate area of flash; EPROM; or etc.). We need to:

Define a configuration storage interface
Reference it from our other libraries.
Port it to a handful of representative platforms, including embedded Linux and at least two MCU architectures.
If secure storage is available on the developer board or platform in question, store confidential configuration elements such as the MQTT password there.
Not count solely on static analysis tools to find buffer overflows in our various serialization code (for example, Jobs and MQTT), since dynamic configuration values will be defined after an embedded module has been deployed.

Hi everyone,
I feel the need for a feature like this. I want to use the serial number saved in EEPROM as Thing Name.
What are the plans for this feature to be included in the project?
Thanks in advance


multiple scanning issue

seems like i can only have a max of two scans going? i tried to open a third one and the 2nd scan stop showing pokemon but the third one does.

I'm with 6 accounts, the scan is so fast now, radius 15 scans in less 5 minutes

ah okay, guess i need an account for every scan, thanks thig

@pocketq10 , radius 15 scans in less 5 min? wow that was fast.  I need 10 min for radius 12 scan.

More accounts = Better coverage + speed(with diminishing returns)

how multiple account thing works? i have 2 accounts. How can i use 2 scan at same time at different points? Please suggest.

Manojrajput I found a small bug and I'll report, but that's how: From the home screen you put latitude and longitude, right? When you start, you change the marker once place, the accounts will separate and scan two places at same time, as the budy said, more accounts, faster and more areas are covered. Sry my english, 50% google translator

i tried as you said but it is still not working. May be i am doing something wrong. Anyway thanks for your help...


Video Html Problem?

What should we do to view videos in html?

Use the Stream class.. follow example example/stream-video.php for more detail
For the video to play in html, make sure you use the streamer url in video tag attribute source, instead of direct link to the tiktok video.

Can you help me how to integrate this video into my own html design?


Please, make sure to create a local directory named photos.
docker run -i -t --rm -v "$(realpath photos)":/photos simaofsilva/noip-renewer:debug

On a regular run, it creates 4 browser prints. Image 2 must be a print of the login form filled with your credentials; image 3 prints the NoIP dashboard and image 4 must print the page with the domains. Can you try it and check where the errors are happening?

ok, I have 4 pictures and I think this is the line that is causing the error:
https://github.com/simao-silva/noip-renewer/blob/3fc14a6645fb7045ade52cf4538e23fe6167ec74/renew.py#L113

That new page could certainly be an issue. Currently, I do not have any domains to be renewed so solving this will have to wait.

Did you have experienced that behaviour another time?

No but this is my first account on noip.com and I think this is the cause of the problem.
This window pops up only on fresh accounts and after clicking the button it doesn't appear again.

I have added a note in the README about this. I will close now.

This happens to OLD account, too
you need to click the No thanks button
if button.text == "No thanks, just renew my free hostname" or translate(button.text) == "No thanks, just renew my free hostname":
button.click()

The button element is:
No thanks, just renew my free hostname


Update terminology from margin to perpetual

@jelysn software upgrade tested in localnet successfully:
6:11PM ERR CONSENSUS FAILURE!!! err="UPGRADE \"v0.29.0\" NEEDED at height: 5511389: " module=consensus stack="goroutine 46 [running]:\nruntime/debug.Stack()\n\truntime/debug/stack.go:24 +0x64\ngithub.com/cometbft/cometbft/consensus.(*State).receiveRoutine.func2()\n\tgithub.com/cometbft/cometbft@v0.37.2/consensus/state.go:732 +0x44\npanic({0x108000140, 0x14008d2bc70})\n\truntime/panic.go:884 +0x204\ngithub.com/cosmos/cosmos-sdk/x/upgrade.BeginBlocker(_, {{0x1084e6e70, 0x140002f0120}, {0x1084fd1e0, 0x140089f08c0}, {{0xb, 0x0}, {0x1400b597100, 0xd}, 0x5418de, ...}, ...}, ...)\n\tgithub.com/cosmos/cosmos-sdk@v0.47.4/x/upgrade/abci.go:78 +0xc28\ngithub.com/cosmos/cosmos-sdk/x/upgrade.AppModule.BeginBlock(...)\n\tgithub.com/cosmos/cosmos-sdk@v0.47.4/x/upgrade/module.go:161\ngithub.com/cosmos/cosmos-sdk/types/module.(*Manager).BeginBlock(_, {{0x1084e6e70, 0x140002f0120}, {0x1084fd1e0, 0x140089f08c0}, {{0xb, 0x0}, {0x1400b597100, 0xd}, 0x5418de, ...}, ...}, ...)\n\tgithub.com/cosmos/cosmos-sdk@v0.47.4/types/module/module.go:562 +0x170\ngithub.com/elys-network/elys/app.(*ElysApp).BeginBlocker(...)\n\tgithub.com/elys-network/elys/app/app.go:1338\ngithub.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).BeginBlock(_, {{0x140098cd7c0, 0x20, 0x20}, {{0xb, 0x0}, {0x1400b597100, 0xd}, 0x5418de, {0x35191420, ...}, ...}, ...})\n\tgithub.com/cosmos/cosmos-sdk@v0.47.4/baseapp/abci.go:196 +0x674\ngithub.com/cometbft/cometbft/abci/client.(*localClient).BeginBlockSync(_, {{0x140098cd7c0, 0x20, 0x20}, {{0xb, 0x0}, {0x1400b597100, 0xd}, 0x5418de, {0x35191420, ...}, ...}, ...})\n\tgithub.com/cometbft/cometbft@v0.37.2/abci/client/local_client.go:283 +0x108\ngithub.com/cometbft/cometbft/proxy.(*appConnConsensus).BeginBlockSync(_, {{0x140098cd7c0, 0x20, 0x20}, {{0xb, 0x0}, {0x1400b597100, 0xd}, 0x5418de, {0x35191420, ...}, ...}, ...})\n\tgithub.com/cometbft/cometbft@v0.37.2/proxy/app_conn.go:101 +0xf4\ngithub.com/cometbft/cometbft/state.execBlockOnProxyApp({0x1084e83e0?, 0x14008c58430}, {0x1084f96c0, 0x14005e14798}, 0x14006e1e5a0, {0x1084fdd80, 0x14005e14018}, 0x5418dd?)\n\tgithub.com/cometbft/cometbft@v0.37.2/state/execution.go:363 +0x3e8\ngithub.com/cometbft/cometbft/state.(*BlockExecutor).ApplyBlock(_, {{{0xb, 0x0}, {0x1400b787b0a, 0x6}}, {0x1400b787b20, 0xd}, 0x5418d6, 0x5418dd, {{0x140091f91c0, ...}, ...}, ...}, ...)\n\tgithub.com/cometbft/cometbft@v0.37.2/state/execution.go:197 +0xe4\ngithub.com/cometbft/cometbft/consensus.(*State).finalizeCommit(0x140014e1c00, 0x5418de)\n\tgithub.com/cometbft/cometbft@v0.37.2/consensus/state.go:1700 +0x964\ngithub.com/cometbft/cometbft/consensus.(*State).tryFinalizeCommit(0x140014e1c00, 0x5418de)\n\tgithub.com/cometbft/cometbft@v0.37.2/consensus/state.go:1609 +0x28c\ngithub.com/cometbft/cometbft/consensus.(*State).enterCommit.func1()\n\tgithub.com/cometbft/cometbft@v0.37.2/consensus/state.go:1544 +0xa0\ngithub.com/cometbft/cometbft/consensus.(*State).enterCommit(0x140014e1c00, 0x5418de, 0x0)\n\tgithub.com/cometbft/cometbft@v0.37.2/consensus/state.go:1582 +0xb90\ngithub.com/cometbft/cometbft/consensus.(*State).addVote(0x140014e1c00, 0x14008167860, {0x0, 0x0})\n\tgithub.com/cometbft/cometbft@v0.37.2/consensus/state.go:2212 +0x1790\ngithub.com/cometbft/cometbft/consensus.(*State).tryAddVote(0x140014e1c00, 0x14008167860, {0x0?, 0x104ae6d20?})\n\tgithub.com/cometbft/cometbft@v0.37.2/consensus/state.go:2001 +0x28\ngithub.com/cometbft/cometbft/consensus.(*State).handleMsg(0x140014e1c00, {{0x1084ba060, 0x14008c83a58}, {0x0, 0x0}})\n\tgithub.com/cometbft/cometbft@v0.37.2/consensus/state.go:861 +0x37c\ngithub.com/cometbft/cometbft/consensus.(*State).receiveRoutine(0x140014e1c00, 0x0)\n\tgithub.com/cometbft/cometbft@v0.37.2/consensus/state.go:788 +0x350\ncreated by github.com/cometbft/cometbft/consensus.(*State).OnStart\n\tgithub.com/cometbft/cometbft@v0.37.2/consensus/state.go:379 +0xf4\n"
6:11PM INF service stop impl={"Logger":{"Logger":{}}} module=consensus msg={} wal=/tmp/elys/data/cs.wal/wal
6:11PM INF service stop impl={"Dir":"/tmp/elys/data/cs.wal","Head":{"ID":"mfuAd6BDdMhu:/tmp/elys/data/cs.wal/wal","Path":"/tmp/elys/data/cs.wal/wal"},"ID":"group:mfuAd6BDdMhu:/tmp/elys/data/cs.wal/wal","Logger":{"Logger":{}}} module=consensus msg={} wal=/tmp/elys/data/cs.wal/wal
2024/01/30 18:11:32 Process killed successfully
2024/01/30 18:11:32 Process was killed: signal: killed
2024/01/30 18:11:37 Waiting for node to start...
6:11PM INF Setting up upgrade handler for burner module=server
6:11PM INF Setting up upgrade handler for leveragelp module=server
6:11PM INF Setting up upgrade handler for bank module=server
6:11PM INF Setting up upgrade handler for crisis module=server
6:11PM INF Setting up upgrade handler for ibc module=server
6:11PM INF Setting up upgrade handler for icahost module=server
6:11PM INF Setting up upgrade handler for transferhook module=server
6:11PM INF Setting up upgrade handler for gov module=server
6:11PM INF Setting up upgrade handler for transfer module=server
6:11PM INF Setting up upgrade handler for assetprofile module=server
6:11PM INF Setting up upgrade handler for commitment module=server
6:11PM INF Setting up upgrade handler for perpetual module=server
6:11PM INF Setting up upgrade handler for auth module=server
6:11PM INF Setting up upgrade handler for staking module=server
6:11PM INF Setting up upgrade handler for tokenomics module=server
6:11PM INF Setting up upgrade handler for amm module=server
6:11PM INF Setting up upgrade handler for clock module=server
6:11PM INF Setting up upgrade handler for stablestake module=server
6:11PM INF Setting up upgrade handler for mint module=server
6:11PM INF Setting up upgrade handler for slashing module=server
6:11PM INF Setting up upgrade handler for icacontroller module=server
6:11PM INF Setting up upgrade handler for oracle module=server
6:11PM INF starting node with ABCI Tendermint in-process module=server
6:11PM INF service start impl=multiAppConn module=proxy msg={}
6:11PM INF service start connection=query impl=localClient module=abci-client msg={}
6:11PM INF service start connection=snapshot impl=localClient module=abci-client msg={}
6:11PM INF service start connection=mempool impl=localClient module=abci-client msg={}
6:11PM INF service start connection=consensus impl=localClient module=abci-client msg={}
6:11PM INF service start impl=EventBus module=events msg={}
6:11PM INF service start impl=PubSub module=pubsub msg={}
6:11PM INF service start impl=IndexerService module=txindex msg={}
6:11PM INF ABCI Handshake App Info hash="e�!\x16��Ƨ���>\x12۵��~���6t\x10�G��f���" height=5511389 module=consensus protocol-version=0 software-version=v0.29.0
6:11PM INF ABCI Replay Blocks appHeight=5511389 module=consensus stateHeight=5511389 storeHeight=5511390
6:11PM INF Replay last block using real app module=consensus
6:11PM INF applying upgrade "v0.29.0" at height: 5511389 module=server
6:11PM INF Running upgrade handler for v0.29.0 module=server
6:11PM INF migrating module incentive from version 8 to version 9 module=server
6:11PM INF adding a new module: perpetual module=server
6:11PM INF ending epoch identifier=band_epoch module=x/epochs
6:11PM INF ending epoch identifier=hour module=x/epochs
6:11PM INF ending epoch identifier=tenseconds module=x/epochs
6:11PM INF Vesting tokens for vestingInfo module=x/commitment```

@jelysn I noticed there are still a few files that still have the name margin should we rename them as well? I am fine with doing those changes in a future PR as those are minor changes.


Prerendering timed out after 30000ms because the boot function

Prerendering timed out after 30000ms because the boot function
I have just used ngx-bootstrap:
<carousel [interval]="myInterval" [noWrap]="noWrapSlides" [(activeSlide)]="activeSlideIndex">
<slide *ngFor="let slide of slides; let index=index">

  </slide>
</carousel>

component.ts
call after webservice retrieved the data

So it's because the carousel is running an interval so the server never knows when to render. Try wrapping myInterval and such with isPlatformBrowser, you want to ignore this from rendering (or at least running any type of interval) on the server. You want the server to render asap.
Hope that helps!


Feature request Proxyless (USING VPN EXTENSION)

Is there an existing issue for this?

[X] I have searched the existing issues

I'm submitting a ...

[ ] bug report
[X] feature request
[ ] support request --> Contact me over mail for support https://github.com/MShawon

Description
Please create new update with no proxy option.
Thank you
Environment
- OS : Windows
- Python : 3.9
- Script version : 1.7.6

config.json
No

MShawon said before that he won't do this, you would have to use another project or make your own view bot. But VPNs usually don't have many IPs, so you wont make many views anyways, and VPNs use datacenter proxies, which all the views will be removed. You need resedential proxies

MShawon said before that he won't do this, you would have to use another project or make your own view bot. But VPNs usually don't have many IPs, so you wont make many views anyways, and VPNs use datacenter proxies, which all the views will be removed. You need resedential proxies

Nice bro. youtube update and yeah .. proxy resential is the best


Remove Legacy Codes that are not in use anymore

Describe the improvement
Some legacy codes (i.e. [1] ), are not in use inside the IS anymore. But since these codes are packed inside the IS, it causes security scanners to detect security vulnerabilities related to them and will be reported as IS vulnerabilities even though they are not used anymore. Therefore such unused legacy code bases should be refactored.
[1] https://github.com/wso2/carbon-kernel/blob/4.9.x/core/org.wso2.carbon.ui/src/main/resources/web/editarea/edit_area_loader.js

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Tyrian converter

This PR adds support for Tyrian: https://tyrian.indigoengine.io/
Since Tyrian isn't that similar to the others I decided to put the converter in a complete new path rather than integrating it with the others and try to account for the differences in countles if/elses. Also prevents messing up the existing converters.
I also added the TyrianTags and TyrianAttributes which are a mirror from Tyrians definition of tags and attributes. This makes it trivial to update the list if new tags are added or changed in the library.
Hope this is useful, cheers!

Nice. Thank you 👍🏼.

Added a package for tyrian.
Just for nicer git commit history and to maintain author names. Would you mind adding a TyrianConverter in that package with your convert function in it?
Eg:
private def toScala(node: Node,
                    converterType: ConverterType,
                    childrenWithoutGarbageNodes: collection.Seq[Node],
                    children: String): String =
  converterType match {
    case _: Tyrian =>
      TyrianConverter.toScala(
        node = node,
        converterType = converterType,
        childrenWithoutGarbageNodes = childrenWithoutGarbageNodes,
        children = children
      )

   case _ =>
     ...

@simerplaha I can try that.