Porting @AloyseTech's color picker from lvgl v5 to v6

Currently I can compile and run the code in an Arduino test project, but I see no UI.
(My project can show "Hello LittlevGL" text, so the setup seems fine).
I am new to lvgl so don't yet know how to use a desktop simulator, but I have been programming for 30 years and I should be able to figure it out as needed.
void setup() {
  Serial.begin(115200);
  Serial.println("setup: littlevgl cpicker test");

  //...

  lv_init();

  lv_disp_buf_init(&disp_buf, buf_1, buf_2, LV_HOR_RES_MAX * 10);

  lv_disp_drv_t disp_drv;
  lv_disp_drv_init(&disp_drv);
  disp_drv.hor_res = displayWidth;
  disp_drv.ver_res = displayHeight;
  disp_drv.flush_cb = my_disp_flush;
  disp_drv.buffer = &disp_buf;
  lv_disp_drv_register(&disp_drv);

  lv_indev_drv_t indev_drv;
  lv_indev_drv_init(&indev_drv);
  indev_drv.type = LV_INDEV_TYPE_POINTER;
  indev_drv.read_cb = my_input_read;
  lv_indev_drv_register(&indev_drv);

  tick.attach_ms(LVGL_TICK_PERIOD, lv_tick_handler);

  //lv_obj_t *label = lv_label_create(lv_scr_act(), NULL);
  //lv_label_set_text(label, "Hello LittlevGL v6.x");
  //lv_obj_align(label, NULL, LV_ALIGN_CENTER, 0, 0);

  lv_obj_t *colorPicker = lv_cpicker_create(lv_scr_act(), NULL);
  lv_obj_align(colorPicker, NULL, LV_ALIGN_CENTER, 0, 0);
}

void loop() {
  //...
  lv_task_handler();
  delay(5);
  //...
}

I won't mark this as Ready For Review until I can at least get it working.
I may need some help/advice on how to best test the code.
I have forked lv_examples and am attempting to add a lv_test_cpicker, but am stumbling getting it to run in Arduino (which I don't expect the tests are designed for).
Currently I am just creating the objx directly and attempting to show and poke it and get a reaction.

Including @AloyseTech if he wants to chime in.

As far as I recall, it was a bit picky about how you initialized it. Maybe try something like this (from #565):
    const uint32_t pickerSize = 200;
    lv_obj_t * scr = lv_scr_act();

    static lv_style_t style;
    lv_style_copy(&style, &lv_style_plain);
    style.line.color = lv_color_hsv_to_rgb(0, 100, 100);
    style.line.width = pickerSize/5;
    style.body.padding.inner = 8;

    static lv_style_t indicStyle;
    lv_style_copy(&indicStyle, &lv_style_plain);
    indicStyle.body.main_color = LV_COLOR_WHITE;
    indicStyle.body.grad_color = indicStyle.body.main_color;
    indicStyle.body.opa = LV_OPA_80;

    lv_obj_t * picker = lv_cpicker_create(scr, NULL);
    lv_cpicker_set_style(picker, LV_CPICKER_STYLE_MAIN, &style);
    lv_cpicker_set_style(picker, LV_CPICKER_STYLE_IND, &indicStyle);
    lv_obj_set_size(picker, pickerSize, pickerSize);
    lv_obj_align(picker, NULL, LV_ALIGN_CENTER, 0, 0);
    lv_scr_load(scr);

FYI, I'm just doin this on the side (who isn't?), so I'll get to this when I get to this; no rush (other than when I actually get the time to work on it! :))

Coded creation per your suggestion from original PR.
Still not showing anything.
I think where I am confused now is w/ that the v5 code seems to be based off of lv_objx_template, but I think lv_objx_template seems to be obsolete in v6.
v5 lv_cpicker_create calls lv_obj_set_signal_func and lv_obj_set_design_func, but v6 never shows that being used by anything other than lv_objx_template.
Similar story w/ ancestor_signal and ancestor_design.
I am new to this lib and not familar w/ what seems like the v5 template.
Are lv_obj_set_signal_func and lv_obj_set_design_func require to init the v5 objx?
Looking to see how other controls are initialized...

lv_objx_template is not obsolete. See https://github.com/littlevgl/lvgl/blob/master/src/lv_objx/lv_objx_templ.c.

FYI, looks like in lv_objx_templ.c, lv_signal_func_t should be renamed lv_signal_cb_t, and lv_design_func_t to lv_design_cb_t

Progress! I am able to get the center dot to draw [but oddly, red].
Next I suspect the triangle drawing calls need to be migrated better.

"Accidentally" hit "Ready For Review" to test if it would let me enter text; it didn't, so here we are in review.
Not actually ready for review yet!
The UI draws OK now, but events still aren't hooked up.
I'll work on that tonight/tomorrow.

Not actually ready for review yet!

No problem. It's really too bad that you can't go back to a draft once it's "ready for review".

I think this is ready for review/testing.
Note that I don't know this code very well, so if there are "existing" bugs @AloyseTech might be better to fix them.

Again, my Arduino test app is at:
https://github.com/paulpv/lv_examples/blob/master/lv_tests/lv_test_objx/lv_test_cpicker/lv_test_cpicker.ino
Sorry, I am totally not set up to test this on any other environments. :/

Video of it in action.
https://youtu.be/l_1NwwVqQzk
It is very slow.
I will be trying some tricks the the display driver to speed it up, but do you have any obvious suggestions?

In the above video, notice the first draw starting at 7 seconds and ending at 9 seconds.
If I entirely #if false all of the cpicker code and just print the title, it still takes about 2 seconds to paint the screen. :/
I am hard initializing my ILI9341 SPI to 40000000 Hz.
Arduino sketch has been updated.

@paulpv I'll test it on my STM32 later (where it was previously fast in 5.3). If it acts the same as it used to there then the performance issue is not related to the color picker itself.

@paulpv

I will be trying some tricks the the display driver to speed it up, but do you have any obvious suggestions?

Using display.writePixels should speed up drawing.

If you use the TinyPICO you could take a look at the ESP32 port/driver maybe?

Performance problem solved.
Even the display's base graphics test was slow.
Unbeknownst to me I was using the Software SPI (SWSPI) mode of the Adafruit ILI9341 driver.
I switched to Hardware SPI (HWSPI) mode and both the graphics test and the lvgl test app are much faster.

display.writePixels implemented.
Display looks good and seems a little faster.
Is there an easy way to add a FPS overlay, or is that not really relevant here?

Is there an easy way to add a FPS overlay, or is that not really relevant here?

Not particularly. Just use the benchmark from lv_examples and add a color picker to it somewhere. Then you can check rendering speed, which is the closest unit we have to FPS.

Oh, I haven't even tried the Rect version of the control yet. :/

FYI:
With cpicker:  ~3.6 screen redraws per second
Without cpicker: ~21.8 screen redraws per second

With cpicker: ~3.6 screen redraws per second

Ouch. I think this would be pretty visible to the human eye (especially on slower chips). It's probably worth looking into why it's so slow.

I'm new to lvgl and its capabilities, but I would think that the control triangles could be generated only when the moment the mode is set (implying at creation too) and then persist as a [hopefully faster to draw?] static background image that the cursor control is then drawn over.
If the mode is changed that is probably an acceptable time for a small FPS hit to calculate the control's new mode's image using the current values.
Theory only...and I currently have little to no idea how to implement that.
The "FPS" still seems very usable to me, but I am running an ESP32.

persist as a [hopefully faster to draw?] static background image that the cursor control is then drawn over.

The usual solution that the other objects use is to respect the mask that gets passed to the design function. Not sure if the color picker does that or not. With the other objects, the mask is passed all the way into the drawing functions like lv_draw_rect, etc. which then skip calculations of areas outside the mask.
If you know, how fast is it with the rectangular version?

Rectangle is a bit messed up.
I'll work on it "soon".

Drawing hundreds of triangles/arcs will be very slow anyway. Probably the rectangle like color picker would be a better direction. Less fancy but should be much faster. Unfortunately, I don't remember how the rectangle version looked like in @AloyseTech 's implementation but IMO something like in Paint could be good direction (rectangle + slider for brightness). Or three sliders for Hue, Saturation, and Value?

Drawing hundreds of triangles/arcs will be very slow anyway. Probably the rectangle like color picker would be a better direction. Less fancy but should be much faster.

I think we should allow both options (if it doesn't increase the code size). I still need to test the round version but in the past on STM32 the speed was very reasonable.

To speed up the circular version you can play with the quantization factor. The higher the QF, the faster the rendering. The color wheel is made with 360/QF triangles for Hue (100 for Saturation and Value). If QF is too high, the wheel will lok like a polygon and will have less color gradient displayed (the center preview color will display the 360 or 100 value though.

Yes, a more practical UI may be to have 3 sliders.
That said, and I mean this as a compliment, @AloyseTech's control (which I have seen similar in other places) is beautiful overkill.
Perhaps this control would be best as a stand-alone 3rd party control and not a first-class citizen of lvgl?

With the default QF setting (1) this is definitely much slower than how I remember it being back in December.
I adjusted the QF to 4 and gave it another try. It had much better performance. I will see how high I can make the QF without much visual difference. (I feel like I'm adjusting the quality setting on a JPEG before I export it.)

I was trying to run the benchmark and get some objective data, but in the process... LittlevGL seems to have lost the ability to properly handle text at the moment. Investigation continues...

@kisvegabor Any ideas as to why all text rendering stopped functioning for me on dev-6.1 HEAD? An older version of dev-6.1 or the master branch both seem to work fine. Do I need to change something else?

Here's the raw benchmark results for STM32F746-Discovery (custom port, not the SW4STM32 one):
* Screen load without color picker:     34  ms
* Screen load with color picker, QF 16: 77  ms
* Screen load with color picker, QF  8: 98  ms
* Screen load with color picker, QF  4: 130 ms
* Screen load with color picker: QF  2: 200 ms
* Screen load with color picker, QF  1: 340 ms

Here are the results in chart format.
It looks the best options for a default QF would be 2, 3, or 4. Beyond that there is minimal performance gain, and the widget does not look very good.

Yes, 3 looks good. 4 has recurring artifacts.
Still haven't touched the broken Rectangle code yet.
Any opinions on whether this is worthy of being a 1st class control or if this PR should be abandoned and this code become a 3rd party repo of its own?
I am assuming the latter is possible, but I suppose it is possible it is too tightly integrated, but it seems fairly separable to my naive self.

Any opinions on whether this is worthy of being a 1st class control or if this PR should be abandoned and this code become a 3rd party repo of its own?

I think it's fine to merge it, like I said above. No one is forced to use it. :smiley:

I think it's fine to merge it, like I said above. No one is forced to use it.

Understood, but the owners of this project might feel forced to maintain it. :/

the owners of this project might feel forced to maintain it.

As one of the owners, I can say that I wouldn't feel forced at all. :wink:
This kind of widget looks good in screenshots/demos/etc. (especially if it were to be animated), so I would be happy to keep it working.

I agree to merge this widget, but the code needs to be cleaned up.
@embeddedt

As one of the owners, I can say that I wouldn't feel forced at all.

Actually we are forced to maintain it. If somebody reports a bug in it we should fix it. And to do so the widget should be clean, easy to understand and well commented. For example lv_cpicker_disc_design is 400 lines long. It should be cleaned up and broken into smaller functions to make it easier to digest. If we don't use the rectangle mode then the related code should be removed.
@paulpv
Don't misunderstand me, any contribution is highly appreciated, however, unfortunately, I already had bad experiences when I needed to almost completely rewrite other's widgets to make them work correctly. That's why I force to merge clean and easy to maintain code.

but the code needs to be cleaned up.

Fair enough.

It should be cleaned up and broken into smaller functions to make it easier to digest.

Yes; I agree.

I'll still attempt to fix the Rectangle version.
Perhaps I could just comment it out until it is fixed?
Since this is not my original code, I'll query: Who would be the best person to clean this code up?
I'm gonna predict you'll say me. :P

I'll query: Who would be the best person to clean this code up?
I'm gonna predict you'll say me. :P

You are good at predicting. :wink:
Seriously, though, in my opinion, you are probably the most familiar with that code and therefore the best candidate for the task. But let's wait and see what @kisvegabor says.

Seriously, though, in my opinion, you are probably the most familiar with that code and therefore the best candidate for the task. But let's wait and see what @kisvegabor says.

It'd be great if @paulpv could make the initial clean up (too long functions, comments etc). After that, I'd happily review it and make some fine-tuning (API, further simplification, optimization etc.).

Will do as I am trying to get Rect working.
I suppose were all volunteers here. Three toddler or less kids slow down my contributions a lot. I will get to it "soon".

Interesting: https://forum.littlevgl.com/t/color-picker-widget/727

Update: I made good progress on updating the code and fixing the two issues I found with the Rect version.
What follows is by no means a criticism of @AloyseTech's good and hard work; it is just intended as a statement of fact.
It looks like from @AloyseTech last push that his Rect code was mostly a copy and paste of the Disc code, and the Rect code still contained use of ATAN and outer and inner radii, as well as todo comments saying to use the rect of the gradient and preview of the control.
Most of that is implemented now, as well as a breaking down the code in to smaller functions.
It still may be a day or two before it is ready for review again.
I'll get it done, but it's probably safe to say that the only one in a rush for this to be done is me. :)

I'm a bit stuck. :/
I have a [sub] branch where I broke down the code a bit...but I ended up breaking something along the way.
So, I backtracked and started to just fix the functionality issues that I found along the way.
So, keep in mind that my request below is for the original non-broken down code (that I still intend to break down, but only after all known issues are working).
All of the issues I found seem to be fixed now...
...except for the Rect's "optimized" invalidation of only the "LINE" indicator. :/
The Disk "Circle", "Line", and "In" indicators seem to invalidate just fine.
The Rect "Circle", and "In" indicators seem to invalidate just fine.
Only the Rect "Line" indicator isn't invalidating...nor is it even letting me select the left ~1/4 values...but again things work fine for all other indicators.
I must be missing some obvious simple bug in my code, or in how lvgl invalidation works.
Are any of you in a position to run this [non-cleaned up] code and look at how the Rect is invalidating and spotting whatever obvious issue I am missing?
I'll keep banging on this, but any help would be appreciated.
Thanks!

@paulpv
I'd look into it. Can you send a coded snippet to reproduce the issue?

Code from my test sketch at https://github.com/paulpv/lv_examples/blob/master/lv_tests/lv_test_objx/lv_test_cpicker/lv_test_cpicker.ino
    static lv_style_t styleMain;
    lv_style_copy(&styleMain, &lv_style_plain);
    styleMain.line.width = pickerSize * 0.2;

    static lv_style_t styleIndicator;
    lv_style_copy(&styleIndicator, &lv_style_plain);
    styleIndicator.body.main_color = LV_COLOR_WHITE;
    styleIndicator.body.grad_color = styleIndicator.body.main_color;
    styleIndicator.body.opa = LV_OPA_80;

    lv_obj_t * scr = lv_disp_get_scr_act(disp);

    colorPicker = lv_cpicker_create(scr, NULL);
#if false
    lv_obj_set_size(colorPicker, pickerSize, pickerSize);
    lv_cpicker_set_type(colorPicker, LV_CPICKER_TYPE_DISC);
    lv_cpicker_set_indicator_type(colorPicker, LV_CPICKER_INDICATOR_LINE);
#else
    lv_obj_set_size(colorPicker, pickerSize, pickerSize / 2);
    lv_cpicker_set_type(colorPicker, LV_CPICKER_TYPE_RECT);
    lv_cpicker_set_indicator_type(colorPicker, LV_CPICKER_INDICATOR_LINE);
#endif
    lv_obj_align(colorPicker, NULL, LV_ALIGN_CENTER, 0, 0);
    lv_cpicker_set_style(colorPicker, LV_CPICKER_STYLE_MAIN, &styleMain);
    lv_cpicker_set_style(colorPicker, LV_CPICKER_STYLE_INDICATOR, &styleIndicator);

FYI, the following combos seem to work fine:
LV_CPICKER_TYPE_DISC  LV_CPICKER_INDICATOR_LINE
LV_CPICKER_TYPE_DISC  LV_CPICKER_INDICATOR_CIRCLE
LV_CPICKER_TYPE_DISC  LV_CPICKER_INDICATOR_IN
LV_CPICKER_TYPE_RECT  LV_CPICKER_INDICATOR_CIRCLE
LV_CPICKER_TYPE_RECT  LV_CPICKER_INDICATOR_IN

Only LV_CPICKER_TYPE_RECT  LV_CPICKER_INDICATOR_LINE seems to not work. :/
the LV_CPICKER_TYPE_RECT signal code doesn't care about the indicator type, so it works for 2 of the 3 indicators, and drawing seems to work for all 3 indicators, but hooking together input signaling and drawing doesn't work only for RECT LINE. :/
I'll still bang away at it.

Here is a video of the drawing bug:

Here is the Line drawing code (the Circle and In code draw and accept [the same] input just fine):
(circa https://github.com/littlevgl/lvgl/pull/1196/files#diff-377eaf57e58ece914765518d2b0618d7R1077)
            lv_point_t p1, p2;
            p1.x = ext->rect_gradient_area.x1 + ind_pos;
            p1.y = ext->rect_gradient_area.y1;
            p2.x = p1.x;
            p2.y = ext->rect_gradient_area.y2;

            lv_draw_line(&p1, &p2, mask, ext->indicator.style, opa_scale);

I have no idea what is causing that odd "black hole" of a triangle to not redraw.

Better video showing all 3 modes in action and only one not working as expected:

I'm moving on w/ the cleanup, which will result in cleaner code that hopefully magically fixes the problem...

Thank you for the code and the videos. I've found the issue and pushed a fix.

Hallelujah for code reviews! I knew it had to be something simple!
Thanks!
Onward and upward...

I'm thinking about color indicator in rectangle mode.
IMO it's not what user always want.
What about removing it and let the user to monitor the current color and do what he wants with it?

I'm thinking about color indicator in rectangle mode.
IMO it's not what user always want.
What about removing it and let the user to monitor the current color and do what he wants with it?

For this PR I plan to stick with the spirit of @AloyseTech's original idea.
The functionality is welcome to be tweaked, but my opinion is to save changes like you recommend for future PRs.

The functionality is welcome to be tweaked, but my opinion is to save changes like you recommend for future PRs.

Okay.
I've got email notification about this commit but can't see here now. What happened? What was the problem with the fonts?

The 4 robot fonts don't compile with their first #include "lvgl/lvgl.h" line.
You had just merged 6.1 but I assumed my branch was off caused all 4 roboto files showed up in the PR.
I erroneously deleted them on my branch and pushed.
I immediately realized my error and rather than correctly simply commit a revert of my changes I probably erroneously reset my branch to before my deleting the fonts and then forced a push.
Bad me, but it was just on my branch so hopefully no harm done.
I still have to have my local roboto font files change their first line to #include "../../lvgl.h" in order to get them to compile.
FYI: I've made great progress on the cleanup and am almost done.

OK, please review!
Please pay specific attention to function parameters, and if any of them should be const or * or something else more appropriate.
Please also feel free to refactor the code more as you see fit and that meets your standards.
I read them and think I am close, but I am probably not 100% on.
I'm also not able to set to color color value at app setup time and have it display as the set value.
I have a hunch that the code needs to wait until after LVGL is finished initializing before I can set the value and have it display correctly.
Might this hunch be correct, and is this normal, and how to do it?
I also plan to take another pass and reduce the number of trigo calls by saving a calculated value and using it multiple times, instead of re-calculating the exact same values multiple times.
That may or may not happen in this PR.

Again, a stand-alone test app can be seen here.
https://github.com/paulpv/lv_examples/blob/master/lv_tests/lv_test_objx/lv_test_cpicker/lv_test_cpicker.ino
I didn't figure out how to run tests so that I can write ones for this control.

Might this hunch be correct, and is this normal, and how to do it?

Anything that gets called after lv_init should work properly. lv_init is not asynchronous.

Funny, after all the cleanup, consolidating a ton of duplicated code, I ended up saving less than 100 lines! :/
Before:
After:

@paulpv
Awesome, thank you! I'll immerse in it next week!

Please also feel free to refactor the code more as you see fit and that meets your standards.
I read them and think I am close, but I am probably not 100% on.

Look good at first look!

I ended up saving less than 100 lines! :/

I'm sure you do much more if you take the new function prototypes and extra comments into account. :wink:
As I'm mentioned here I'm not sure all the current features are really required. We should end up with a lean and flexible object. It'd easier to review/refactor if I could reshape these things at once. I suggest merging the current state into a feat-cpicker branch. This way the current version would be already in lvgl and it can be used as a base of further improvements. What do you think?

@kisvegabor do whatever makes the most sense for the project! You want to create the feat-cpicker branch, or should I? I'll default to just following your lead.

I've created it because write access is required to create new branches.
So I've merged the current state to feat-cpicker and I'll start ot work on it next week.
Thank you very much @paulpv and @AloyseTech!

Thanks! There seems to be a bug w/ setting the color with lv_color_t, where it computes hsv but then only sets h.
Simple fix, but I'm trying to wrap my head around how 565 color works in lvgl and why I don't get the results I expect when I call lv_cpicker_set_color(colorPicker, LV_COLOR_MAGENTA);
I am also experimenting with replacing:
typedef struct {
    uint16_t hue;
    uint8_t saturation;
    uint8_t value;
...
    uint16_t prev_hue;
    uint8_t prev_saturation;
    uint8_t prev_value;
...
} lv_cpicker_ext_t;

with
typedef struct {
    lv_color_hsv_t hsv;
...
    lv_color_hsv_t prev_hsv;
...
} lv_cpicker_ext_t;

Finally, once fully stabilized and merged to production I may consider adding logic to better interop w/ FastLED (https://github.com/FastLED/FastLED/wiki/FastLED-HSV-Colors), but if that doesn't make any sense to be in LVGL then I can always make it a stand alone-repo.

There seems to be a bug w/ setting the color with lv_color_t, where it computes hsv but then only sets h.
Simple fix, but I'm trying to wrap my head around how 565 color works in lvgl and why I don't get the results I expect when I call lv_cpicker_set_color(colorPicker, LV_COLOR_MAGENTA);

Fell free to send PR to feat-cpicker if you have a fix.

Finally, once fully stabilized and merged to production I may consider adding logic to better interop w/ FastLED (https://github.com/FastLED/FastLED/wiki/FastLED-HSV-Colors), but if that doesn't make any sense to be in LVGL then I can always make it a stand alone-repo.

That's impressive! We can update lv_color_hsc_to_rgb to work with these corrected curves.

Heads Up: The setting and getting of the color components does seem to me to be wonky.
To control starts off set to Greenish, even though it resets to Red just fine.
Setting a color doesn't display as set.
And I'm still wrapping my head around 565 colors.
Obviously this shouldn't be merged with production until any issue here is resolved. I'll be looking in to it when I get time, but if you see the same issue and see a fix please make it so!


Hyperion and DiyHue Bridge

[x] I confirm that this is an issue rather than a question.

Bug report
I am using DiyHue Virtual Hue Bridge. I am successfully discovery this fake bridge with my iPhone hue apps, and Philips Ambilight TVs. But in Hyperion this bridge not found. I write bridge IP also nothing happening.
Here is DiyHue Bridge: https://diyhue.org/
PS: I know the build is not original. But I first try the latest original build. Original build can't find a bridge. After that, I compile SJunkies build. So the same system and same happens.
PS2: Yes. I have Philips Ambilight Tv and I am still using ws2812b's strips in my Ambilight tv with android grabber.
Steps to reproduce
Connect Hue Bridge.
What is expected?
Successfully discovery and connect to hue bridge.
What is actually happening?
Not discovery Hue Bridge.
System

Hyperion Server:

Build:       entertainment-api-2020 (SJunkies-e53b42d5/cc39649f-1586967374)
Build time:  Apr 15 2020 21:41:55
Git Remote:  https://github.com/SJunkies/hyperion.ng.git
Version:     2.0.0-alpha.4
UI Lang:     auto (BrowserLang: en-US)
UI Access:   expert
Avail Capt:  dispmanx,v4l2,framebuffer,qt

Hyperion Server OS:

Distribution: Raspbian GNU/Linux 10 (buster)
Arch:         arm
Kernel:       linux (4.19.93+ (WS: 32))
Browser:      Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537

Did you also tested this PR https://github.com/hyperion-project/hyperion.ng/pull/592 ?

@tpmodding
the entertainment-api-2020 branch is currently the same as the entertainment-api-2019 branch.
I will look into this problem!

@SJunkies if you need any info or debug messages I am here. Today I am successfully connected hue bridge with Hyperion! But without a wizard. I added an IP address and username manually.

I have used Hue essentials app for extract username. And copy username. After that connect is successfully. Wizard still no response.

I used local IP because Hue emulator installed the same device with Hyperion. So now no problem. I can control lights with Hyperion. I edited config.json manually. Philips Hue Wizard is still not working.

@BTopbas
thanks for your input!
the bridge discovery inside the wizard works currently only with https://discovery.meethue.com website. If no data is available over this URL, manually typed in bridge IP is needed.
Use Target-IP: <IP_ADDRESS> like on your devices screenshot and restart the wizard.
If the bridge is found, you can create a new user inside the wizard and configure your lights.
All updates within the Hue Bridge/Lights/Wizard etc. currently available inside the #592.
for this PR:
I will try to add bridge discovery through SSDP later...
To use the entertainment API, an entertainment group is required, which must first be created with one of the Hue apps.

are you sure, that your username is correct?
Do you get response from API, when u open the url inside a browser:
http://BRIDGEIP/api/USERNAME/
I think the existing usernames cannot be accessed in readable format through the REST API...

@SJunkies The Username is OK.
It is the wizard.js that has problems. If you use the previous version the wizard works. With the latest version, one cannot proceed beyond the assistant's intro screen.

@SJunkies In addition, the configuration item "Log all Hue commands" is only available, if  Entertainment API is selected. It should be available for classic API, too. Pleasae remove that dependency in the definition file.

@SJunkies The Username is OK.
It is the wizard.js that has problems. If you use the previous version the wizard works. With the latest version, one cannot proceed beyond the assistant's intro screen.

Thanks for this!
my editor wasn't case sensitive, while i did the last changes with  search / replace 🤦
Fix coming soon. Sorry for that :/

are you sure, that your username is correct?
Do you get response from API, when u open the url inside a browser:
http://BRIDGEIP/api/USERNAME/
I think the existing usernames cannot be accessed in readable format through the REST API...but maybe i’m wrong!?

Yes I get response. Here is output.
{"lights":{"1":{"capabilities":{"certified":true,"control":{"colorgamut":[[0.704,0.296],[0.2151,0.7106],[0.138,0.08]],"colorgamuttype":"A","maxlumen":200,"mindimlevel":10000},"streaming":{"proxy":false,"renderer":true}},"manufacturername":"Philips","modelid":"LST002","name":"Hue WS2812 strip 1","state":{"alert":"none","bri":35,"colormode":"xy","ct":200,"effect":"none","hue":62536,"mode":"homeautomation","on":false,"reachable":false,"sat":254,"transitiontime":1,"xy":[0.6716,0.2986]},"swversion":"<IP_ADDRESS>581","type":"Color light","uniqueid":"00:17:88:01:00:6b:0d:99-0b","productname":"Hue lightstrip plus","config":{"archetype":"huelightstrip","function":"mixed","direction":"omnidirectional","startup":{"mode":"safety","configured":false}}}},"groups":{"1":{"action":{"on":false,"bri":35,"ct":200,"hue":62536,"sat":254,"xy":[0.6716,0.2986]},"class":"Living room","lights":["1"],"name":"ArtFunSex","state":{"any_on":false,"all_on":false},"type":"Room","sensors":[]}},"config":{"Hue Essentials key":"e79aa50e7f5e11eab069d076580a5c5f","Remote API enabled":false,"UTC":"2020-04-18T15:09:16","apiversion":"1.35.0","backup":{"errorcode":0,"status":"idle"},"bridgeid":"D07658FFFE0A5C5F","datastoreversion":"70","dhcp":true,"factorynew":false,"gateway":"<IP_ADDRESS>","internetservices":{"internet":"connected","remoteaccess":"connected","swupdate":"connected","time":"connected"},"ipaddress":"<IP_ADDRESS>","linkbutton":false,"localtime":"2020-04-18T15:09:16","mac":"d0:76:58:0a:5c:5f","modelid":"BSB002","name":"Philips hue","netmask":"<IP_ADDRESS>","portalconnection":"connected","portalservices":true,"portalstate":{"communication":"disconnected","incoming":false,"outgoing":true,"signedon":true},"proxyaddress":"none","proxyport":0,"replacesbridgeid":null,"starterkitid":"","swupdate":{"checkforupdate":false,"devicetypes":{"bridge":false,"lights":[],"sensors":[]},"notify":true,"text":"","updatestate":0,"url":""},"swupdate2":{"autoinstall":{"on":true}},"swversion":"1937113020","timezone":"Europe/Bucharest","whitelist":{"6eb521447f6011eabe57d076580a5c5f":{"create date":"2020-04-15T21:31:13","last use date":"2020-04-17T22:51:03","name":"Hue 3#Batuhan’s iPhone"},"hueessde7f6011eabc2ad076580a5c5f":{"create date":"2020-04-15T21:33:18","last use date":"2020-04-18T15:09:16","name":"Hue Essentials#iPhone"},"web-ui-7589":{"create date":"2020-04-15T21:20:25","last use date":"2020-04-16T07:54:36","name":"WebGui User"}},"zigbeechannel":25},"scenes":{"1":{"appdata":{"data":"eSRpL_r01_d01","version":1},"group":"1","lastupdated":"2020-04-17T16:14:14","locked":false,"name":"Relax","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]},"10":{"appdata":{"data":"GBHmN_r01_d17","version":1},"group":"1","lastupdated":"2020-04-17T16:14:15","locked":false,"name":"Arctic aurora","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]},"11":{"appdata":{"data":"T2XBZ_r01_d18","version":1},"group":"1","lastupdated":"2020-04-17T16:14:15","locked":false,"name":"Spring blossom","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]},"2":{"appdata":{"data":"pdYu4_r01_d02","version":1},"group":"1","lastupdated":"2020-04-17T16:14:14","locked":false,"name":"Read","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]},"3":{"appdata":{"data":"aXyQZ_r01_d03","version":1},"group":"1","lastupdated":"2020-04-17T16:14:14","locked":false,"name":"Concentrate","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]},"4":{"appdata":{"data":"4Atfe_r01_d04","version":1},"group":"1","lastupdated":"2020-04-17T16:14:14","locked":false,"name":"Energize","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]},"5":{"appdata":{"data":"5Isqm_r01_d05","version":1},"group":"1","lastupdated":"2020-04-17T16:14:14","locked":false,"name":"Bright","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]},"6":{"appdata":{"data":"llvRj_r01_d06","version":1},"group":"1","lastupdated":"2020-04-17T16:14:14","locked":false,"name":"Dimmed","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]},"7":{"appdata":{"data":"wBiA6_r01_d07","version":1},"group":"1","lastupdated":"2020-04-17T16:14:14","locked":false,"name":"Nightlight","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]},"8":{"appdata":{"data":"yCrKo_r01_d15","version":1},"group":"1","lastupdated":"2020-04-17T16:14:15","locked":false,"name":"Savanna sunset","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]},"9":{"appdata":{"data":"wtJrd_r01_d16","version":1},"group":"1","lastupdated":"2020-04-17T16:14:15","locked":false,"name":"Tropical twilight","owner":"6eb521447f6011eabe57d076580a5c5f","picture":"","recycle":false,"type":"GroupScene","version":2,"lights":["1"]}},"schedules":{},"rules":{},"sensors":{"1":{"config":{"configured":false,"on":true,"sunriseoffset":30,"sunsetoffset":-30},"manufacturername":"Philips","modelid":"PHDL00","name":"Daylight","state":{"daylight":null,"lastupdated":"none"},"swversion":"1.0","type":"Daylight"}},"resourcelinks":{}}

@BTopbas @SJunkies already fixed the issue. You may want to try his latest code base.

@BTopbas

@SJunkies Yes I get response. Here is output.

thanks for testing!
I could setup the DIYHue with Docker and found the current problem inside the wizard.
The DIYHue bridge, don't behave like a original Philips Hue bridge!
The REST API call: http://BRIDGEIP/api/ don't work and result in a 404, but thats the base to identify a Hue bridge with the wizard, because the original bridge return a json information over that URL.
@all
I'm currently trying some workarounds, but for security reasons, it would be best if someone else could insert a hyperion command with "sendToHyperion" over the API to execute an SSPD search with SSDPDiscover Class and return the results to the frontend.
This would also be the best way to remove internet dependencies from the https://discovery.meethue.com URL to work on offline networks as well.

@SJunkies I have the same need for the Yeelight ssdp discovery. Plus some additional tweaks as Yeelight has some proprietary stuff. I will have a Look when I have the lights basics working.

@sjunkies I manged to get the diyHue bridge running and via a RESTClient I managed also to get a username and clientkey.
Then I created and Entertainment Group with one light and activated streaming.
The I started hyperion with the right parameters, but the device goes into error "Bridge response is not Valid'".
If I look at the bridge's response. It is a valid Success message.
Looks like there is an issue, if the stream is active, you try to disable it...
Please find the log details below:
hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:358:log()> Entertainment Group found     : [4]
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:358:log()> Lights in Group               : 1
[hyperiond LEDDEVICE] <INFO> Entertainment Group [4] "" with 1 Lights found
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:358:log()> Light-IDs configured          : 1
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:358:log()> Light-IDs                     : 1
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:744:PhilipsHueLight()> Recognized model id LCT001 of light ID 1 as gamut B
[hyperiond LEDDEVICE] <INFO> Light ID 1 ("Hue Lamp 1", LED index "0") created
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Streamer Debug            : yes
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL DebugLevel                : [4] Verbose
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Servername                : Hue
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Host                      : <IP_ADDRESS>
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Port                      : 2100
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> PSK                           : 321c0c2ebfa7361e55491095b2f5f9db
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> PSK-Identity                  : 2bd7034a81ab11eab438000c29d8d52d
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Transport Type            : DTLS
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Seed Custom               : dtls_client
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Retry Left                : 5
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Read Timeout              : 0
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Handshake Timeout min     : 400
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Handshake Timeout max     : 1000
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:183:configLog()> SSL Handshake attempts        : 5
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:91:init()> Successfully parsed <IP_ADDRESS> as an ip address.
[hyperiond LEDDEVICE] <DEBUG> <ProviderUdpSSL.cpp:122:init()> UDP SSL using <IP_ADDRESS>:2100
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:563:getJson()> GET: [http://<IP_ADDRESS>:80/api/2bd7034a81ab11eab438000c29d8d52d/groups/4]
[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:36:setNewComponentState()> LED device: enabled
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:613:handleReply()> Reply.httpStatusCode [200]
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:630:handleReply()> Reply: [{"action":{"bri":221,"ct":0,"hue":10105,"on":false,"sat":254,"xy":[0.4356,0.4967]},"class":"TV","lights":["1"],"locations":{"1":[0,0.7,0]},"state":{"all_on":false,"any_on":false},"stream":{"active":true,"owner":"2bd7034a81ab11eab438000c29d8d52d","proxymode":"auto","proxynode":"/bridge"},"type":"Entertainment"}]
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:1144:initStream()> Group: "" [4] is in use, try to stop stream
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:587:putJson()> PUT: [http://<IP_ADDRESS>:80/api/2bd7034a81ab11eab438000c29d8d52d/groups/4] [{"stream":{"active":false}}]
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:613:handleReply()> Reply.httpStatusCode [200]
[hyperiond LEDDEVICE] <DEBUG> <LedDevicePhilipsHue.cpp:630:handleReply()> Reply: [[{"success":{"/groups/4/stream":{"active":false}}}]]
[hyperiond LEDDEVICE] <ERROR> Device disabled, device 'philipshue' signals error: 'set stream to false: Bridge response is not Valid'
[hyperiond LEDDEVICE] <ERROR> Group: "" [4] couldn't stop by user: "2bd7034a81ab11eab438000c29d8d52d" - Entertainment API not usable[hyperiond ComponentRegister] <DEBUG> <ComponentRegister.cpp:36:setNewComponentState()> LED device: disabled

If I set the entertainment group to {"stream":{"active":false}} before starting, the same error occurs:

[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Streamer Debug            : yes
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL DebugLevel                : [4] Verbose
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Servername                : Hue
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Host                      : <IP_ADDRESS>
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Port                      : 2100
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() PSK                           : 321c0c2ebfa7361e55491095b2f5f9db
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() PSK-Identity                  : 2bd7034a81ab11eab438000c29d8d52d
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Transport Type            : DTLS
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Seed Custom               : dtls_client
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Retry Left                : 5
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Read Timeout              : 0
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Handshake Timeout min     : 400
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Handshake Timeout max     : 1000
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:183:configLog() SSL Handshake attempts        : 5
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:91:init() Successfully parsed <IP_ADDRESS> as an ip address.
[hyperiond LEDDEVICE]  ProviderUdpSSL.cpp:122:init() UDP SSL using <IP_ADDRESS>:2100
[hyperiond LEDDEVICE]  LedDevicePhilipsHue.cpp:563:getJson() GET: [http://<IP_ADDRESS>:80/api/2bd7034a81ab11eab438000c29d8d52d/groups/4]
[hyperiond ComponentRegister]  ComponentRegister.cpp:36:setNewComponentState() LED device: enabled
[hyperiond LEDDEVICE]  LedDevicePhilipsHue.cpp:613:handleReply() Reply.httpStatusCode [200]
[hyperiond LEDDEVICE]  LedDevicePhilipsHue.cpp:630:handleReply() Reply: [{"action":{"bri":221,"ct":0,"hue":10105,"on":false,"sat":254,"xy":[0.4356,0.4967]},"class":"TV","lights":["1"],"locations":{"1":[0,0.7,0]},"state":{"all_on":false,"any_on":false},"stream":{"active":false,"owner":null,"proxymode":"auto","proxynode":"/bridge"},"type":"Entertainment"}]
[hyperiond LEDDEVICE]  LedDevicePhilipsHue.cpp:1195:startStream() Start entertainment stream
[hyperiond LEDDEVICE]  LedDevicePhilipsHue.cpp:587:putJson() PUT: [http://<IP_ADDRESS>:80/api/2bd7034a81ab11eab438000c29d8d52d/groups/4] [{"stream":{"active":true}}]
[hyperiond HYPERION]  PriorityMuxer.cpp:238:setInputImage() Priority 0 is now active
[hyperiond HYPERION]  PriorityMuxer.cpp:333:setCurrentTime() Set visible priority to 0
[hyperiond HYPERION]  PriorityMuxer.cpp:198:setInput() Priority 254 is now active
[hyperiond X11]  GrabberWrapper.cpp:49:start() Grabber start()
[hyperiond HYPERION]  Hyperion instance 'First LED Hardware instance' has been started
[hyperiond X11GRABBER]  Update of screen resolution: [0x0]  to [3280x1200]
[hyperiond X11GRABBER]  Using XRender for grabbing
[hyperiond X11GRABBER]  Update output image resolution: [0x0]  to [410x150]
[hyperiond X11GRABBER]  Capture interface is now enabled
[hyperiond HYPERION]  PriorityMuxer.cpp:238:setInputImage() Priority 250 is now active
[hyperiond LEDDEVICE]  LedDevicePhilipsHue.cpp:613:handleReply() Reply.httpStatusCode [200]
[hyperiond LEDDEVICE]  LedDevicePhilipsHue.cpp:630:handleReply() Reply: [[{"success":{"/groups/4/stream":{"active":true}}}]]
[hyperiond LEDDEVICE]  Device disabled, device 'philipshue' signals error: 'set stream to true: Bridge response is not Valid'
[hyperiond LEDDEVICE]  Philips Hue Entertaiment API could not initialisized!

@SJunkies Currently, if one configures the bridge manually via IP(e.g. for diyHue), plus having a valid username configured, the wizard does not continue. This is due to the fact that the username  configured is not passed to the brigde checking.
The following changes passes the configured username and one can use the wizard.
That also works with diyHue and manual IP-Config.
Please have a look, if the suggested changes are not in conflict with other logic. I have not tested it in all combinations....
//check if ip is empty/reachable/search for bridge
if(eV("output") == "")
{
getHueIPs();
}
else
{
var ip = eV("output");
$('#ip').val(ip);
hueIPs.push({internalipaddress : ip});
checkHueBridge(checkBridgeResult, $('#user').val());
}
$('#retry_bridge').off().on('click', function(){
hueIPs.push({internalipaddress : $('#ip').val()});
hueIPsinc = 0;
checkHueBridge(checkBridgeResult, $('#user').val());
});

@SJunkies Currently, if one configures the bridge manually via IP(e.g. for diyHue), plus having a valid username configured, the wizard does not continue. This is due to the fact that the username configured is not passed to the brigde checking.
The following changes passes the configured username and one can use the wizard.
That also works with diyHue and manual IP-Config.
Please have a look, if the suggested changes are not in conflict with other logic. I have not tested it in all combinations....
//check if ip is empty/reachable/search for bridge
if(eV("output") == "")
{
getHueIPs();
}
else
{
var ip = eV("output");
$('#ip').val(ip);
hueIPs.push({internalipaddress : ip});
checkHueBridge(checkBridgeResult, $('#user').val());
}
$('#retry_bridge').off().on('click', function(){
hueIPs.push({internalipaddress : $('#ip').val()});
hueIPsinc = 0;
checkHueBridge(checkBridgeResult, $('#user').val());
});

I compiled with these changes. And so far so good! Wizard is working!

fyi: I changed the Philips Hue wizard to recognize non-original bridges!
Unfortunately it is not yet an SSDP solution, so the IP must still be entered manually, but I have changed the check to the IP/api/config URL so that it works at all ;)
It should also work for other bridge alternatives...but myself have not tested any other than the DIYHue ....
The username (+ clientkey) for non-original bridges, can now also be created using the wizard.

@BTopbas
Did everything work now and the issue can be closed or are there any other problems with the current version?

@SJunkies Yep. Everything works! Thanks for your hard work and effort! I am closing the issue.

Thank you!!!


Shows different tag values when client and server differ

This does the minimal needed to show that there are different values for
the same tag, between a client and a server. Future work could be
considered to answer who sent what value. In the mean time, users can
inspect the JSON button when this occurs.
Fixes #2390
Before: different values were swallowed

After: different values are displayed

LGTM

thanks for taking a look!

If show like these would be better ?
http.path (C [or Client])    /content/persional
http.path (S [ or Server])    /content/persionals

@ldcsaa how to design UX for this is a separate issue as there are many ways to do that. want to open one? It will take some time to get feedback on it, which is why I solved the underlying problem seperately

OK~
I create a new issue #2397


rollback to PyQt4 version so we can have a qt4 branch

Created from revision 257683a. Fixes https://github.com/conda-forge/pyqt-feedstock/issues/20

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I'm going to merge this as it is since it only restores the old recipe.

Thanks a lot @gillins for the quick response.


Preparation for enabling the  inlining of generics

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test Linux

@swift-ci please test

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 386064b38253caefe9ec0b045574177f4524123f
Test requested by - @swiftix

Why do you disable generic inlining when creating pre-specializations?

@slavapestov Because the generic methods we want to pre-specialize get inlined instead into the caller inside SwiftOnoneSupport.swift

Would a more general solution be to prefer specialization to generic inlining if all substitutions are concrete?

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 386064b38253caefe9ec0b045574177f4524123f
Test requested by - @swiftix

@slavapestov In fact, the PR tries to do exactly  this https://github.com/swiftix/swift/blob/386064b38253caefe9ec0b045574177f4524123f/lib/SILOptimizer/Transforms/PerformanceInliner.cpp#L325-L328 among other things. But it didn't work for pre-specializations somehow.

Might be worth investigating :)

Yes, but it is not critical at the moment. I'm more curious about the Linux runtime crashes.

@swift-ci please test

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 386064b38253caefe9ec0b045574177f4524123f
Test requested by - @swiftix

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 386064b38253caefe9ec0b045574177f4524123f
Test requested by - @swiftix

@swift-ci please smoke test Linux

please smoke test Linux

@swift-ci please smoke test Linux

@swift-ci please test


int_sequence slicing in timeseries_dataset_from_array from Chapter 10

Hi all,
I'm wondering if this line of code
data=int_sequence[:-3],
could be modified to be
data=int_sequence[:-1],
for at least the output seems fine:
[0, 1, 2] 3
[1, 2, 3] 4
[2, 3, 4] 5
[3, 4, 5] 6
[4, 5, 6] 7
[5, 6, 7] 8
[6, 7, 8] 9

 I have received your E-mail——Steven Lee


Issue with syntax highligting in Raw block on Windows

Description
My simple typst document looks like this:
#show raw.where(lang: "rust"): set raw(theme: "VisualStudioDark.tmTheme")

```rust
// test
pub struct Wow { hi: u64 }
let logical: bool = true;
fn blah() -> u64 {}
```

VisualStudioDark.tmTheme can be any theme but important is to use some distinct color (like red) for variable scope so hi variable will be red in output pdf. Problem is that everyting is colored except variable scope so hi stays black. I thought this must be some issue with my template file but after long investigation and switching to Linux and using very same example ... it works, and hi becomes red in output pdf. So I guess this must be something specyfic to windows.
On Windows I am using Typst 0.12 and on Linux i compiled source from 0.12 branch.
Reproduction URL
No response
Operating system
Windows
Typst version

[X] I am using the latest version of Typst

Could you share the .tmTheme file you're having this problem with?

@PgBiel  sure (please change extension from txt to tmTheme)
VisualStudioDark.txt

It appears like this to me in both Linux and the web app. Seems like the theme is the culprit (if that's not the intended output).

The fact that it was different on your Linux machine was likely due to user error (either using a different Typst version, a different theme file, or something else).

@PgBiel hmm you are right, I had to mess something up at some point with my files. Sorry for that. Closing.


[Feature] Compatibility with Tidy5e-Sheet

Please make this compatible with Tidy5E-Sheet.
When using both, the button to trade with another player doesn't appear.

Let's Trade is compatible with Tidy5e Sheet, but to trade the actor must be assigned to a player (via the player configuration menu), and the player must be online.

Let's Trade is compatible with Tidy5e Sheet, but to trade the actor must be assigned to a player (via the player configuration menu), and the player must be online.

Was able to reproduce after the latest update of Tidy5e Sheet (Had to delete old version and reinstall)
The trade menu for items does appear in the right-click context menu, but has no text label. While the currency trade icon does not get added.

Was able to reproduce after the latest update of Tidy5e Sheet (Had to delete old version and reinstall)
The trade menu for items does appear in the right-click context menu, but has no text label. While the currency trade icon does not get added.

This has been resolved in the release 0.2.0 branch.

This has been resolved in the release 0.2.0 branch.


ios 7 bug: Terminating app due to uncaught exception 'NSGenericException', reason: 'Data tasks are not supported in background sessions.

bug,only crash in ios 7; ios 8 work;
Terminating app due to uncaught exception 'NSGenericException', reason: 'Data tasks are not supported in background sessions.'

sorry,I restart mac, it become ok!
I just install sdk 7.1, soon run code, the above problem occurs!
Now is ok!! sorry!!!!


JLine 3.24.0 and JAnsi 2.4.0.

Fix #7371

This PR is still waiting for an update on sbt/jline2.
I would much appreciate also if it could be cherry-picked to what ever is the next release

JLine 3.24 doesn't work on JDK 8 — better stop at 3.23 (reference: https://github.com/scala/scala-dev/issues/856)

JLine 3.24 contains the fix I need. I could ask the developer of JLine to backport it to 3.23.1, but I don't know how he will feel about it since no other such patch releases have been done in the past.
Does this imply that scala will try to support JDK8 for ever?

Does this imply that scala will try to support JDK8 for ever?

Unclear. So far, it hasn't really been that painful for us and isn't really holding us back. Perhaps at some point we'll decide a tipping point has been reached for the costs of continuing support have become too high.
Anyway, it's a moot point for now, as I see that the JLine 3 maintainer just said that they will restore JDK 8 support in 3.24.1.

Updated the PR with JLine 3.24.1 (was 3.24.0)

@eed3si9n did you get a chance to release sbt/jline2 already? If you could tell the version number, I can update it to this PR.

Yea, I released it - https://repo1.maven.org/maven2/org/scala-sbt/jline/jline/2.14.7-sbt-9c3b6aca11c57e339441442bbf58e550cdfecb79/

When I take current 1.10.x, run sbt publishLocal, then rm -rf ~/.sbt/boot/scala-2.12.18/org.scala-sbt/sbt/1.9.7-SNAPSHOT and then try 1.9.7-SNAPSHOT in a test project, I get
➜ sbtproj sbt
[info] [launcher] getting org.scala-sbt sbt 1.9.7-SNAPSHOT  (this may take some time)...
java.lang.NoClassDefFoundError: org/jline/terminal/spi/JansiSupport
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1027)
	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
	at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
	at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
	at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:714)
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:580)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:580)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:580)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	at sbt.internal.util.JLine3$.<init>(JLine3.scala:53)
	at sbt.internal.util.JLine3$.<clinit>(JLine3.scala)
	at sbt.internal.util.Terminal$.newConsoleTerminal(Terminal.scala:805)
	at sbt.internal.util.Terminal$.withStreams(Terminal.scala:386)
	at sbt.xMain$.withStreams$1(Main.scala:88)
	at sbt.xMain$.run(Main.scala:123)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at sbt.internal.XMainConfiguration.run(XMainConfiguration.java:59)
	at sbt.xMain.run(Main.scala:47)
	at xsbt.boot.Launch$.$anonfun$run$1(Launch.scala:149)
	at xsbt.boot.Launch$.withContextLoader(Launch.scala:176)
	at xsbt.boot.Launch$.run(Launch.scala:149)
	at xsbt.boot.Launch$.$anonfun$apply$1(Launch.scala:44)
	at xsbt.boot.Launch$.launch(Launch.scala:159)
	at xsbt.boot.Launch$.apply(Launch.scala:44)
	at xsbt.boot.Launch$.apply(Launch.scala:21)
	at xsbt.boot.Boot$.runImpl(Boot.scala:78)
	at xsbt.boot.Boot$.run(Boot.scala:73)
	at xsbt.boot.Boot$.main(Boot.scala:21)
	at xsbt.boot.Boot.main(Boot.scala)
Caused by: java.lang.ClassNotFoundException: org.jline.terminal.spi.JansiSupport
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	... 34 more
[error] [launcher] error during sbt launcher: java.lang.NoClassDefFoundError: org/jline/terminal/spi/JansiSupport

@hvesalai  / @eed3si9n  does it work for you?

macOS 14.2, OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)

I can reproduce the problem. The fix is to bump the version number to 1.10.0-SNAPSHOT. This is likely side effect of multi-repo (Zinc etc) using util packages from sbt/sbt but with 1.10.0-M1.

Thanks Eugene, that fixes it 👍


[radicle-funding-nft] add strategy: radicle-funding-nft, community tokens

Changes proposed in this pull request:

adding radicle-funding-nft strategy to list of strategies and  strategies/index.ts, using funding-subgraph-v4 of radicle.

@AmirSarraf Hi, thanks for your contribution, how did you find this, are you aware there is a bounty on Gitcoin for this strategy?

yes, actually i found this bounty from Gitcoin,
I added a link to the PR at Gitcoin

@AmirSarraf Looks good! Can you just rename the strategy to "radicle-community-tokens" ? Thanks!

Strategy is live: https://snapshot.org/#/strategy/radicle-community-tokens

@AmirSarraf There seem to be some issue with the strategy when we test it on the playground here: https://snapshot.org/#/playground/radicle-community-tokens
The strategy fail to resolve some time or give no results. Feel free to contact us on Discord here: https://discord.snapshot.org to discuss about this issue


Error in documentation - Dynamics 365 not covered

In the intro on this page it states:

The Emissions Impact Dashboard for Azure gives you transparency on the carbon emissions generated by your usage of Azure and Microsoft Dynamics.

Sadly, Dynamics 365 is not covered. So it should be something like this:

The Emissions Impact Dashboard for Azure gives you transparency on the carbon emissions generated by your usage of Azure.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 82f8dd20-599d-ab7f-a1db-7e2b5310abb1
Version Independent ID: 897a9588-8a69-dc64-6722-fd2c731f0f03
Content: Connect to the Emissions Impact Dashboard for Azure - Power BI
Content Source: powerbi-docs/connect-data/service-connect-to-emissions-impact-dashboard.md
Service: powerbi
Sub-service: powerbi-template-apps
GitHub Login: @andreabichsel
Microsoft Alias: rosode

Thanks for your comment, @MaVergau. This issue has been assigned to the doc author for review.

@MaVergau - I started an email thread for this.


refactor(let): Cleaned up the exec ecu code a lot

I needed to clean this up a bit to make it easier to follow. I could refactor more, but I have to get back to other stuff now.

I've added fixes for 3/4 of yours FIXMEs ~ feel free to provide thoughts :)
I'm unable to test if it works, though. I don't have access to a VM that compiles branelet with the appropriate GLIBC dependency, and the make.py is broken in this branch so I can't run the in-container compilation. I don't suppose you have a setup available to make it work?
Longer-term fix: bring back in-container compilation. Workaround: #191 and update the Dockerfile to an Ubuntu version that is more reasonable to compile to.

I think we can compile it using the new Makefile, however I am more limited by my broken Brane configuration which I am still trying to figure out. I will take a look once that is fixed (more important than this PR anyway). Thanks for the fixes, though!


Fails JSHint

Any chance of getting this script to pass JSHint? The app I'm trying to incorporate it into fails to build do to the errors found.

Linters should only be run on your own code because everyone has different styles. The code already passes in ESLint+XO
What issues are you seeing, anyway?


Suggestion/Feature request | Netherite Sword requirement

Can a config option be added to require a Netherite Sword in the crafting recipe instead of a stick?
I feel like the sword is OP and would like to increase the difficulty of obtaining it even more.

Recipes can be changed using recipe editing mods.


Corrects word in README

Alumni was used where Admin was likely intended creating duplication.

Looks good!

🏴☠


Add support for the DS record

Also updated tests to add a new DS record for a sub zone along with updates since an existing DS records is now handled

Is superseded by https://github.com/octodns/octodns-powerdns/pull/50 if https://github.com/octodns/octodns/pull/1065 is merged

Is superseded by #50 if octodns/octodns#1065 is merged

We'll need to stick with this one for now since it will work with older versions of octoDNS.
Once https://github.com/octodns/octodns/pull/1065#pullrequestreview-1634283518 is merged and released we can merge https://github.com/octodns/octodns-powerdns/pull/50 if/when we're OK with putting a hard requirement on the (new) version of octoDNS.

Thanks

Thank you for merging it (and doing so so quickly)!


List Commit Comments

List comments on a commit. Depends on #12

Having machine issues. I appear to not be able to locate a package via ubuntu.

I am not having your issue; would like to take a look at your system
configuration in the morning. It's possible that something is wrong with
the pom.xml, but I would expect that to produce an issue for me as well.
On Mon, Nov 19, 2018, 12:09 AM SupahSprinkle<EMAIL_ADDRESS>wrote:

Having machine issues. I appear to not be able to locate a package via
ubuntu.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/CompassSoftware/GDET-Tremendous-Trio/issues/17#issuecomment-439773284,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Apyb5qhJ8kR1Gpi5XuGD1pjFI2YBPpJbks5uwjz4gaJpZM4YWsJ2
.

Addressed in #44


Fixes arrayMin

Addresses Issue: #241

[x] Running yarn lint does not trigger any linter errors
[x] The test of the method you have fixed is passing
[x] You have written a new skeleton method for someone else to work on!
[x] You have written tests to accompany your skeleton method

Okay I'll get on to it. Sorry I missed that!

@BlakeGuilloud I have added some more stuff. Please check and let me know.


[FEATURE] initialize mongoose

⭐ Suggestion
Before implementing the modules we should initialize the mongoose logic first.
💻 Use Cases
No response
❌ Related Problems
No response

Closing #230


440: Refactoring functional tests to support reusing test logic across multiple versions

Refactoring functional tests to support reusing test logic across multiple versions which are functionally identical
Versions 3.1.8 and 3.1.9 are functionally equivalent for all the schemas (except VRPs which we currently don't have tests for). We would like to be able to run tests against the different versions that we support to verify that the controllers behave identically.
Refactored tests to allow the version to be plugged in, which enables us to execute the same logic against different API endpoints.
GetAccountBalancesTest demonstrates how simple test cases can be refactored, extracting a single test method which the version can be plugged into. This works as both of the methods are identical except for the urls.
CreateDomesticPaymentsConsentsv3_1_8Impl, CreateDomesticPaymentsConsentsv3_1_8Test and CreateDomesticPaymentsConsentsv3_1_9Test demonstrate a pattern for more complex test cases where there are multiple test cases that we want to reuse. Here we extract a class with the test logic and have separate version specific Test classes which invoke the test methods from JUnit.
The existing CreateDomesticPaymentsConsentsTest class has marked as deprecated and only contains tests for versions prior to 3.1.8 - as it was deemed too much effort to refactor these when it is likely that we will drop support for older versions in the future.
Issue: https://github.com/SecureBankingAccessToolkit/SecureBankingAccessToolkit/issues/487

NOTE: this is a draft demonstrating how we could solve the problem.
If this approach were to be accepted then I would expect to transform the tests under the accounts package following the pattern used in GetAccountBalancesTest and the payments package would follow CreateDomesticPaymentsConsentsv3_1_8Impl pattern.

It seems a clean solution to reuse tests logics I like it.
Maybe will be nice to move the implementation to his own package, as example payment/domestic/payments/consents/[common | shared | other | ???]

I agree, a package structure and class naming convention are needed.
I think I will also refactor the accounts package in the same fashion as payments (extracting Impl classes), in order to have one consistent approach which can be documented. Then in future when OBIE make breaking changes to the accounts API, it will be easier/cleaner to support multiple versions.

This PR has been superseded by https://github.com/SecureBankingAccessToolkit/securebanking-openbanking-uk-functional-tests/pull/34


feat: support watching specific namespaces

Checklist

[x] Update changelog in CHANGELOG.md.

Proposal
Make it possible to watch only for a specific set of namespaces for Silence CR changes.
Doesn't change the actual behavior of the operator as it remains cluster wide by default.
Breaking change in the CRD to make its scope Namespaced.

What's your use case to restrict it to namespace?

What's your use case to restrict it to namespace?

We have RBAC enforced on our clusters that strictly splits every client in its own namespace managed by a specific team.
So with the current implementation of silence-operator, we cannot let these specific teams manage silences since they only have rights to list resources in their authorized namespaces.

Any update @hervenicol ?

Sorry @maxime1907, end of year was a bit rough.
@QuentinBisson should be the one giving approval. In January hopefully, as he still is rather busy.

Sorry @maxime1907, end of year was a bit rough. @QuentinBisson should be the one giving approval. In January hopefully, as he still is rather busy.

Okay no problem, thank you for answering!

Any update/Are you still busy @QuentinBisson ?

Any updates on this?


NOJIRA: fix: updating the makefile go install command for ci, making tests ve…

Updates:

Added the verbose flag to go test in the makefile
Added the codecov script call to make test
Added the codecov script to the hack dir for use in CI
Fixed the go-install-tool directive in the makefile to respect vendoring (breaks dependency bin installs in CI)

/lgtm


Inference failing with mode="server"

How to run server mode inference?
I did standard pip installation and initialized the engine with engine = OpenOCR(mode="server")
---------------------------------------------------------------------------
FileNotFoundError                         Traceback (most recent call last)
Cell In[7], line 7
      4 logger = logging.getLogger("openrec")
      5 logger.setLevel(logging.ERROR)
----> 7 engine = OpenOCR(mode="server")

File /usr/local/lib/python3.10/dist-packages/openocr/tools/infer_e2e.py:152, in OpenOCR.__init__(self, mode, drop_score, det_box_type)
    150 cfg_det['Global']['pretrained_model'] = model_dir
    151 if mode == 'server':
--> 152     cfg_rec = Config(DEFAULT_CFG_PATH_REC_SERVER).cfg  # server model
    153     model_dir = check_and_download_model(MODEL_NAME_REC_SERVER,
    154                                          DOWNLOAD_URL_REC_SERVER)
    155 else:

File /usr/local/lib/python3.10/dist-packages/openocr/tools/engine/config.py:107, in Config.__init__(self, config_path, BASE_KEY)
    105 def __init__(self, config_path, BASE_KEY='_BASE_'):
    106     self.BASE_KEY = BASE_KEY
--> 107     self.cfg = self._load_config_with_base(config_path)

File /usr/local/lib/python3.10/dist-packages/openocr/tools/engine/config.py:120, in Config._load_config_with_base(self, file_path)
    117 _, ext = os.path.splitext(file_path)
    118 assert ext in ['.yml', '.yaml'], 'only support yaml files for now'
--> 120 with open(file_path) as f:
    121     file_cfg = yaml.load(f, Loader=yaml.Loader)
    123 # NOTE: cfgs outside have higher priority than cfgs in _BASE_

FileNotFoundError: [Errno 2] No such file or directory: '/usr/local/lib/python3.10/dist-packages/openocr/tools/../configs/det/svtrv2/svtrv2_ch.yml'

Thank you for your feedback, we have fixed this bug. Please install the latest version to enjoy it.
pip uninstall openocr-python
pip install openocr-python==0.0.6

Thanks!


[FR]: Interface switch

I would like to request a network interface toggle. I know I can set a toggle with a block all rule on the interface, but the current streams do not get disconnected. When you disable the IF the current streams are immediately cut off.

It would  be very great, when a switch for interfaces would be available.
I like to toggle the VLAN interface for the kids devices on/off conveniently from with Home Assistant.

@mzurhorst: you can do this by en-/disabling a manual outbound NAT rule. This way e.g. wifi connections will work, DHCP will work but phone devices show "no internet".


xephero DPS gauges are mis-alligned with 14.0.1

The overlay seems to have enough room, but it looks like it thinks it has less space than it does and is overflowing down a section. This is more noticable when there are multiple combatants, though it usually only affects the firs two.

Thanks.  I don't quite know why this started happening, but I've seen this too.  I may just rewrite the xeph dps parser to use grid instead of flexbox as it would help avoid these issues.


Use Cha-UI npm not git repo

In package.json, please refer to Cha-UI NPM package directly https://github.com/HPSoftware/cha-ui and https://www.npmjs.com/package/cha-ui
Do now refer to git+https://github.com/HPSoftware/cha-ui.git

@JonathanRosado @gmatoshp This might concern the integration with hubot-enterprise.


Issue with dithering on jpegdec

Hello,
While loading an image using jpegdec I'm getting a whole Buch of dots all over my image.
I am using "DISPLAY_PICO_DISPLAY_2"with a custom buffer size: display_buffer = bytearray(110080)
I'm using PEN_RGB332 for the colors but I don't see an option for removing dithering.
I had it working well with PEN_RGB565 but due to memory constraints and the fact that I am no longer using a 320x240 screen, the buffer is now too small to use PEN_RGB565.
Hardware: Pimoroni Pico lipo
Library: Pico Graphics
Screen: Adafruit 1.47" 320x172
How do I show the full image without dithering?
I am running Micro Python.
Code Snippet to load the JPEG:
j = jpegdec.JPEG(LCD)
# Open the JPEG file
j.open_file("Capture.jpg")
# Decode the JPEG
j.decode(25, 60, 3)
# Display the result
LCD.update()
Here is what is available to me with jpegdec
I don't see dithering options

That was, uh, planned:
https://github.com/pimoroni/pimoroni-pico/blob/82756a3fc99dd587ef2b77d629748e713dd4074f/micropython/modules/jpegdec/jpegdec.cpp#L129
But yes RGB332 mode should support quantized output.

I do have another solution I had developed loading a RAW image type. But the solution is very slow and requires the file to be converted to a RAW format. I was just hoping that maybe I missed the option for dithering and would prefer to load the image directly without dithering. Also, I would like to use the baked in libraries as much as possible.
Though the issue with speed is not really a problem for my current project since it is just a logo displayed on startup.

Should be fixed by #492
If you grab the appropriate build from https://github.com/pimoroni/pimoroni-pico/actions/runs/2839220919 and call decode like so: jpeg.decode(0, 0, dither=False) then it should posterise to the RGB332 colourspace instead.


Remove LinuxMain.swift

Swift 5.5+ Swift Package Manager warns that --enable-test-discovery is
enabled by default. I assume for this project that should mean this
isn't needed anymore on main.

thanks!


Can't grep individual tests in when running with mocha

When running with karma and mocha there is an option to execute only specific tests with a grep expression
karma start
karma run -- --grep="manager tests"

but this doesn't work when using the karma-sinon-chai plugin since the command line config is lost in the chai-adapter.js.
Replacing the following line in chai-adapter.js
karma.start();
with
karma.start(karma.config);
makes the mocha adapter pick up the grep argument and only execute the desired tests. Not sure if this is the correct place to fix it, but greping works as expected when the sinon-chai plugin is not included in the karma frameworks config.

As I see now in the implementation of the karma context (which the chai-adapter.js uses), it calls karma.start() by passing the karma.config, so your suggestion should be correct. I added this in version 2.0.2.


NPM pulls corrupted packages from Verdaccio instance

Describe the bug
When I perform a basic npm install in an application I am attempting to set up a dev. environment for corrupted packages end up being pulled from my Verdaccio proxy instance.
To Reproduce
Steps to reproduce the behavior:

Set up package.json for my project including adding my dependencies, etc.
Set my local system to use my Verdaccio instance: npm set registry [[Verdaccio Server URL]]:4873
Perform npm install within the directory I have the package.json in.

Results
I get a ton of output similar to the following:
npm http fetch GET 200 [[Proxy NPM<EMAIL_ADDRESS>6430ms
	npm WARN tarball tarball data for<EMAIL_ADDRESS>(sha512-NT8xYl7Vr3qPygisek3PlXqNROEjg48GXOEsDEc7c8lDBo3EB9Tf328fWJD0GbLtXZNhmmNNxwIe+qqPFFhFAA==) seems to be corrupted. Trying one more time.
	npm WARN tarball tarball data for<EMAIL_ADDRESS>(sha512-Ubldcmxp5np52/ENotGxlLe6aGMvmF4R8S6tZjsP6Knsaxd/xp3Zrh50cG93lR6nPXyUFwzN3ZSOQI0wRJNdGg==) seems to be corrupted. Trying one more time.
	npm WARN tarball tarball data for<EMAIL_ADDRESS>(sha1-1B/UIVTAWTQiy4PEc6OCiqdSW/U=) seems to be corrupted. Trying one more time.

Note the URL encoded name of the package, in this case @angular%2fplatform-browser-dynamic. I do not get this when I set my proxy to be https://registry.npmjs.org/
Expected behavior
I am able to perform an npm install just as if I were connected to the official registry.
Screenshots
N/A
Configuration and Log Files
verdaccio-log.txt
npm-verbose-log.txt
config.yaml.txt

You would need to provide more info. npm version. Are you behind a proxy? Environment conditions. I've never heard of this problem before.

Hi, thank you for the quick feedback:
NPM Version: Latest - 6.1.0 but it happens with other versions.
Node Version that Verdaccio is running on: 10.4.0
Node Version that Client is running on: 10.4.0
Environment: Windows Server 2012 (SP2)
The server that Verdaccio is not behind a proxy.

Hello @ckkoeber,
I don't think verdaccio stored corrupted packages on its file system,
i've already faced a similar problem and maybe it is the same for you.
In my case it happened because npm was trying to check the package integrity with a wrong hash.
Try deleting your npm-shrinkwrap.json and see if it solves

@lgaitan Thank you for the helpful hint. Forgive me if this is common knowledge: where would I find the npm-shrinkwrap.json file? I assume this is client-side.

Yes, it should be located on the project folder that you are trying to install.
it can be either npm-shrinkwrap.json or package-lock.json

OK, so after performing the following everything worked:
rmdir /S /Q node_modules
del package-lock.json
npm set registry [[Verdaccio Instance's IP]]:4873
npm cache clean --force
npm install --force --verbose --no-bin-links

Thank you everyone for the feedback.

Adding *nix variant:
rm -rf node_modules
rm package-lock.json
npm set registry [[Verdaccio Instance's IP]]:4873
npm cache clean --force
npm install --force --verbose --no-bin-links

definitively a package-lock.json is involved in this problem.
"rm package-lock.json" should never be done unless you don't care what you will distribute.
package-lock.json make that all the dependency of all your project dependency will never change. It the solution to prevent a crash in case someone bumb a sub sub sub dependency with bad code.
I can talk more longer why we should not do that but ... it not the place here.
When you will make  "npm install" a new package-lock.json will be create and the next "npm cache clear -force & npm install --force --verbose --no-bin-links" will give you the error "seems to be corrupted" again.
This bug seem to be only when you use npm (recent version) on windows. verdaccio can run on any type of machine (I try window and mac).
With old version of npm (5.6.0) it give something like
npm WARN tar zlib error: unexpected end of file
npm ERR! cb() never called!
It seem that we don't receive the complete tar file.
If we do "npm install" without clearing the npm cache many time, it work (it mean sometime the tar file is well transfered, sometime not). Also I see that the error is more often when we transfer big tar file, (in may case over 100meg)
note also that I see this error with sinopia 1.4 then it maybe a old bug (or a new one in npm).
note also that yarn don't have this problem (but it dont use package-lock.json anyway)
I have a felling that if the network is slow, we don't have this error ... but for now it just a felling.
(I have the bug more often when I run everything on same PC/virtual PC).
Hope it help

Git needed to be installed in the system
Then it would be a successful try from my end and the project has successfully run
or copy the node modules from the source file and paste it in the present project

after performing the following everything still not worked:

rmdir /S /Q node_modules
del package-lock.json
npm set registry [[Verdaccio Instance's IP]]:4873
npm cache clean --force
npm install --force --verbose --no-bin-links

npm version 6.7.0
verdaccio version 3.2.0
node version 10.15.0

Was able to solve the problem by turning off Verdaccio's 'cache'
uplinks:   npmjs:     url: https://registry.npmjs.org/     cache: false

If you turn of the cache, tarballs are not persisted affecting the registry performance. It is ok to do it but be aware of it.

I tried @luguidong solution and @2imagine solution both options did not resolve the corrupted package issue for me.

npm install
npm WARN tarball tarball data for<EMAIL_ADDRESS>(sha512-EPh38EQdkd9nngbSSB3Yqacqy4MxdnDHLVTP208M+bwQ7Apee5BwDgP4bMp/tKfw2b5Jk1W9w6s9Top5hbo2og==) seems to be corrupted. Trying one more time.
npm WARN tarball tarball data for<EMAIL_ADDRESS>(sha512-1dar+duEcH0+kVbiwf2xw0oCkm5UNPg5h7Qs9qa5Ak9wRnRq41yGYpjz8myzuLsQ2tEISc8FXiQdCG5wIt2UFQ==) seems to be corrupted. Trying one more time.
npm WARN tarball tarball data for<EMAIL_ADDRESS>(sha512-0RNDbSdEokBeEAkgNbxJ+BLwSManFy9TeXz8uW+48j/xhEXv1ePME60olyzw2XzUqUBNAYFeJadIqAgNqIACwg==) seems to be corrupted. Trying one more time.

PS > node --version
v10.16.0
PS > npm -v
6.9.0
using docker version verdaccio/verdaccio@latest
http address - http://<IP_ADDRESS>:4873/ - verdaccio/4.0.1


Increment Block Mined Stat on Player Block Destroy

Codecov Report

Merging #56 (3e39d7b) into master (4165f33) will increase coverage by 1.50%.
The diff coverage is 88.99%.

@@             Coverage Diff              @@
##             master      #56      +/-   ##
============================================
+ Coverage     23.95%   25.46%   +1.50%
- Complexity      695      703       +8
============================================
  Files           855      930      +75
  Lines         26733    28688    +1955
  Branches       2084     2172      +88
============================================
+ Hits           6405     7304     +899
- Misses        20264    21318    +1054
- Partials         64       66       +2

Impacted Files
Coverage Δ

...tlin/org/kryptonmc/api/effect/sound/SoundEvents.kt
100.00% <ø> (ø)

...ed/kotlin/org/kryptonmc/api/item/meta/DyeColors.kt
0.00% <0.00%> (ø)

...n/kotlin/org/kryptonmc/api/adventure/flattening.kt
0.00% <ø> (ø)

.../main/kotlin/org/kryptonmc/api/auth/GameProfile.kt
0.00% <0.00%> (ø)

...n/kotlin/org/kryptonmc/api/auth/ProfileProperty.kt
0.00% <0.00%> (ø)

...n/kotlin/org/kryptonmc/api/block/BlockHitResult.kt
0.00% <0.00%> (ø)

...in/kotlin/org/kryptonmc/api/block/meta/WoodType.kt
0.00% <0.00%> (ø)

...lin/org/kryptonmc/api/block/property/Properties.kt
100.00% <ø> (ø)

...tlin/org/kryptonmc/api/command/BrigadierCommand.kt
0.00% <0.00%> (ø)

...tlin/org/kryptonmc/api/command/InvocableCommand.kt
0.00% <ø> (ø)

... and 560 more

Continue to review full report at Codecov.

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


Add initial conformance results for Contour

What type of PR is this?
/area conformance
What this PR does / why we need it:
Adds initial conformance results for Contour's Gateway API implementation
Which issue(s) this PR fixes:
N/A
Does this PR introduce a user-facing change?:
NONE

/cc @skriss


Fix offset calculation in IE11

Coverage remained the same at 79.237% when pulling 7db927040be55a00509781adda29f5f85a2b1b0d on petrinecp:master into dc1fdcc1abd566e757aa071b2d3a28179ae4765a on lukasoppermann:master.


How to draw PMI(A,B)

Hi Phillipi
May I ask how could I generate the exact the same PMI(A,B) figure as you shown in Fig. 2 of the paper, which I think is very intuitive?

Hi zizhaozhang,
You can find code for that in viz_pmi_script.m.


Enhances the Physical Parametrizations/GMREDI docs section

What changes does this PR introduce?
This PR enhances the 8.4.1. GMREDI: Gent-McWilliams/Redi SGS Eddy Parameterization docs section. Specifically, the PR:

fixes some mathematical notation (bold for vectors, roman for subscripts, e.g., _{Redi} -> _{\rm Redi}
punctuates all equations
some minor rephrases in text to improve clarity

Does this PR introduce a breaking change?
No breaking changes are introduced.
Suggested addition to tag-index
(To avoid unnecessary merge conflicts, please don't update tag-index. One of the admins will do that when merging your pull request.)

ready for review! thanks!

I will take a look here. My issue with this doc section is that it needs a lot of work/much missing, will decide what if any to fix up as part of this PR. [I would add this package is very commonly used, so worth some investment of time]

thanks @mjlosch and @jrscott
I tried to address the comments. I didn't go through all bib entries tho.

for non-dim numbers we have opted for roman, which I think is more consistent with the notation standards here. FWIW done roman or italic in quick look at literature.

Did the next rung of lowest-hanging fruit fixup. Still remains much missing, and many parm descriptions are unclear or inadequate for this purpose, and need to be mentioned in context in the text. I need to go through the code a bit more, and @jm-c can we sit down to discuss a bit?

@jm-c @navidcy @mjlosch
Suggest we merge this set of changes (mostly, related to equation formatting and addition of parm tables)
I have started additional changes, a more serious fixup of this pkg doc (tapering doc/options, BVP and submeso, overall section order etc), that I will put in as a new PR. We can discuss changes/scope in this new PR further there.
I reviewed @navidcy's original changes. Suggest we merge master again, @navidcy take a quick look, then either @jm-c or @mjlosch check quickly, then merge. Don't fret about minor things unless very blatantly wrong, we'll address in new PR.

Yeap, merge master and merge to master ;)

@navidcy do you want to do the first step then, ie merge master? (steps are outlined in doc if unclear)
We'll do the second step :)

@navidcy do you want to do the first step then, ie merge master? (steps are outlined in doc if unclear)
We'll do the second step :)

Done :)

Regarding LDD97 tapering scheme, still not clear to me why we are adding this first expression while the second expression (i.e., the original one) does match the code and the paper.  Seems more likely to add confusion ?

Regarding LDD97 tapering scheme, still not clear to me why we are adding this first expression while the second expression (i.e., the original one) does match the code and the paper.  Seems more likely to add confusion ?

@jm-c feel free to revert to original?

@jm-c see 4e875f8

I was leaning toward suggesting to keep it, I don't think it is confusing per se, but agree with @jmc it is a bit odd w/o any explanation. Thinking being, it is important to convey to reader some sense of what this depth-tapering function looks like, and everyone immediately knows what sin^2 looks like but the coded expression is not something I can visualize in my head, without at least a bit of examination/thought.
But, better plan might me to include a simple plot of that function, similar to what's done earlier in fig 8.7+8.8 (and not include the sin^2 expression), for several S. Particularly given that c is hard-coded. This form is in the LDD paper's appendix but barely discussed, so some practical explanation here is helpful IMO. (would add this figure/can discuss further in new PR, let's merge this one in present form)

I was leaning toward suggesting to keep it, I don't think it is confusing per se, but agree with @jmc it is a bit odd w/o any explanation. Thinking being, it is important to convey to reader some sense of what this depth-tapering function looks like, and everyone immediately knows what sin^2 looks like but the coded expression is not something I can visualize in my head, without at least a bit of examination/thought.
But, better plan might me to include a simple plot of that function, similar to what's done earlier in fig 8.7+8.8 (and not include the sin^2 expression), for several S. Particularly given that c is hard-coded. This form is in the LDD paper's appendix but barely discussed, so some practical explanation here is helpful IMO. (would add this figure/can discuss further in new PR, let's merge this one in present form)

Regarding a future PR, I'd suggest we change the expression in the docs and the expression in the code. The fact that the paper is published with an expression 1/2 * (1 + sin(x - π/2)) instead of the simpler sin²(x/2) is just an oversight of the authors/reviewers and I don't think we should keep propagating it. A comment in the code noting this oversight is enough for people to not be confused.

I have a comment related to @jrscott changes:
I looked at the new doc, and while I agree that the new CPP option table and parameter table are very useful, I would prefer to keep the description section just after the introduction (a bit like what it was originally) and move these tables further down.
I recognize that several other pkg doc start with the option and params sections but I feel like it's easy to read and to follow when the basic description of the pkg comes first. So may be something we may want to change in some other pkg doc ?
Now back to pkg/gmredi doc, we could reorder the sub-section later (i.e., in an other PR) or, since the ordering was modified here, it could be nice to change it back to get the description section just following the introduction.

@jm-c shall I move (new) sections <IP_ADDRESS> and <IP_ADDRESS> to just before the GMREDI diagnostics list, as a first pass at this (for this PR)?

@jrscott

shall I move (new) sections <IP_ADDRESS> and <IP_ADDRESS> to just before the GMREDI diagnostics list

Yes, I think it would be nicer this way.

@jm-c I think this works. We can tweak a bit more in new PR but I think as a general layout this is good. Merge at this point? @timothyas you agree?

I could merge this PR soon (e.g., later today). @mjlosch do you agree ?

I am fine with this as it is. I can offer, though, to go through and restrict the line length to 79/80 (which is a number that we once found as a recommendation).  Let me know.

thx @mjlosch will take you up on that in new PR, once new text added etc.

Going to merge now.


fork command error: "Error: Cannot find module 'columnify'"

When trying to fork our app, I got this error
00:19:29.205 + heroku fork --app source-app target-app
00:19:29.857 module.js:339
00:19:29.857     throw err;
00:19:29.857           ^
00:19:29.857 Error: Cannot find module 'columnify'
00:19:29.857     at Function.Module._resolveFilename (module.js:337:15)
00:19:29.857     at Function.Module._load (module.js:287:25)
00:19:29.857     at Module.require (module.js:366:17)
00:19:29.858     at require (module.js:385:17)
00:19:29.858     at Object.<anonymous> (/home/vagrant/.heroku/node_modules/heroku-fork/node_modules/heroku-cli-util/columnify.js:2:17)
00:19:29.858     at Module._compile (module.js:431:26)
00:19:29.858     at Object.Module._extensions..js (module.js:449:10)
00:19:29.859     at Module.load (module.js:356:32)
00:19:29.859     at Function.Module._load (module.js:311:12)
00:19:29.859     at Module.require (module.js:366:17)

did it just happen one? or is it working now?

JUST happened. Working now.

I swear, our build infrastructure is like a heroku stress test. :)

I know what happened. I released a fork update and it was caught in the middle of updating (remember I removed the message stating that)
I had an idea to fix this issue without blocking while an update is taking place and without just showing an annoying message on stderr.
I was thinking I could lock on each plugin so you would only have to wait for a single plugin to finish updating (which wouldn't take long at all)
On Wed, May 13, 2015 at 4:12 PM, Taylor Brown<EMAIL_ADDRESS>wrote:

Closed #1567.
Reply to this email directly or view it on GitHub:
https://github.com/heroku/heroku/issues/1567#event-304396426

Unfortunately, it looks like it just failed again on the same build machine. I will try again. If I can't get this to work, do I need to update the fork command specifically?

Potentially, 'heroku plugins:install heroku-fork'
On Wed, May 13, 2015 at 4:53 PM, Taylor Brown<EMAIL_ADDRESS>wrote:

Unfortunately, it looks like it just failed again on the same build machine. I will try again. If I can't get this to work, do I need to update the fork command specifically?
Reply to this email directly or view it on GitHub:
https://github.com/heroku/heroku/issues/1567#issuecomment-101853117

I think I figured this one out. The updater was touching the ~/.heroku/autoupdate file so it knows the last time it updated AFTER it finished updating. Because some commands call the v4 cli 2-3 times, this means that 2-3 updates would be triggered all at once. I fixed it by checking to see if an update is needed right before performing it.
Let me know if you see it again though.


Smoke alarm batteries changed chore tracker 🔥🔋📅

Create two new input_datetime entities to record when I last changed my Nest smoke alarm batteries. This evening my cast iron pan got the better of me and triggered my Nest smoke alarms. I caught the warning but apparently the smoke was too much and the siren went off. Shortly after silencing the alarms, they both started beeping periodically to indicate their batteries were low.
I'll create an automation to remind me to check the batteries every three months and to change them each year. I think I haven't changed them in two years.

#HomeAssistant input_datetime integration documentation - https://www.home-assistant.io/integrations/input_datetime/

I guess them beeping at you isn't enough to remind you to change the battery ? :-)

I guess them beeping at you isn't enough to remind you to change the battery ? :-)

This time around it was fine. But I'd rather not have low batteries in them when I actually need them. Until Nest becomes available there is no harm in a subtle reminder to check them. I've been positioned once before by carbon dioxide and let's just say it wasn't very nice at all. Home Assistant always has my back so what are a couple more basic chores.

input_datetime fields created #221, just the notification reminder automation now.

Templating.
Date time: {{ as_timestamp(states.sensor.date_time.last_changed) }}
Now: {{ as_timestamp(now()) }}

Chore timestamp attribute: {{ state_attr('input_datetime.chore_nest_upstairs_batteries_last_changed','timestamp') }}
vs state: {{ as_timestamp(states('input_datetime.chore_nest_upstairs_batteries_last_changed')) }}

Seconds in 90 days (3 months): {{ (60*60*24)*90 }}
Seconds in a minute x by minutes in an hour x by hours in a day x by 90 days.

90 days has pasted: {{ as_timestamp(states.sensor.date_time.last_changed) >= (state_attr('input_datetime.chore_nest_upstairs_batteries_last_changed','timestamp') + (60*60*24)*90) }}
180 days has pasted: {{ as_timestamp(states.sensor.date_time.last_changed) >= (state_attr('input_datetime.chore_nest_upstairs_batteries_last_changed','timestamp') + (60*60*24)*180) }}
270 days has pasted: {{ as_timestamp(states.sensor.date_time.last_changed) >= (state_attr('input_datetime.chore_nest_upstairs_batteries_last_changed','timestamp') + (60*60*24)*270) }}
360 days has pasted: {{ as_timestamp(states.sensor.date_time.last_changed) >= (state_attr('input_datetime.chore_nest_upstairs_batteries_last_changed','timestamp') + (60*60*24)*360) }}
450 days has pasted: {{ as_timestamp(states.sensor.date_time.last_changed) >= (state_attr('input_datetime.chore_nest_upstairs_batteries_last_changed','timestamp') + (60*60*24)*450) }}
540 days has pasted: {{ as_timestamp(states.sensor.date_time.last_changed) >= (state_attr('input_datetime.chore_nest_upstairs_batteries_last_changed','timestamp') + (60*60*24)*540) }}

Date time:<PHONE_NUMBER>.055409
Now:<PHONE_NUMBER>.088987

Chore timestamp attribute:<PHONE_NUMBER>.0
vs state:<PHONE_NUMBER>.0

Seconds in 90 days (3 months): 7776000
Seconds in a minute x by minutes in an hour x by hours in a day x by 90 days.

90 days has pasted: False
180 days has pasted: False
270 days has pasted: False
360 days has pasted: False
450 days has pasted: False
540 days has pasted: False

#HomeAssistant binary_sensor integration documentation - https://www.home-assistant.io/integrations/binary_sensor/ and https://www.home-assistant.io/integrations/binary_sensor.template/

In the end, I created a template binary_sensor which is 'on' if the time elapsed since the batteries were changed falls into one of the days passed as shown above. This binary_sensor triggers an automation the reminds me to test/check the smoke alarms.

Persisting alerts
I could create an input_boolean and use an automation to turn this on when the template binary_sensor is turned on. Then these notifications/alerts could persist until the input_boolean is turned off through an actionable alert for example.


Settings tab for the plugin does not appear

I just installed the plugin via BRAT, and after installation, enabling, and also restarting Obsidian, the settings tab for the plugin does not seem to appear?

Thanks for the Issue I'll look into it!

I'm having the same issue.

Same issue on my side !

Yes sorry for the inconvenience! It should be fixed with the new release, please check and let me know if it works. Thanks for the feedback and patience.

Closing it as the issue didn't appear again with the new releas and further testing. Just comment if it occures again.


Flask rollout prep: TypeError: Object of type ProgrammingError is not JSON serializable

The third most common error we get in Flask that we don't get in PHP is a problem serializing a ProgrammingError. What is supposed to happen here?
First occurrence: Apr 23, 10:35 AM
Last occurrence: Apr 26, 3:49 PM
builtins:TypeError: Object of type ProgrammingError is not JSON serializable
Traceback(most recent call last):
File "/usr/local/lib/python3.7/site-packages/newrelic/api/wsgi_application.py", line 47, in __iter__
File "/usr/local/lib/python3.7/site-packages/newrelic/api/wsgi_application.py", line 454, in __iter__
File "/usr/local/lib/python3.7/site-packages/werkzeug/wsgi.py", line 506, in __next__
File "/usr/local/lib/python3.7/site-packages/werkzeug/wrappers/base_response.py", line 45, in _iter_encoded
File "/usr/local/lib/python3.7/site-packages/flask/helpers.py", line 162, in generator
File "/app/app/_printer.py", line 57, in gen
File "/app/app/_printer.py", line 84, in _error
File "/usr/local/lib/python3.7/site-packages/flask/json/__init__.py", line 211, in dumps
File "/usr/local/lib/python3.7/json/__init__.py", line 238, in dumps
File "/usr/local/lib/python3.7/json/encoder.py", line 199, in encode
File "/usr/local/lib/python3.7/json/encoder.py", line 257, in iterencode
File "/usr/local/lib/python3.7/site-packages/flask/json/__init__.py", line 100, in default
File "/usr/local/lib/python3.7/json/encoder.py", line 179, in default

do we collect the logs somewhere?

Yes -- @korlaxxalrok can set you up with an Elastic account; then this query will get you the Docker logs for the Flask server.

closing for now since a possible fix has been merged. If it still occurs we can open the issue open up again


Added Cabin Analytics

https://withcabin.com
No cookies or consent banners
Faster, lighter and greener
No data sharing or ad networks
Compliant with all privacy laws

Is this available for self-hosting?

Currently not, but we may work on it if there is a desire for self hosting.

After a review of your site, docs and privacy policy, Cabin looks good to me! A good next-step would be to allow users self-hosting their instance, so they can be in control of the data.