Autoscroll to a certain tab

Is there a way, or could you point me in the right direction to creating a method like .scrollTo(tabid)
which would tell the scroller to scroll until the desired tab is in the visible part of the nav bar?
I am working on an application where new tabs can be added dynamically while a user is on the page, and we would like to have the user to notice a newly added tab, even if it is int he overflow.
Any direction is super helpful, thanks again!

I actually have an application that is somewhat similar, and the function tabSet.scrollSelectedIntoView() already exists to scroll to where the selected tab is visible. Apparently I never added that one to the documentation.
If you need it to not be the selected tab, but rather a tab with a given ID or classname, you can use the methodology found here in the codebase, but swap out some jQuery Selectors:
https://github.com/joshreed/jQuery-ScrollTabs/blob/master/js/jquery.scrolltabs.js#L249-L265
Hopefully this is helpful!


Feature: Localization Support

Description
Elsa Studio currently has hardcoded UI strings, which poses challenges for non-English users and limits the reach of the tool. Introducing localization support will make Elsa Studio more accessible to a global audience.
Goals

Replace hardcoded strings with a mechanism that supports multiple languages.
Ensure that the solution is maintainable, scalable, and allows community contributions for new language support.

Proposed Solutions
There are several ways to handle localization in Blazor applications. Here are some of the popular methods:

Embedded Resources: This approach involves creating .resx files for each supported language. These resource files can be embedded in the application, and Blazor has built-in support for using them. It's a common .NET approach and might be familiar to many .NET developers.
Pros:

Strong IDE support, especially in Visual Studio.
Built-in .NET support.

Cons:

Might be cumbersome when dealing with large amounts of text.
Requires a rebuild of the application for adding new languages or updating existing translations.

PO Files: PO files are a popular choice for localization, especially in the open-source world. They are easy to understand, and there are tools available for translation management.
Pros:

Simple and human-readable format.
Allows for easy community contributions without requiring a rebuild of the app.
There are various tools available for managing PO files.

Cons:

Requires additional libraries for integration with Blazor.

JSON/JS Libraries: Use JavaScript libraries like i18next in combination with Blazor JS interop. This approach involves storing translations in JSON files.
Pros:

Can leverage a wide range of existing frontend localization tools.
Flexible and can be used in combination with other frontend components if needed.

Cons:

Might be a bit overkill and require more JS interop than the other methods.

Recommendation
Given the nature of Elsa Studio being primarily a Blazor application, and the strong support of .NET for embedded resources, I would suggest starting with Embedded Resources. It provides a balance of familiarity for .NET developers and built-in support.
However, if there's a strong inclination towards community-driven translations and avoiding application rebuilds, PO Files would be a compelling choice.
Action Items

Decide on the localization strategy.
Replace hardcoded strings with the chosen localization method.
Document the process for contributors to add new language support.
Test the implementation with at least two languages to ensure the localization support works as expected.

This is a brief overview of how the GitHub issue might look. Depending on the team's familiarity and expertise, they might lean towards one method over the others.

Okay, I look forward to your excellent internationalization framework. It's difficult to use on projects without supporting internationalization

Thank you for sharing that feedback @jhgg75 !

Is there any progress regarding localization?


Idea: Add Standardlib to Eclipseplugin

It's kind of a hassle to download the Wurstpack separately and it is one of the last barriers to make WurstScript independent from the Editor.
One idea would be to have an automatically imported project when entering the Wurst Nature.
Not sure to what extent this is possible @peq so discuss!

see https://github.com/peq/WurstScript/issues/418


Client cancelled request should not return 5XX response

If a request is terminated early due to cancellation from the client side, we should not treat that as server error. Nginx uses 499 responses for client closed the connection. The main incentive to change the response code is to distinguish real server errors from client cancellation. A justified reason to cancel a request is latency, which should be monitored by the appropriate metrics.
Waiting for completion of #4291 .

So, to make things clear, we want to return 499, to be aligned with nginx?

Why shouldn't we return it to the client?
I assume that a client that cancelled a request is not interested in the status code anyhow. If the request was cancelled after a long time (> 2 min / 30 sec ?), then one might suggest that it wasn't the client that initiated the cancellation, rather some other component along the way. But we don't witness many requests to lakeFS that span for so long, so trying to optimize for these is premature.

No reason not to return it to the client, if the connection is still valid.
I'm just trying to figure what the phrasing should we use, as this is a custom status code. I'm thinking of a more general Request was cancelled. WDYT?


deleteColumn Method taking too much time to execute

myTable.deleteColumn(7, 1);

maybe more details to reproduce ?

How many rows do you have? Do you have events associated?

How many rows do you have? Do you have events associated?

10 Rows

That is probably link to any implementation inside events, there is no other reason to explain that and considering no further information was provided I am closing this one.


Question: Unit, Integration, and End-to-end Testing

I'm planning to use wdio-vscode-service for implementing end-to-end tests for a vscode extension. I also have @vscode/test-electron installed as part of the vscode docs on testing extensions. My original plan was something like:

e2e tests -  wdio-vscode-service
integration tests -@vscode/test-electron (if this makes sense)
unit tests - also @vscode/test-electron (same)

My questions:

For integration tests, does @vscode/test-electron offer anything that can't be done with wdio-vscode-service?
Same question for unit tests. I'm assuming it is not the best option, so also curious if there are any best practice recommendations here.

I am honestly not sure how "useful" @vscode/test-electron actually is, while you can run tests within a VSCode extension context, I would honestly either just write end-to-end tests for things that require interaction with VSCode APIs or write unit tests which mock out the VSCode interfaces. There is nothing you couldn't do with wdio-vscode-service that @vscode/test-electron can do. This package provides much better reporting capabilities and a richer ecosystem in general.
I will go ahead and close this issue but happy to provide further guidance.

@christian-bromann thanks for the confirmation.
Any precedence on what to use for unit tests? Also, any consideration on enabling github discussions on this repo? Not sure how often you get question tickets.

Any precedence on what to use for unit tests?

I am a big fan of Vitest, great tool and community.

Also, any consideration on enabling github discussions on this repo?

I think so far it has been ok, but definitely something worth to consider.


remove sleep from alerter retries

Codecov Report

Merging #597 (62bf453) into master (943e9ab) will increase coverage by 0.03%.
The diff coverage is 69.04%.

@@            Coverage Diff             @@
##           master     #597      +/-   ##
==========================================
+ Coverage   44.74%   44.77%   +0.03%
==========================================
  Files          46       46
  Lines        6819     6834      +15
==========================================
+ Hits         3051     3060       +9
- Misses       3768     3774       +6

Impacted Files
Coverage Δ

assemblyline_core/metrics/heartbeat_formatter.py
0.00% <0.00%> (ø)

assemblyline_core/alerter/run_alerter.py
53.08% <52.38%> (+1.65%)
:arrow_up:

assemblyline_core/alerter/processing.py
89.00% <83.33%> (+0.17%)
:arrow_up:

assemblyline_core/ingester/ingester.py
78.95% <100.00%> (ø)

assemblyline_core/server_base.py
82.12% <100.00%> (ø)

assemblyline_core/dispatching/dispatcher.py
75.83% <0.00%> (-0.12%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Contributing Guidelines for MONAI Tutorials

Is your feature request related to a problem? Please describe.
A set of contributing guidelines would be helpful for MONAI Tutorial as well, like we have for MONAI Core. For e.g it could begin with consisting formatting fixes and also the other list that are mentioned such as variable naming conventions etc.
Describe the solution you'd like
Just a contributing guidelines MD would be helpful

just realised this is duplicate of https://github.com/Project-MONAI/tutorials/issues/118


Rendering of the month grid exceeds the dialog box width

Great library.
When showing the picker dialog on iPhone SE (3rd generation) (mobile) simulator, a portion of the 4th column of the months (Apr, Aug, Dec) are rendered outside of the view of the picker dialog box. Please check the width setting of the month columns to see if it adapts to different screen width correctly. Thanks.

Tried on iPhone 14 Plus (mobile) simulator. Same issue. Same portion of the 4th month column (Apr, Aug, Dec) is shown outside of the dialog box.

yes, facing  same issue in the portrait mode in google pixel 4

Is there any workaround or method that expose the columns width?

anything on this?


Tint Color Lights doesn't switch colors

Hi,
I bought Zigbee 3 candles from tint with RGB support and paired them with my hue bridge just fine.
I use homebridge-hue 0.11.2.
Switching the lights on and off using homekit works just fine, also dimming seems to work. But if I try to change colors nothing happens and the light is shown as not responding. Although it is in fact responding and I can turn it off for example. Switching color using the Hue App oder Alex works.
My homebridge log constnatly repeats the following message:
[2019-1-28 09:14:37] [Hue] Flur 1: set homekit hue from NaN˚ to NaN˚
[2019-1-28 09:14:37] [Hue] Flur 1: set homekit saturation from NaN% to NaN%
[2019-1-28 09:14:37] [Hue] Flur 2: set homekit hue from NaN˚ to NaN˚
[2019-1-28 09:14:37] [Hue] Flur 2: set homekit saturation from NaN% to NaN%
[2019-1-28 09:14:37] [Hue] Flur 3: set homekit hue from NaN˚ to NaN˚
[2019-1-28 09:14:37] [Hue] Flur 3: set homekit saturation from NaN% to NaN%
[2019-1-28 09:14:37] [Hue] Flur 4: set homekit hue from NaN˚ to NaN˚
[2019-1-28 09:14:37] [Hue] Flur 4: set homekit saturation from NaN% to NaN%
My config.json for the homebridge-hue plugin looks as follows:
"platform": "Hue",
"host": "",
"users": {
"001788FFFE729A9A": "y5Ue3lTl0uU9epCSsPqi1J6Es8oXUSRqUwiGPgoc"
},
"hueMotionTemperatureHistory":true,
"sensors": false,
"lights": true,
"nativeHomeKitSensors": true,
"excludeSensorTypes": [],
"lowBattery": 25,
"nativeHomeKitLights": true,
"wallSwitch": true,
"groups": false,
"group0": false,
"rooms": false,
"schedules": true,
"rules": true,
"heartrate": 5,
"timeout": 10,
"resource": true,
"parallelRequests": 10,
"waitTimeResend": 300,
"waitTimeUpdate": 20
},
Any idea what I'm doing wrong? Any help is much appreciated.
Thank You!

Released v0.11.13 and unpublished the beta.

Sorry for my delayed response I was pretty busy the last days...I changed the setting "groups": true in config.json but here is no light that reflects that particular group. I honestly couldn't find any additional light after changing this setting. Did I miss anything?
Thanks a lot!

Yes I did restart homebridge...I also tried starting homebridge -D
You can see below, that groups is set to true.
I have to say that I have no standard room anymore, I deletetd it sometime ago. Could that be an issue? I would normalyy expect he group to appear in the same room where my homebridge is, but I'm not sure.
config.json: {"platform":"Hue","host":"","users":{"001788FFFE729A9A":"***************************************1"},"hueMotionTemperatureHistory":true,"sensors":false,"lights":true,"nativeHomeKitSensors":true,"excludeSensorTypes":[],"lowBattery":25,"nativeHomeKitLights":true,"wallSwitch":true,"groups":true,"rooms":false,"schedules":true,"rules":true,"heartrate":5,"timeout":10,"resource":true,"parallelRequests":10,"waitTimeResend":300,"waitTimeUpdate":20}

Okay I set rooms to true an now I have a light reflecting the four bulbs...if I set that to red it is really red but it ends up not responding while the 4 single bulbs in homekit are still responding

Just to be sure, could you re-run ph probe making sure that nothing changes the light state, while it's running.  If it yields the same results, I'll just ignore this and use the default gamut.

Good morning I ran ph -H <IP_ADDRESS> probe -v /lights/11 again...the output seems to differ for r:
ph probe: /lights/11: cool ... done
ph probe: /lights/11: warm ... done
ph probe: /lights/11: red ... done
ph probe: /lights/11: green ..... done
ph probe: /lights/11: blue ..... done
{
"manufacturername": "MLI",
"modelid": "ZBT-ExtendedColor",
"type": "Extended color light",
"bri": true,
"ct": {
"min": 153,
"max": 555
},
"xy": {
"r": [
0.5308,
0.2769
],
"g": [
0.1112,
0.7717
],
"b": [
0.1277,
0.1277
]
}
}

While ph probe is trying red, does the light look red or pink-ish?

It looked pinkish in my second try in my first try it looked more like red.

That’s odd.  Could I ask you to probe the other MLI lights?

Absolutely! Whatever it takes :-)
All four bulbs looked pinkish this time.
Another note from my side: I tried to change color using Alexa which is working accurate as well.
ph probe: /lights/11: cool ... done
ph probe: /lights/11: warm ... done
ph probe: /lights/11: red ... done
ph probe: /lights/11: green ..... done
ph probe: /lights/11: blue ..... done
{
"manufacturername": "MLI",
"modelid": "ZBT-ExtendedColor",
"type": "Extended color light",
"bri": true,
"ct": {
"min": 153,
"max": 555
},
"xy": {
"r": [
0.5245,
0.2337
],
"g": [
0.1112,
0.7717
],
"b": [
0.1277,
0.1277
]
}
}
ph probe: /lights/12: cool ... done
ph probe: /lights/12: warm ... done
ph probe: /lights/12: red ..... done
ph probe: /lights/12: green ......... done
ph probe: /lights/12: blue ..... done
{
"manufacturername": "MLI",
"modelid": "ZBT-ExtendedColor",
"type": "Extended color light",
"bri": true,
"ct": {
"min": 153,
"max": 555
},
"xy": {
"r": [
0.5245,
0.2337
],
"g": [
0.1112,
0.7717
],
"b": [
0.1277,
0.1277
]
}
}
ph probe: /lights/13: cool ... done
ph probe: /lights/13: warm ... done
ph probe: /lights/13: red ..... done
ph probe: /lights/13: green ..... done
ph probe: /lights/13: blue ...... done
{
"manufacturername": "MLI",
"modelid": "ZBT-ExtendedColor",
"type": "Extended color light",
"bri": true,
"ct": {
"min": 153,
"max": 555
},
"xy": {
"r": [
0.5245,
0.2337
],
"g": [
0.1112,
0.7717
],
"b": [
0.1277,
0.1277
]
}
}
ph probe: /lights/14: cool ... done
ph probe: /lights/14: warm ... done
ph probe: /lights/14: red ....... done
ph probe: /lights/14: green ..... done
ph probe: /lights/14: blue ..... done
{
"manufacturername": "MLI",
"modelid": "ZBT-ExtendedColor",
"type": "Extended color light",
"bri": true,
"ct": {
"min": 153,
"max": 555
},
"xy": {
"r": [
0.5245,
0.2337
],
"g": [
0.1112,
0.7717
],
"b": [
0.1277,
0.1277
]
}
}

All four bulbs looked pinkish this time.

Do you mean: the colour shown in HomeKit, or the actual colour of the bulb?
Different types of lights support different ranges of colours, depending on what LEDs they use for red, green, and blue.  They can only show colours that can be created from mixing their LEDs.  When setting a light to a colour that it doesn't support, it should switch to the supported colour that most closely matches the requested colour.  Typically, the light reports back the actual (supported) colour.
This leads to weird behaviour in apps: you set the colour to dark blue (which the light doesn't support); the app reflects dark blue, but the light is light blue.  The next time time the Hue bridge polls the light, the app reflects the light blue, so in the app the colour seems to change spontaneously, but the light colour does not change.
To overcome this weirdness, apps (like homebridge-hue) try to predict what colour the light will display, by taking into account the colours the light supports.  Then the app reflects the actual colour immediately.  This still seems a bit weird: you request dark blue but get light blue, but at least the app and the light are sync'ed.  There's no way in HomeKit to limit the selectable colours to only those that the light supports.
This prediction only works for lights, not for groups (that could contain different types of lights).
There's something weird with the MLI lights: setting xy to [0.9996, 0.0001] doesn't set it to red, but some pink-ish colour [0.5245, 0.2337].  When setting the light to red in the Hue app, it reports [0.6822, 0.3045] (from your log).  Clearly, the light's red point is not  [0.5245, 0.2337].
I'm not sure which values the Hue app generates.  Could you try ph put /lights/11/state '{"on": true, "xy": [0.8, 0.2]} and then continuously ph get /lights/11/state, until the xy values change (basically doing the same ph probe does, but now with different input values).  Wait like a minute or so, and double check that xy hasn't changed.
After that, maybe also try setting xy to [0.8, 0.4] to see if that results in different values.

All four bulbs looked pinkish this time.
Do you mean: the colour shown in HomeKit, or the actual colour of the bulb?

Sorry for the confusion I meant all bulbs were pinkish while  I was running ph probe. So the acutal bulbs where pinkish didn't check the home app at this point of time.
`ph -H <IP_ADDRESS> put /lights/11/state '{"on": true, "xy": [0.8, 0.2]}'
pi@raspberrypi:~ $ ph -H <IP_ADDRESS> get /lights/11/state
{
"on": true,
"bri": 254,
"hue": 0,
"sat": 254,
"effect": "none",
"xy": [
0.5799,
0.2609
],
"ct": 555,
"alert": "select",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
}
pi@raspberrypi:~ $ ph -H <IP_ADDRESS> get /lights/11/state
{
"on": true,
"bri": 254,
"hue": 0,
"sat": 254,
"effect": "none",
"xy": [
0.5799,
0.2609
],
"ct": 555,
"alert": "select",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
}
pi@raspberrypi:~ $ ph -H <IP_ADDRESS> get /lights/11/state
{
"on": true,
"bri": 254,
"hue": 0,
"sat": 254,
"effect": "none",
"xy": [
0.5799,
0.2609
],
"ct": 555,
"alert": "select",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
}
pi@raspberrypi:~ $ ph -H <IP_ADDRESS> get /lights/11/state
{
"on": true,
"bri": 254,
"hue": 0,
"sat": 254,
"effect": "none",
"xy": [
0.5799,
0.2609
],
"ct": 555,
"alert": "select",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
}
`
Result: The bulb's light is pinkish
ph -H <IP_ADDRESS> put /lights/11/state '{"on": true, "xy": [0.8, 0.4]}' pi@raspberrypi:~ $ ph -H <IP_ADDRESS> get /lights/11/state {   "on": true,   "bri": 254,   "hue": 0,   "sat": 254,   "effect": "none",   "xy": [     0.6109,     0.3718   ],   "ct": 555,   "alert": "select",   "colormode": "xy",   "mode": "homeautomation",   "reachable": true } pi@raspberrypi:~ $ ph -H <IP_ADDRESS> get /lights/11/state {   "on": true,   "bri": 254,   "hue": 0,   "sat": 254,   "effect": "none",   "xy": [     0.6109,     0.3718   ],   "ct": 555,   "alert": "select",   "colormode": "xy",   "mode": "homeautomation",   "reachable": true }
If  I set the bulb to red through the Hue app and query the state I get:
ph -H <IP_ADDRESS> get /lights/11/state {   "on": true,   "bri": 254,   "hue": 0,   "sat": 254,   "effect": "none",   "xy": [     0.6724,     0.3245   ],   "ct": 555,   "alert": "select",   "colormode": "xy",   "mode": "homeautomation",   "reachable": true }

v0.11.14 uses the default colour gamut for the MLI lights.

@Bluesmoke82 could you please attach the debug dump file of and the debug log file v0.11.14, when the lights turn blue?  What colour did you try to change the lights to, or does this happen with any colour?
@bierkules do you see the same in v0.11.14?

how can I get the debug log file for the version 14? isn't it deleted with the unistalling?
It didn't matter which color, every change changed it to blue.

See https://github.com/ebaauw/homebridge-hue#debug-log-file.  I'm afraid you have to re-install .14 to generate it.  I'm sorry, but I need to see what's happening.  The only change I made (for lights) between .13 and .14 is removing the specific colour gamut for the MLI lights.  I don't understand how that change could cause this, especially since using the group from HomeKit seemed to work.

Of course I understand that, I will try to get it done at the weekend.

Hi,
i have the same exact issue as Bluesmoke82 with the tint lights (Only with E14 sockets). They change to blue every time I try to change the color settings in the home app. The Tint E27 socket lights and the Tint lightstrips work fine in the current version of homebridge(0.11.42).
After Downgrading to 0.11.13 I can change the colors via the home app, but some colours which are achievable via the Philips Hue app are not possible to reach inside the home app (eg. strong yellow, it just results in a very whiteish yellow). When on 0.11.13, the Tint E27 and Tint Lightstrips also get these weak colors, while as I said before they can achieve better colors on 0.11.42.

My best guess is that the E14 has different firmware and/or supports a different colour gamut.  It defaults to blue (xy = [0, 0]) for unsupported colours.  You should be able to get colours out of the Home app, by selecting a more white-ish colour more towards the middle of the wheel.
Can you list the resource created by the Hue bridge and run ph probe -v on the light?  Please re-install latest homebridge-hue before running ph.

For the E14:
ph -H <IP_ADDRESS> probe -v /lights/29
ph probe: /lights/29: cool ... done
ph probe: /lights/29: warm ... done
ph probe: /lights/29: red ... done
ph probe: /lights/29: green ................ done
ph probe: /lights/29: blue ............ done
{
  "manufacturername": "MLI",
  "modelid": "ZBT-ExtendedColor",
  "type": "Extended color light",
  "bri": true,
  "ct": {
    "min": 153,
    "max": 555
  },
  "xy": {
    "r": [
      0.5245,
      0.2337
    ],
    "g": [
      0.1112,
      0.7717
    ],
    "b": [
      0.1277,
      0.1277
    ]
  }
}

For the E27 (which is working fine):
ph -H <IP_ADDRESS> probe -v /lights/27
ph probe: /lights/27: cool ... done
ph probe: /lights/27: warm ... done
ph probe: /lights/27: red ................ done
ph probe: /lights/27: green .............. done
ph probe: /lights/27: blue ................... done
{
  "manufacturername": "MLI",
  "modelid": "ZBT-ExtendedColor",
  "type": "Extended color light",
  "bri": true,
  "ct": {
    "min": 153,
    "max": 556
  },
  "xy": {
    "r": [
      0.5245,
      0.2337
    ],
    "g": [
      0.1112,
      0.7717
    ],
    "b": [
      0.1277,
      0.1277
    ]
  }
}

It is always switching back to blue, even if I repeatedly try to hit the middle (white). I can set different white temperatures from the white wheel, however.
The Homebridge log shows the following:
0|homebridge  | [2019-11-18 22:14:36] [Hue] Extended color light 1: homekit hue changed from 209˚ to 132˚
0|homebridge  | [2019-11-18 22:14:38] [Hue] Extended color light 1: set homekit hue from 132˚ to 209˚

No matter where I set it to, a few seconds later it gets reset to 209°, I do not know where the resetting command is coming from

And one afterthought:
When I move the color picker in the home app, it switches immediately after I stop touching it to the temperature picker while showing a blue dot

I do not know where the resetting command is coming from

Probably from reading back the state from the Hue bridge.  Could you capture a debug logfile (running homebridge -D), see https://github.com/ebaauw/homebridge-hue#debug-log-file.  This also logs the interaction with the Hue bridge.
Could you also attach the debug dump file, see https://github.com/ebaauw/homebridge-hue#debug-dump-file?

homebridge-hue.json.gz
homebridge1337.log.gz

Sorry, had a busy week and couldn't analyse the files earlier.
Debug log file:

You didn't try and set the colour while the collecting the log.
You're running a pretty old version of NodeJS.  I don't think it causing these issues, though.
Seems like there's a new version of the Hue bridge firmware I hadn't seen yet.  Again, probably not causing these issues.

Debug dump file:

The E27, /lights/27, and the E14, /lights/29, look the same from a ZigBee perspective (same manufacturername and modelid, except for the firmware version (swversion).  The E14 seems to have newer firmware.  The RGBW strip, /lights/28, seems to have a different firmware altogether.
The E27 has a Jennic mac address; the E14 and RGBW strip have a Silicon Labs mac address.  I'm curious as to what Manufacturer Code they report (in the Node Info panel in the GUI).  I expect the E27 and E14 to report the same; and maybe the RGBW strip to report a different one.
The E14 seems to report a valid gamut; the E27 reports rubbish (that's why homebridge-hue uses the default gamut for MSI lights, see https://github.com/ebaauw/homebridge-hue/commit/a9bb76ad40e95b3cb1b48d0dd952bab29d74b33d).  The RGBW strip reports no gamut at all.
The E27 and E14 report back the actual (?) colour, where the RGBW reports back the last colour set (hence the timeouts in ph probe).
Oddly, ph probe seems to find the same gamut for the E27 and the E14.  This could be an issue with ph probe and/or the MSI firmware.  I set xy to [1, 0] to discover red, expecting/hoping the light will display the closest supported colour, which should be the lower right corner of the triangle (see https://github.com/ebaauw/homebridge-hue/issues/439#issuecomment-459483394).  However, it would seem the light displays a colour somewhere on the bottom line, hence the pinkish colour instead of red.

When I move the color picker in the home app

The Home app doesn't like a light with both Hue/Saturation and Color Temperature characteristics.  Have you tried the Eve app?
Could you please try the following (while running homebridge -D, capturing the debug logfile):
$ ph put /lights/29/state '{"on": true, "bri": 254}'
$ ph put /lights/29/state '{"xy": [0.68, 0.31]}'
# Observe light colour - should be red, not pinkish
$ sleep 120
$ ph get /lights/29/state
$ ph put /lights/29/state '{"xy": [0.11, 0.82]}'
# Observe light colour - should be green
$ sleep 120
$ ph get /lights/29/state
$ ph put /lights/29/state '{"xy": [0.13, 0.04]}'
# Observe light colour - should be blue
$ sleep 120
$ ph get /lights/29/state
$ ph put /lights/29/state '{"on": false}'

Then repeat for /lights/27.
After that (still capturing the debug log file), play around some in the Hue app, setting both the E27 and the E14 to red, green, and blue, waiting a couple of minutes before changing it again.

Sorry for the late response, I was on a business trip.
homebridge241119-1.log.gz

The E27 has a Jennic mac address; the E14 and RGBW strip have a Silicon Labs mac address. I'm curious as to what Manufacturer Code they report (in the Node Info panel in the GUI).

Which GUI do you mean?

The Home app doesn't like a light with both Hue/Saturation and Color Temperature characteristics. Have you tried the Eve app?

Tried it, same behaviour as in the Home App

Setting the lights using ph seems to work as intended.  Did the lights show proper red, green, and blue colours?
I think you tried to change the lights from HomeKit after that?  Looks like you grouped the two lights in HomeKit?  That didn't work at first, since the lights don't accept any state changes while off.  After a while, you turned the lights and tried again.
It seems like homebridge-hue picked up the E27's advertised gamut.  The HomeKit app sends a couple of updates while selecting red in the colour wheel, but eventually, homebridge-hue sets xy to [0.68, 0.31], the advertised red point:
[2019-11-24 13:01:11] [Hue] Schreibtisch rechts 2: homekit saturation changed from 100% to 7%
[2019-11-24 13:01:11] [Hue] Schreibtisch rechts 2: homekit hue changed from 232˚ to 344˚
[2019-11-24 13:01:11] [Hue] Jessi: bridge request 987: put /lights/27/state {"xy":[0.3392,0.3226]}
[2019-11-24 13:01:11] [Hue] Jessi: bridge request 987: ok
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: homekit saturation changed from 7% to 81%
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: homekit hue changed from 344˚ to 355˚
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 989: put /lights/27/state {"xy":[0.6513,0.2959]}
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 989: ok
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: homekit saturation changed from 81% to 100%
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 991: put /lights/27/state {"xy":[0.68,0.31]}
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 991: ok
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: homekit hue changed from 355˚ to 352˚
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 993: put /lights/27/state {"xy":[0.68,0.31]}

When reading back the values from the bridge, the HomeKit Hue and Saturation get adjusted somewhat, but I guess this is to be expected from the RGB to CIEE 1931 back to RGB colour space transformations.
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 995: get /lights
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 995: ok
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: set homekit hue from 352˚ to 7˚
[2019-11-24 13:01:12] [Hue] Schreibtisch rechts 2: set homekit saturation from 100% to 92%

The E14 advertises a bogus gamut (all colour points at [0, 0]), but homebridge-hue applies it anyways, setting xy to [0, 0.0001], which, indeed, is blue!  I never set y to 0, since this would cause a divide by zero error converting the colour back to RGB.  I found some light firmwares also crash, presumably because of this.
[2019-11-24 13:01:11] [Hue] Extended color light 1: homekit saturation changed from 100% to 7%
[2019-11-24 13:01:11] [Hue] Extended color light 1: homekit hue changed from 209˚ to 344˚
[2019-11-24 13:01:11] [Hue] Jessi: bridge request 986: put /lights/29/state {"xy":[0,0.0001]}
[2019-11-24 13:01:11] [Hue] Jessi: bridge request 986: ok
[2019-11-24 13:01:12] [Hue] Extended color light 1: homekit saturation changed from 7% to 81%
[2019-11-24 13:01:12] [Hue] Extended color light 1: homekit hue changed from 344˚ to 355˚
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 988: put /lights/29/state {"xy":[0,0.0001]}
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 988: ok
[2019-11-24 13:01:12] [Hue] Extended color light 1: homekit saturation changed from 81% to 100%
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 990: put /lights/29/state {"xy":[0,0.0001]}
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 990: ok
[2019-11-24 13:01:12] [Hue] Extended color light 1: homekit hue changed from 355˚ to 352˚
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 992: put /lights/29/state {"xy":[0,0.0001]}
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 992: ok

When reading the value back, the Hue jumps to blue:
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 995: get /lights
[2019-11-24 13:01:12] [Hue] Jessi: bridge request 995: ok
[2019-11-24 13:01:12] [Hue] Extended color light 1: set homekit hue from 352˚ to 209˚

On the next poll, the light has adjusted the requested xy values to the actual values:
[2019-11-24 13:01:14] [Hue] Jessi: bridge request 997: get /lights
[2019-11-24 13:01:14] [Hue] Jessi: bridge request 997: ok
[2019-11-24 13:01:14] [Hue] Extended color light 1: light xy changed from [0,0.0001] to [0.1277,0.1278]

Double-checking the logic in homebridge-hue to determine the gamut:

Check if the model is whitelisted for a specific gamut;
Check if the manufacturer is whitelisted for a manufacturer default gamut;
Check if the bridge reports capabilities.control.colorgamut, without actually checking for all [0, 0];
Apply the default gamut of {"r": [0.9961, 0.0001], "g": [0, 0.9961], "b": [0, 0.0001]}.

As the MLI is no longer whitelisted, homebridge-hue takes the advertised gamut.  So I need to whitelist the MLI with the correct gamut, as advertised by the E27.  I'm not sure if the same gamut also applies to the RGBW strip.  Does that show a pinkish colour when setting it to red?

Could you please try<EMAIL_ADDRESS> Install by:
sudo npm -g i homebridge-hue@beta

It applies the gamut as advertised by the E27 to all MLI lights.  This should work for the E27 and the E14, but I'm not sure about the RGBW strip.  Could you see if that produces decent colours when set from HomeKit?

Setting the lights using ph seems to work as intended. Did the lights show proper red, green, and blue colours?

Yes

I'm not sure if the same gamut also applies to the RGBW strip. Does that show a pinkish colour when setting it to red?

The Lightstrip shows the correct colors in the old and new(beta) Version.
Both the E27 and E14 now work in the beta Version.
I really appreciate your quick help, thank you.


Verify "Largest Series Product" exercise implementation

There was some confusion in this exercise due to the ambiguous use of the term consecutive in the README. This could be taken to mean contiguous, as in consecutive by position, or as in consecutive numerically. The the README has been fixed (https://github.com/exercism/x-common/pull/200).
Please verify that the exercise is implemented in this track correctly (that it finds series of contiguous numbers, not series of numbers that follow each other consecutively).
If it helps, the canonical inputs/outputs for the exercise can be found here:
https://github.com/exercism/x-common/blob/master/largest-series-product.json
If everything is fine, go ahead and just close this issue. If there's something to be done, then please describe the steps needed in order to close the issue.

Quite similar to the xecmascript one. None of the tests included in this track violates rules stated in the README.
But, there are interesting cases in the canonical inputs/outputs that could be added:
[
// ...
    {
        "description": "can get the largest product of a big number (Project Euler)",
        "digits": "7316717653133062491922511967442657474235534919493496983520312774506326239578318016984801869478851843858615607891129494954595017379583319528532088055111254069874715852386305071569329096329522744304355766896648950445244523161731856403098711121722383113622298934233803081353362766142828064444866452387493035890729629049156044077239071381051585930796086670172427121883998797908792274921901699720888093776657273330010533678812202354218097512545405947522435258490771167055601360483958644670632441572215539753697817977846174064955149290862569321978468622482839722413756570560574902614079729686524145351004748216637048440319989000889524345065854122758866688116427171479924442928230863465674813919123162824586178664583591245665294765456828489128831426076900422421902267105562632111110937054421750694165896040807198403850962455444362981230987879927244284909188845801561660979191338754992005240636899125607176060588611646710940507754100225698315520005593572972571636269561882670428252483600823257530420752963450",
        "span": 13,
        "expected":<PHONE_NUMBER>0
    },
    {
        "description": "rejects invalid character in digits",
        "digits": "1234a5",
        "span": 2,
        "expected": -1
    },
    {
        "description": "rejects negative span",
        "digits": "12345",
        "span": -1,
        "expected": -1
    }
]

And, one case that explains the weird (I found it weird the first time I read the specs) spec that returns 1 (the spec already exists, but not the explanation):
{
    "#": [
      "There may be some confusion about whether this should be 1 or error.",
      "The reasoning for it being 1 is this:",
      "There is one 0-character string contained in the empty string.",
      "That's the empty string itself.",
      "The empty product is 1 (the identity for multiplication).",
      "Therefore LSP('', 0) is 1.",
      "It's NOT the case that LSP('', 0) takes max of an empty list.",
      "So there is no error.",
      "Compare against LSP('123', 4):",
      "There are zero 4-character strings in '123'.",
      "So LSP('123', 4) really DOES take the max of an empty list.",
      "So LSP('123', 4) errors and LSP('', 0) does NOT."
    ],
    "description": "reports 1 for empty string and empty product (0 span)",
    "digits": "",
    "span": 0,
    "expected": 1
}

Required changes were included in 9369b3f4a476aa73b85661f9802902333785efae.
I hope this issue can be closed.


.csproj reference

As the universum will be running on .csproj based configuration soon, can we have a specs published and maintained somewhere similar to dreaded/rip project.json specs, please?
https://github.com/aspnet/home/wiki/project.json-file
https://docs.microsoft.com/pl-pl/dotnet/articles/core/tools/project-json
I'll have to tinker about migrating 3rd party code to use .csproj without VS tooling support, so knowing some internals would help.
Thanks!

@natemcmaster wrote a nice post on this very subject: http://www.natemcmaster.com/blog/2017/01/19/project-json-to-csproj/

@moozzyk Thanks! Appreciated!
But one still needs something more definitive as guide for .NET core migration. For example I could read all possible scripts values for project.json just by following still valid specs:
http://json.schemastore.org/project
At least something like:
https://docs.microsoft.com/en-us/nuget/schema/nuget-config-file
NOTE I've found this one, but still it seems to be just too generic:
https://docs.microsoft.com/pl-pl/visualstudio/msbuild/msbuild-project-file-schema-reference
https://docs.microsoft.com/en-us/dotnet/articles/core/preview3/tools/csproj
and later this:
https://msdn.microsoft.com/en-us/library/5dy88c2e.aspx
but I would welcome the draft docs used to create new3 (dotnet/cli) tooling migration output to be released if possible
Thanks!

Our docs team is on it. Closing as a duplicate of the effort tracked here: https://github.com/dotnet/docs/projects/5.

@natemcmaster appreciated!
x-ref: https://github.com/dotnet/docs/issues/1456


Support for arbitrary arguments to commands

It would be nice to be able to allow arbitrary arguments in command sequences. For example for your example Cisco-like CLI...
interface   encapsulation dot1ad  dot1q
The arbitrary elements could be defined by regex. I'm not sure how iShell's classes would manage this.
If you have suggestions for how to do this, I could try to implement it.

if the arbitrary arguments are at the end of the command it's just a matter of getting the full line at your run function and splitting it.


Fetch rockets - Fetch data

Fetch data from the Rockets endpoint (https://api.spacexdata.com/v3/rockets) when the application starts (as Rockets is the default view).
Once the data are fetched, dispatch an action to store the selected data in the Redux store.
Make sure you only dispatch those actions once and do not add data to store on every re-render.

@jerryowusu thanks for the review!


Mbed OS docker image cleanup

Problem
Cleanup Mbed OS docker image. After integration improvement, we use more tools and libraries from Pigweed.
Change overview
Remove Mbed-os sources installing - now it is the third-party library
Remove ARM toolchain installing - we use Pigweed version of it
Improve flashing and debugging script and VScode launch tasks.
Testing
Build and run docker images locally. Build, flash and debug Mbed OS applications.

Guys, can we go forward with this PR? It is a blocker of further upstreaming actions on our side.

@ATmobica Merge conflict?

@ATmobica And if you have any ideas on how to make it clearer that it needs to be there, I would love to hear them!


[WIP] Use private IPs only for CI

Because the test VMs share a private subnet with the Jenkins server, we
do not need to access them using public IP addresses.

This is looking good. What more do you want to do before removing the "WIP" flag?

The --extra-vars is not actually working....

This works now


No mention of Provider children change in release notes

I just upgraded from redux 2.0.0 to 3.0.4 (and upgraded to react 0.14 at the same time) but I did not see any mention of the breaking change for how to use <Provider/> in the release notes. Maybe it's worth adding retroactively? Or is there another migration/upgrade guide that I missed?
I found the answer only by Googling because I didn't understand the error message. For completeness, here are the details:
I got an error (yes it broke my app) like "Failed propType: Invalid prop children supplied to Provider, expected a single ReactElement."
I had to change this:
  <Provider store={dataStore}>
    {() => <App/>}
  </Provider>

to this:
  <Provider store={dataStore}>
    <App/>
  </Provider>

I did the scan the examples in the docs to try and figure out if there was a new way to use Provider but I guess it was such a subtle change that I missed it.

@kumar303 Provider comes from react-redux. It's in the release-notes.

Yep, it's from a different project which is upgraded separately.
https://github.com/rackt/react-redux/releases/tag/v4.0.0

d'oh! Totally knew that. facepalm


Add functionality to open external links in jupyter notebooks in new tab

See https://github.com/alshedivat/al-folio/pull/2230

You know you could just send new commits to that branch and the code in the PR would be updated, right?
LGTM, thanks for the PR.

Now just missing fixing the prettier formatter complaints, and it is good to go.

Hi, thank you for your advice, I will keep that in mind in the future.


disable prod backfill for now

the opt-in-out-urls jobs are filling up the job queue faster that it's being emptied, leading to 300k+ waiting jobs

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Support Data Package Identifiers spec

http://dataprotocols.org/data-package-identifier/
I suppose first is to support all of Identifier String as DataPackage class init values.

DUPLICATE https://github.com/frictionlessdata/datapackage-py/issues/76


Changes that happened during integration with ControlGym

Would need to merge the toolkits first

[ ] Remove predictor specification from optimizer config
[ ] Organize better how dt is specified (control / simulation / saving)


Terms of Use

I was assigned to design the terms of use screen for authenticated users interested in using our streaming platform. Link: https://www.figma.com/proto/tNI2fUodbSyrhaBGbOxiV9/Col-films-designs?node-id=2443%3A15378&scaling=scale-down&page-id=1%3A2

Marked done by @Olamibennie


Need Custodian policy for IAM Password Policy

Need Custodian policy for IAM Password Policy

Hi @rammohanreddy86 - can you provide more details/context?

@ocampocj To verify Password policy configured/not, Below items and as well.
MinimumPasswordLength
AllowUsersToChangePassword
RequireSymbols
RequireUppercaseCharacters
RequireLowercaseCharacters
RequireNumbers
ExpirePasswords
PasswordReusePrevention
MaxPasswordAge
root MFA enabled or not?

see the output / schema thats in the cli builtin help.
$ custodian schema account.filters.password-policy

Help
----

Check an account's password policy.

Note that on top of the default password policy fields, we also add an extra key,
PasswordPolicyConfigured which will be set to true or false to signify if the given
account has attempted to set a policy at all.

:example:

    .. code-block: yaml

        policies:
          - name: password-policy-check
            resource: account
            region: us-east-1
            filters:
              - type: password-policy
                key: MinimumPasswordLength
                value: 10
                op: ge
              - type: password-policy
                key: RequireSymbols
                value: true


#1507. Adding Marathon JSON for launching on minimesos cluster

See related #1507

@errordeveloper mind taking a look at this?  You know mesos better than anyone.

@errordeveloper I moved installation instructions to site/installing.md. Please, take a look

@sadovnikov thank you! I'd tweak the text a bit, @pidster what do you think?

@errordeveloper if it's factually correct, accept it as-is, and ask @abuehrle if she can check the phrasing and adjust as required.


How to contribute button added

Fixes issue #44 i.e. How to contribute button should be added to "Get started" response.
Screenshots for the change:

@madhavrathi @saurabhjn76 @AliAyub007 Please review it. Thank you, guys.


On kale Run Automl's default mirror TRIAL_IMAGE = "gcr.io/arrikto/katib-kfp-trial:a7f7bb79-d9bf99ac"

Hi, I have a question, Kale/common/katibutils default TRIAL_IMAGE = "gcr.io/arrikto/katib-kfp-trial:a7f7bb79-d9bf99ac"
Whether it works in all cases or only in one case. Do we need to change the TRIAL_IMAGE for different scenes when using Kale Run Katib? https://github.com/kubeflow-kale/kale/blob/master/backend/kale/common/katibutils.py
In addition, do we need to change different mirrors or HJ when we are in different scenes。
Thank you very much!

Or is there a dockerfile for it?

What is HJ？


Please upgrade support library to 23

Please upgrade support library to 23, or will have problem like this: 记录一次v4包中SwipeRefreshLayout的“坑爹”事件

@callmepeanut  This may take some time，I need to get back to my computer.


mscv fixes collection

mozilla/sccache#724
mozilla/sccache#753
mozilla/sccache#874
Pending ci for windows tests, we should also obtain a few test projects see https://github.com/paritytech/sccache/issues/16

[ ] verify this actually works

Can we close this since https://github.com/paritytech/sccache/pull/41 is merged?


Lines not show in GLMakie.jl

f = Figure()
ax = Axis(f[1,1])
lines!(cumsum(randn(100)))
scatter!(randn(100), randn(100))
f

The same is true if I activate GLMakie without display.
If I switch to CairoMakie I get this:

julia> versioninfo()
Julia Version 1.7.2
Commit bf53498635 (2022-02-06 15:21 UTC)
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-12.0.1 (ORCJIT, nehalem)
Environment:
  JULIA_PKG_PRECOMPILE_AUTO = 1
  JULIA_EDITOR = code
  JULIA_NUM_THREADS = 8

[e9467ef8] GLMakie v0.6.7
Graphics card: ATI FirePro V3700 (FireGL)

Duplicate of https://github.com/JuliaPlots/Makie.jl/issues/1460

Unfortunately it is a 2012 graphics cards with the latest driver being from 2015. Not sure how much you can do here.

ive got access to 2 machines ,
one of them has an older fireprow2100 which is i believe is pre-vulkan .
This card can be run by two drivers one is the radeon kernel module and the other is the newer amdgpu kernel module ,
the radeon driver seems to be working fine , i haven't tested this device on the amdgpu driver. You might be likewise lucky. ( Then again you would have to use ubuntu 18.04 , i believe 20 and above default to amdgpu) you're mileage will vary .


out of date API page...(and cool project BTW!)

Hi,
First, let me say: awesome project! Supercool what you guys have done and that you released it open source!
I've been trying to set up an RP for an undergraduate experiment I run. Frustrated by the default code (1.7 seconds to pull a 134 us trace!) I was put onto your project by Samuel, and it looks like it's exactly what I need (quick pulling of traces to my notebook, possibly streaming at some point...)
I was just sitting down to start doing some coding, but I ran into some pretty out of date example code on the API page:
https://pyrpl.readthedocs.io/en/latest/api.html
I've documented some of my experiences here:
https://github.com/gsteele13/gary-misc-notebooks/blob/master/Trying PyRPL.ipynb
I'll start digging into the source itself to look for some examples, but I though I would let you know in the meantime.
Cheers,
Gary

Maybe a simple request: I would like to trigger the scope manually and the pull the trace (say even just looking at the input noise).
What is the simplest code I can use for this?
Thanks!
Gary

Always nice to answer your own question :)
This seems to be a working solution:
s.input1 = 'in1'
s.input2 = 'in2'
s.decimation = 1024
s.average = False
s.average = True
s.trigger_source = 'immediately'
s._start_acquisition()
sleep(s.duration)
c1,c2 = s._get_curve()

Although I am being naughty and using internal functions. Maybe there is a more official way?

Hi Gary,
Sorry for not responding earlier, the babysitting + remote working organization needs a bit of fine-tuning at the moment...
Indeed, you are indeed using some internal functions, the proper way would be:
s.input1 = 'in1'
s.input2 = 'in2'
s.decimation = 1024 # or s.duration =0.01
s.average = False
s.average = True
s.trigger_source = 'immediately'
s.single() # the function would not return until acquisition is complete.
#s.single_async() for an asynchronous acquisition (the function returns immediately)
Indeed, I see that the documentation would need a refresh on this.
Also, regarding the source code for data acquisition with instruments, we apologize for the lack of clarity. This is mainly because we have tried to maintain compatibility between python2.7 and python 3. In the branch python3-only, that will eventually become the default master branch at some point, the code is probably more readable. In particular we use the python3 support for asynchronous tasks, which avoids a lot of event-loop-callback nightmares. Let me know if you encounter problems with that branch...
By the way, did at least the acquisition work fine with the Graphical User Interface ?

Thanks, this is great!
I'll check out a copy of the python3-only branch and have a look.
In the meantime, I've had some strange things with the scaling, but try out the above I'll post these in a different issue if I still have problems
I haven't tried the GUI yet as I am building my own application-specific gui inside a Jupyter notebook using Bokeh and iPywidgets. (Now that I've learned to use it, Bokeh is great and can handle immediate streaming updates directly in the notebook!)
(I also have a question about disabling the gui, but I'll also post that as a separate issue)
Cheers,
Gary

Hmmm...I'm not having so much luck with single()
Here is my code:
s.input1 = 'in1'
s.input2 = 'in2'
s.decimation = 1024 # or s.duration =0.01
s.average = False
s.average = True
s.trigger_source = 'immediately'
s.single()

This never returns (need to restart my kernel...)
If I replace s.single() with my earlier code:
s._start_acquisition()
sleep(s.duration)
c1,c2 = s._get_curve()

then this works fine. (aside from scaling issues, which I'll post in the other issue thread...)

This sounds like a problem with the QT event loop.
What branch are you on and what version of python are you using ?
If this is the bug I have in mind, you should also have many problems with the GUI based operation. Can you try to add the scope module in the main window, configure it to immediately and a short curve duration (such that rolling mode is disabled) then click run_continuous. If nothing happens, then this is it.

I'm current running from a pip installation
Indeed, the GUI runs fine with a long duration, but if I go to a short duration and click run_continuous, then the screen is frozen

WOW pip installation is a fearless move... I am really unsure what version is currently on PyPy.
I believe the bug you are having is fixed in more recent versions on github. Probably the master branch would be OK, otherwise, the most up-to-date ones are develop0.9.3 or python3_only.
I strongly advise to use the github version. In principle, you simply need to add the local directory of the repository to your PYTHONPATH environment variable, and I believe it should work out of the box (be careful to properly remove the installation that was in your python distribution to avoid confusion in which code is being executed)
If it is true that the pip version has such a big bug, we will try to quickly create a new release (I hope Leo can help with that because I haven't done that in a long time)

Conclusion here:

prioritize a new release
finally the time is right to drop python 2.7 support

The Qt event loop issues are a nightmare in my opinion. The fact that Gary prefers to use low-level scope readout methods is a symptom of that (I have done the same in the past when trying to operate pyrpl with multiple threads, since Qt forbids to send signals to different threads).
Both the need to require a display for starting even in headless mode, and the need to run the application single-threaded are big arguments against Qt in my opinion. Finally, Qt is becoming more and more commercial (despite apparently being unable to drop open source core libraries due to legal issues) and makes life harder for people like us. In fact, a Qt employee confirmed to me that "Qt is not cool any more" ;). I would not mind to move towards a bokeh GUI in the long term.

@gsteele13 just went through your notebook. Must have been a frustrating experience. Thanks a lot for the feedback. I know pyrpl is in a bad state since I had not time to keep it up to date for a long time now, but didnt know it was that bad to a beginner. I'll make sure to pour 1-2 weeks of time into this asap.

No problem! Took me some poking around but I managed in the end. I find it not any worse that the RP SCPI docs (which are also scant). And the performance is WAY better than the RP SCPI :)
BTW, happy to help in any capacity that I can (right now, I've got a reasonable amount of time with corona, fortunately have my RP in attic :))

Actually this issue seems to appear for all the branches master, develop-0.9.3, and python3-only.
What is more interesting, something blocks result() from being set in the same code section. If one runs a code section like this:
s = r.scope
s.input1 = 'in1'
s.decimation = 1024
s.average = False
s.trigger_source = 'immediately'

res = s.single_async()
sleep (0.3)
print("Curve ready:", s.curve_ready())
res.result()

then result() will not be set:
Curve ready: True
Traceback (most recent call last):

  File "<ipython-input-7-2361bd3d13ed>", line 9, in <module>
    res.result()

InvalidStateError: Result is not set.

However, if after that I run from a console or another section
res.result()

it will succed:
array([[-0.02087402, -0.01904297, -0.02075195, ..., -0.01989746,
        -0.01989746, -0.02026367],
       [-0.01098633, -0.01123047, -0.01196289, ..., -0.01269531,
        -0.01208496, -0.01293945]])

I am having the same problems as aadiyatul and gsteele13. I dowonloaded the pyrpl repository from GitHub and installed it following the instructions on https://pyrpl.readthedocs.io/en/latest/installation.html. Essentially I just want to implement a simple PID Controller, but first i would like to read out the frequency of the Input Signal from the spectrum analyzer. But unfortunately when I call for the curve using the following Code snippet from the API page, the kernel freezes completely and I have to Restart it.
 ch1, ch2, cross_re, cross_im = p.spectrumanalyzer.curve()
This is strange since the spectrum analyzer in the GUI works fine.

I would not mind to move towards a bokeh GUI in the long term

Some useful inspiration code: A scope and spectrum analyzer with Live plotting using Bokeh in a notebook:
https://gitlab.tudelft.nl/gsteele/red-pitaya-control-notebooks
and a video demo :)
Red Pitaya with Live Plotting in Jupyter Notebooks

Same problem here, i would be happy to work on it!

If this is the bug I have in mind, you should also have many problems with the GUI based operation. Can you try to add the scope module in the main window, configure it to immediately and a short curve duration (such that rolling mode is disabled) then click run_continuous. If nothing happens, then this is it.

Any clue were to look at Qt event loop ?


[CI-CD Refactor] Fix onnruntime and deepsparse output validation bug

The input_samples.files and output_samples.files lists, by default, were not in-sync e.g.
input_samples.files -> ['inp-004.npz', 'inp-016.npz', 'inp-006.npz' ...]
output_samples.files -> ['out-003npz', 'out-006.npz', 'out-007.npz' ...]
This was leading to errors when iterating over zip(input_samples, output_samples) due to unmatching expected outputs and actual outputs. Sorting the numpy files solves the problem.
Also, the big feature of this PR is to refactor the code so that InferenceRunner is a stand-alone class and not a functionality buried within ModelDirectory

@bfineran yeah, with the new class for validations, I am already a bit more lightweight on the model_directory.py, but moving the runner to a separate file is tempting. will do.


Ability to use a defined Column as a DiscriminatorColumn

The purpose of this feature is to be able to access the DiscriminatorColumn and define it with the flexibility of Column.
Example:

<?php
/**
 * @Entity
 * @InheritanceType("SINGLE_TABLE")
 * @DiscriminatorColumn(name="section_id")
 * @DiscriminatorMap({
 *  "1" = "Entities\Article\Science",
 *  "2" = "Entities\Article\News"
 *  })
 */
class Article {
  /**
   * @ManyToOne(targetEntity="Entities\Section")
   */
  private $section;
}

Discriminator columns are an internal Doctrine feature and they are not meant to be exposed to developers.
If you want a similar feature, create your own column and always set it on constructor.
Sorry, but such a change is never going to happen in Doctrine! =\


Fix CI build due to cudatoolkit not being defined

Checklist before submitting

[x] Did you read the contributor guide?
[ ] Did you update any affected documentation?
[ ] Did you write any tests to validate this change?

Description
To fix workflow builds of cuda only packages like TRT, nccl, magma, cudnn, etc. which errors out as below -
--->git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'
239
Error: Failed to render jinja template in /home/runner/work/magma-feedstock/magma-feedstock/recipe/meta.yaml:
240
--->git checkout main
241
'cudatoolkit' is undefined

we need to add {% if build_type == "cuda" %} in the config/build-config.yaml files of the feedstocks. And then for this condition to work, we need the changes done in the PR.
Review process to land

All tests and other checks must succeed.
At least one maintainer must review and approve.
If any  maintainer requests changes, they must be addressed.

Codecov Report

Merging #64 (4fafcf2) into main (e08302e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #64   +/-   ##
=======================================
  Coverage   96.70%   96.70%
=======================================
  Files          23       23
  Lines        1971     1971
=======================================
  Hits         1906     1906
  Misses         65       65

Flag
Coverage Δ

unittests
96.70% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out 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 e08302e...4fafcf2. Read the comment docs.


Non-semantic variable naming

Since --owhite can be either white or black and --black can be either black or white, the variables should be named to reflect their position in the design context instead of their light-mode colour.
So --owhite, which is a background colour, might be named --primaryBackground or something along those lines.

Hey @metaloha, good idea! I am currently working on it!


MODCLUSTER-483 Remove zone id completely from CONFIG command

Jira
https://issues.jboss.org/browse/JBEAP-1767

Triggering build using a merge of b7fc16a71570ba7204ee72d92c95708a13d0f7f8 on branch master:
Private: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mod_cluster-1.3.x-pull-player-executor/

Build 165 outcome was SUCCESS using a merge of b7fc16a71570ba7204ee72d92c95708a13d0f7f8 on branch master:
Private: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mod_cluster-1.3.x-pull-player-executor/165
Public: https://hudson.jboss.org/hudson/job/mod_cluster-1.3.x-pull-player-executor/165


NJsonSchema generates discriminator syntax which is not AsyncAPI compatible

According to the spec, AsyncAPI should have a discriminator as a string,
https://www.asyncapi.com/docs/specifications/v2.1.0#schemaObject
However, NJsonSchema generates an object instead with a propertyName and mappings fields, which is valid according to the OpenAPI spec
https://github.com/RicoSuter/NJsonSchema/blob/288eb13e931562264ed9ddd12a83741c67a1ddc4/src/NJsonSchema/OpenApiDiscriminator.cs
https://swagger.io/specification/#discriminator-object
This means that Saunter generates invalid AsyncAPI code.
If you call iPetSchema.ToJson() one line 145 in the following file, you'll see the generated JSON and how it doesn't match the requirements:
https://github.com/tehmantra/saunter/blob/main/test/Saunter.Tests/Generation/SchemaGeneration/SchemaGenerationTests.cs
I've reverted to 0.4.0 for now as it's the last version of Saunter with working discriminator support.
I can't see an obvious way to adjust the generated schema in NJsonSchema, maybe this is something @RicoSuter can help with?
Let me know if there's any more information I can provide.

More frustrations with the different schema formats 😞
There is quite a lengthy discussion in #103 about the correct way to represent nulls, and now we have more issues with the discriminator...
@RicoSuter it seems like we might need to have a specific format for AsyncAPI
I know we have the SchemaType enum, but it seems like this would have to be added directly into NJsonSchema. Is there a way we can support a custom serialization output without having to build it directly into NJsonSchema?
Thanks for your help.

Yeah, I noticed the null issues too, where the generated schema has a lot of null values with the AsyncAPI UI doesn't like.
Maybe the best solution to this is to create a fork of NJsonSchema specifically for AsyncAPI? That is unless @RicoSuter thinks these customisations should be in NJsonSchema itself. That way you can take advantage of development in that project and curate how that merges into the AsyncApi variant?
Either that or NJsonSchema's serialiser would need to be completely customisable (if it isn't already, my knowledge is limited here.)
I think this project (Saunter) has huge potential, I'm a big fan of Swashbuckle and an AsyncAPI equivalent is something which I think is hugely valuable.
Let's see what Rico says I guess.

Can someone clarify what the correct null handling should be?
Is it the same as with OpenAPI or JSON Schema or again completely different?
I'm fine adding the AsyncAPI enum, had to do this for OpenAPI/Swagger as well because it's not just a simple rename of a property but the schema generator needs to generate "completely different" schemas...

Thanks for replying @RicoSuter :)
In this case the issue is how to support polymorphism.

AsyncAPI uses a field called discriminator - https://www.asyncapi.com/docs/specifications/v2.2.0#schemaObject
OpenAPI uses a discriminator object - https://swagger.io/specification/#discriminator-object
Json Schema has nothing

For representing nullables.
As of today AsyncAPI is JsonSchema-draft-07 compatible, which means we need to do:
For simple/primitive properties:
properties:
  foo:
    type: [string, 'null']

For references to other schema:
properties:
  foo:
    oneOf:
    - type: 'null'
    - '$ref': '#/components/schemas/foo'

Once AysncAPI supports later versions of JsonSchema, we can use $ref and type together.
https://github.com/asyncapi/spec/issues/596
properties:
  foo:
    type: [ object, 'null' ]
    '$ref': '#/components/schemas/foo'

It seems like the discriminator issue alone is enough to force us to implement a different SchemaType in NJsonSchema?

It seems like the discriminator issue alone is enough to force us to implement a different SchemaType in NJsonSchema?

So we would add AsyncApi2 (and later AsyncApi3) or just AsyncApi as new SchemaType?

That seems like the most appropriate option :)
Given we currently have values like SchemaType.OpenApi3 and SchemaType.Swagger2, it wouldn't be crazy to have SchemaType.AsyncApi2.
Alternative might be to have NJsonSchema allow custom SchemaTypes somehow?
But I'd be fine with just adding SchemaType.AsyncApi2.
Would you like me to work on this and submit a PR to NJsonSchema?

Alternative might be to have NJsonSchema allow custom SchemaTypes somehow?

problem is that njs needs specific code based on the schema anyway, no? Here for example a different inheritance generation.. another option is that you inherit from JsonSchemaGenerator and tweak the behavior with overrides.. that would be nicer in general (ie get rid of the schematype)


Very bad perfomance when using LWJGL3 on Mac OS X

Issue details
When running my app with LWJGL3 on OS X, as opposed to LWJGL2, I am getting very bad performance. The app makes heavy use of scene2d.ui. When running the app on Android the performance is quite good, and running the desktop version with LWJGL3 on a Raspberry Pi 4 also runs very well.
So when running on LWJGL2 on the mac I am getting a steady 60fps, and when on LWJGL3 it is more like 20. It is run with -XstartOnFirstThread and -Djava.awt.headless=true.
The Mac is a 2014 MacBook Pro running Big Sur. Had this issue also on Catalina.
Could this have something to do with PR #6673?
The app in question is Sputter Music Sequencer for Android. If anyone wants to check it out for whatever reason, let me know and I can give you a promotion code to download it for free.
Reproduction steps/code
I have not been able to find exact steps to reproduce it. For the default project generated by gdx-setup I am not able to measure any difference between LWJGL3 and LWJGL2 on my MacBook Pro.
Version of libGDX and/or relevant dependencies
1.10.0
Please select the affected platforms

[ ] Android
[ ] iOS
[ ] HTML/GWT
[ ] Windows
[ ] Linux
[x] macOS

OK, so this is an Android app and you're trying a desktop (MacOS) version for debug, I'm guessing? Well, first, what we know it isn't:

#6673 hasn't been merged, so it won't affect your application.
We know this isn't an M1-related MacOS issue, so that possibility can be ruled out.
There have been intermittent reports of total crashing failures with LWJGL2 on recent MacOS versions, typically Catalina -- all of the logs contain this:

# Problematic frame:
# C  [AppKit+0x3e5abc]  -[NSOpenGLContext setView:]+0xe5

It's something to note that you're able to run with LWJGL2 at full speed on Catalina; this doesn't help resolve this bug, but it may for other people's bugs.
The default project probably doesn't have enough happening in it to lower FPS below the monitor refresh rate of 60FPS. You might want to just loop n times and create a large grid of n small buttons, to see about at what n performance starts to dip. If a tightly packed grid of buttons doesn't dip FPS, it probably isn't scene2d.ui related (still might be...). I'd try profiling with VisualVM, which is free, to see where the most time is being spent. The majority of the time in most games and applications (that aren't already very close to going below 60 FPS) should be in render() or methods called by render(). Multithreaded usage may change what to expect from profiling. The main thing to look for, I think, would be if a particular method (especially part of LWJGL) is taking a substantially larger percentage of time when the only factor that changes is LWJGL2 vs. LWJGL3. I wouldn't be surprised if there's some uncommon issue with framerate being limited more than once, but this hasn't been reported by anyone else, to my knowledge.
To make sure this isn't caused by the frame limit, you can change the settings in your Lwjgl3Launcher (or DesktopLauncher, if you didn't use gdx-liftoff to generate the project):
                // Try with both true and false.
		configuration.useVsync(true);
                // Try with 0 (unlimited), the refresh rate and maybe also twice the refresh rate. Maybe half as well.
		configuration.setForegroundFPS(Lwjgl3ApplicationConfiguration.getDisplayMode().refreshRate);
                // Be careful with your computer's temperature if you have VSync set to false and FPS is high.

If VSync is on, the FPS should be no higher than the monitor's refresh rate. If it is off, the only limit is what is set on the next line, with setForegroundFPS(). You can try absolute numbers or multiples of the refresh rate, depending on what you know about your monitor's settings. If setting VSync to false (without the second line) lets the LWJGL3 app run at a higher speed, that narrows down the possibilities a lot. The same is true if VSync is false and foreground FPS is 0 or very high.
I don't have a Mac, so there's very little I can do to reproduce this. I think a few members of the team use Macs regularly, or can access one from about the same era as yours. Without seeing any code, there's not a ton we can do... That's why I gave all these options so you can try to track it down on your side.

Are you using 3d and ModelBatch? If so, check if #5893 is the culprit.

Thanks  @tommyettinger for your quite elaborate answer and also to you @PokeMMO for your suggestion.
I tried VisualVM. Thanks for the suggestion, it seems like it can be a very useful tool. However, when I run my app and try to click on it in Visual VM nothing happens. Occasionally I could get the usual screens to show up, but everything seemed frozen and unresponsive. This was both when using LWJGL3 and 2. I got it to work with the default gdx-setup project, so I am not sure what is going on.
I also tried your exact vsync and fps configurations, they had no effect.
Probably I will have to live with this issue for now. Actually the goal is to have the app running on a Raspberry Pi, while developing it on a Mac. So if it works well on the RPi that will have to suffice for now.
I'd be happy to try any other suggestions. @PokeMMO Is there anything specific I could try in the issue you pointed to? I am not not sure if I am using ModelBatch. At least not on purpose... But it could be that Scene2D.ui does?

I am not not sure if I am using ModelBatch. At least not on purpose... But it could be that Scene2D.ui does?

ModelBatch renders 3D models, so you're pretty much certainly not using it unless you specifically have 3D models in your project assets.

However, when I run my app and try to click on it in Visual VM nothing happens. Occasionally I could get the usual screens to show up, but everything seemed frozen and unresponsive. This was both when using LWJGL3 and 2. I got it to work with the default gdx-setup project, so I am not sure what is going on.

Now this seems strange. Is it your game that is freezing, or VisualVM? I use the Startup Profiler extension (which can be installed from inside VisualVM, Tools -> Plugins -> Available Plugins) so I can delay the game's startup until profiling is running. With that, I had startup issues that got resolved by following some of VisualVM's suggestions (I had to use the current agent option, and make sure the JVM I was using had been calibrated before running). I think you must have calibrated already, but if you haven't, calibration is sort of a hidden option: Tools -> Options -> Profiling -> Manage (at the bottom). If you got it working with gdx-setup, there might be something different about your application that makes VisualVM have problems...
This is definitely an uncommon problem; we don't have a lot of people targeting the RPi, but it does work there using LWJGL3 from what I understand. You have to use LWJGL3 to target the RPi, but in most cases it's fine to have both an LWJGL2 and LWJGL3 module that function essentially the same. As long as all changes are in core, or less commonly, duplicated in LWJGL2 and LWJGL3, you could develop with LWJGL2 on your Mac and run with LWJGL3 on your RPi. This was an anticipated use case for having LWJGL2 and LWJGL3 both allowed in the same project in gdx-liftoff. Note that gdx-setup has never supported having both LWJGL2 and LWJGL3 projects, though you can modify one of its projects quite a lot to get it to do that.

Note that gdx-setup has never supported having both LWJGL2 and LWJGL3 projects

This isn't strictly true. If you run it from the command line, desktop and legacy_desktop modules will both be created, unless you --excludeModules one of them of course. I could add support for this to the GUI if there's interest, but personally I'm hoping LWJGL2 completely dies out.

personally I'm hoping LWJGL2 completely dies out.
For that to happen, we'd need to resolve this mysterious slowdown issue. Thank you for volunteering, your sacrifice shall not be in vain.

Alright! Seems like I have found something. I installed the Startup Profiler as you @tommyettinger suggested, and now I can get it to work. Using it, I tracked the issue down to Gdx.graphics.getDensity() which was called every frame. This has been done to calculate correct sizes etc with regards to different screen densities. When I instead just return 1, the application runs 100% fine as expected on my 2014 Macbook Pro.
I do not know if Gdx.graphics.getDensity() is expected to run fast enough that it can be called on each frame. There is appearently some stuff going on in Lwjgl3Graphics.getPpcX(), and I guess some of that stuff is ultimately calling OS functions.
Let me know if there is something more I can test/do to debug this issue.
Just to be clear: It has been running fine using LWJGL3 on the RPi4 all along, and still does. Even with the Gdx.graphics.getDensity() call.

I'm not totally sure this is something those projects would call a bug, since in (almost?) all cases you don't need to call getDensity() every frame. It seems like you have a solution that works on your hardware, and definitely works on the RPi target hardware, but maybe the solution here would just be to update the documentation and say that getDensity() should be stored, rather than called every frame.

That seems reasonable. The underlying code for determining screen density will likely be platform dependent in any case, and there is no way to be certain of the cost of it. At least I will update my code to not call it on every frame.
As far as having two screen with different densities I actually have that here, Retina screen on the MacBook and an extra screen on the side which is probably 160dpi. Not sure how to properly tackle that. It seems like "normal" apps adjusts to it when I move them from one screen to another. For now it will work 100% well enough, but I'll try to deal with it some day and will report back then.
Also I wanna thank you again for pointing me to and helping me out with VisualVM. I have been looking for a good open source profiler to use on desktop. Gold!

I tried with and without running Gdx.graphics.getDensity() on each fram on a RPi 4. Without it running I get a steady 60fps, and when running it on each frame it drops to about 30. I have not noticed any issues like this on Android, but it could be that determining the DPI on the screen of a phone is a known constant, while on desktop machines some costly calculation has to be run. At least it does seem so.
In any case, as you @tommyettinger suggest it would make sense to update the documentation to warn about this. I have proposed such an update in the PR.
Thanks again for all your help!


fixed a few more spelling errors

@jmp1617 Also, could you change the commit message (when you push the change Liam suggested and rebase) to be more specific on what you're changing? I.e. Fixed a few more spelling errors in Deepnet post.


Implement ast_builder for bitwise_not operator

Implement ast_builder for bitwise_not operator

resolved in https://github.com/gluesql/gluesql/pull/1321

@panarch Hi, this issue is not completed yet.
I didn't start.
Could you please open this ticket again?

Oh thanks! I thought that #1321 is a related issue but it was not

https://github.com/gluesql/gluesql/pull/1366


fix: enable pressing enter on action elements in Firefox

Previously it was not possible in Firefox for an action element with an internal anchor element (e.g. <sbb-button href="..."> to be able to "click" it with an Enter press. This PR fixes this by switching from a PointerEvent to a MouseEvent.

Codecov Report

Merging #1807 (bbc3f81) into master (ab917b0) will decrease coverage by 15.94%.
The diff coverage is 34.52%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@             Coverage Diff             @@
##           master    #1807       +/-   ##
===========================================
- Coverage   54.85%   38.91%   -15.94%
===========================================
  Files          49      251      +202
  Lines        1659     9191     +7532
  Branches      406     1927     +1521
===========================================
+ Hits          910     3577     +2667
- Misses        671     5369     +4698
- Partials       78      245      +167

Impacted Files
Coverage Δ

...ts/sbb-accordion-item/sbb-accordion-item.events.ts
100.00% <ø> (ø)

.../sbb-accordion-item/sbb-accordion-item.stories.tsx
0.00% <0.00%> (ø)

...mponents/sbb-accordion-item/sbb-accordion-item.tsx
0.00% <0.00%> (-37.21%)
:arrow_down:

...components/sbb-accordion/sbb-accordion.stories.tsx
0.00% <0.00%> (ø)

...ents/sbb-action-group/sbb-action-group.stories.tsx
0.00% <0.00%> (ø)

...onents/sbb-alert-group/sbb-alert-group.stories.tsx
0.00% <0.00%> (ø)

src/components/sbb-alert/sbb-alert.stories.tsx
0.00% <0.00%> (ø)

...onents/sbb-autocomplete/sbb-autocomplete.events.ts
100.00% <ø> (ø)

...ents/sbb-autocomplete/sbb-autocomplete.stories.tsx
0.00% <0.00%> (ø)

src/components/sbb-button/sbb-button.stories.tsx
0.00% <0.00%> (ø)

... and 58 more

... and 195 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


adding methods to convert a model to a dict

this is partially in response to #56 and #48

I'm personally not sure we should merge this one until we have resolved the conversation on #56 as this PR implements a partial solution to the requirements there. I'm open to the opinions of others though.

Agree, closing this. Opening another PR with fuller solution.


Reuse the File, Config field, and file-related validators from flask-marshmallow

This pr is for #540 .

I don't know what the file min-versions.in does. But if I pin flask-marshmallow to 1.0.0 version, I get an error.
ERROR! requirements/min-versions.txt was not regenerated after changes in requirements/min-versions.in.
Expecting: # SHA1:3725672cc8aa4cdcab4174d189f19e8bb3ac2b62
Found:     # SHA1:a74d3671a740ec5c076a37aaaa3409fd78f9bde2

I don't know what the file min-versions.in does. But if I pin flask-marshmallow to 1.0.0 version, I get an error.
ERROR! requirements/min-versions.txt was not regenerated after changes in requirements/min-versions.in.
Expecting: # SHA1:3725672cc8aa4cdcab4174d189f19e8bb3ac2b62
Found:     # SHA1:a74d3671a740ec5c076a37aaaa3409fd78f9bde2

The min-versions.in file (input) contains the minimal supported version of the dependencies. You could update the version in it, then use pip-compile-multi or pip-compile requirements/min-versions.in command to generate the min-versions.txt file (output, lock file).
Ref:

https://github.com/jazzband/pip-tools
https://github.com/peterdemin/pip-compile-multi

Thanks!


Builds fail in github actions

Description
Hi!
Github actions can't run builds

First time it appeared last week
https://github.com/Interswap-labs/front-monorepo/actions/runs/5893838964/job/15986235736
When I pressed re-run job → it succeeded
Later I faced it again
https://github.com/Interswap-labs/front-monorepo/actions/runs/5901875515/attempts/1
And re-run helped
But since Monday we didn't get anyone successful builds, even trying to re-run a lot of them.
https://github.com/Interswap-labs/front-monorepo/actions

But at that time, everything still works fine on our deveolper's laptops and on AWS also. Therefore I think that the problem is on your side.
Also in new PR's there were not any system stuff, just small code improvements.
I also tried to upgrade rollup to the highest minor version, but still failed.
I wrote a ticket to support, they analyzed and answered the following:
I took a look at the workflow runs in the repository and I noticed that between the last successful run and the failing run, the runner image version was updated from 20230806.1.0 to 20230814.1.0
See below:
Last successful run: https://github.com/Interswap-labs/front-monorepo/actions/runs/5901875515/job/16008922035#step:1:9
Failing run: https://github.com/Interswap-labs/front-monorepo/actions/runs/5925369940/job/16065721502#step:1:9
Virtual environment updates can sometimes cause problems for previous setups.
Platforms affected

[ ] Azure DevOps
[X] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[X] Ubuntu 22.04
[ ] macOS 11
[ ] macOS 12
[ ] macOS 13
[ ] Windows Server 2019
[ ] Windows Server 2022

Image version and build link
20230814.1.0
Is it regression?
20230806.1.0 - https://github.com/Interswap-labs/front-monorepo/actions/runs/5901875515/job/16008922035#step:1:9
Expected behavior
builds are passed
Actual behavior
builds fail
Repro steps
Re-run these jobs:
https://github.com/Interswap-labs/front-monorepo/actions/runs/5942142397/job/16145057245
https://github.com/Interswap-labs/front-monorepo/actions/runs/5952708386/job/16145262763

@dmitry-shibanov @MaksimZhukov looks image-neutral and node-specific... Could you take a look please? We will assist if needed

Hello @Opty1712! Thank you for reporting this!
We will investigate the issue

Unfortunately, we can't see the build logs. Could you please provide us with the link to the public repository or describe steps to reproduce the issue ?

@MaksimZhukov I granted access for you, please accept the invite

Hey guys, it seems I found the problem - node version.
Rollup fails on 18 and later, but works fine on 16.14
https://github.com/Interswap-labs/front-monorepo/actions/runs/6023993703/job/16341823401?pr=468


How to retrieve Favorite and Last Added playlists with songs?

subj

This used to be part of the docs, but it looks like I removed it along with the webclient method. I'll add it back.
These playlists are calculated clientside, so gmusicapi can't retrieve them for you. See https://github.com/simon-weber/gmusicapi/issues/346#issuecomment-111154306 for more details.

As I see there is no way way to get all AA songs with thumb up which not added to library, right?

Right. https://github.com/simon-weber/gmusicapi/issues/182 tracks that issue.


How to capture screenshot of JotView ? currently black screen appears in screenshot

Hello,
I want to capture screenshot of JotView. I have added JotView’s instance in another UIView and I want to capture screenshot but I get black screen. I have used below code.
My app is in landscape mode
UIGraphicsBeginImageContextWithOptions(view.bounds.size, view.opaque, 0.0);
[viewMain.layer renderInContext:UIGraphicsGetCurrentContext()];//JotView is subview inside viewMain
UIImage * img = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

Then I tried your below code for saving as UIImage, but it capture only half screen(not even half) and again my app is in landscape mode
[jotView exportImageTo:[self jotViewStateInkPath] andThumbnailTo:[self jotViewStateThumbPath] andStateTo:[self jotViewStatePlistPath] withThumbnailScale:1.0 onComplete:^(UIImage* ink, UIImage* thumb, JotViewImmutableState* state) {
    UIImageWriteToSavedPhotosAlbum(thumb, nil, nil, nil);
}];

Any idea how to capture screenshot of JotView ?
Thanks

Is the JotView full screen? or only part of the screen? the exportImageTo: method will export the entire JotView but won't export any surrounding views or subviews.

I am drawing everything in JotView and it covers 90% of the screen, but When i export image, then only half screen appears in screenshot. Please take note that my app is in landscape mode. half screen of JotView is cut in screenshot

I am trying to debug below function which is in JotView.m file

(void)exportToImageOnComplete:(void (^)(UIImage*))exportFinishBlock withScale:(CGFloat)outputScale

I think that function is taking screenshot of jotview, but I am not getting success

I also tried in your example my changing orientation of app from portrait to landscape but In your example it is not working.
In your example just change orientation from portrait to landscape and run your example and then draw line in whole screen and then save. you will notice that right side part is not coming in screenshot

Hello,
I solved the problem :)
I changed in #import "UIScreen+PortraitBounds.h" file
But I am getting another problem and I am posting another issue :)
Thanks

glad you got the other saving issue working! I'd be interested to see what you changed in UIScreen+PortraitBounds.h - if you submit a pull request that'd be awesome :)

Sure. What I did is just comment below code in PortraitBounds.m file
//    if (b.size.width > b.size.height) {
//        CGFloat t = b.size.height;
//        b.size.height = b.size.width;
//        b.size.width = t;
//    }
and it solved my problem :)


unicharset_extractor segfault

Current Behavior
After I built from the current main with debug symbols (configure --disable-openmp --enable-debug --disable-shared CXXFLAGS="-g -O0 -fsanitize=address,undefined -fstack-protector-strong -ftrapv"), trying to use tesstrain immediately segfaults on the unicharset_extractor step (all-gt is 313k, norm_mode=2, nothing unusual):
    #0 0x7faa6352b17e in std::filesystem::__cxx11::path::compare(std::filesystem::__cxx11::path const&) const (/lib/x86_64-linux-gnu/libstdc++.so.6+0x19017e)
    #1 0x562c491ddc50 in std::filesystem::__cxx11::operator==(std::filesystem::__cxx11::path const&, std::filesystem::__cxx11::path const&) (/data/ocr-d/ocrd_all/venv38/bin/unicharset_extractor+0x2556c50)
    #2 0x562c491dc60d in Main /data/ocr-d/ocrd_all/tesseract/src/training/unicharset_extractor.cpp:74
    #3 0x562c491dd09d in main /data/ocr-d/ocrd_all/tesseract/src/training/unicharset_extractor.cpp:120
    #4 0x7faa625df6c9  (/lib/x86_64-linux-gnu/libc.so.6+0x276c9)
    #5 0x7faa625df784 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x27784)
    #6 0x562c491db8c0 in _start (/data/ocr-d/ocrd_all/venv38/bin/unicharset_extractor+0x25548c0)

I compiled with g++ 8.3.0.
Judging by the stack trace, there is some non-interopability with the C++ path library here...
Expected Behavior
The unicharset_extractor to exit normally, producing output.
Suggested Fix
No response
tesseract -v
tesseract 5.3.4
 leptonica-1.76.0
  libgif 5.1.4 : libjpeg 6b (libjpeg-turbo 1.5.2) : libpng 1.6.36 : libtiff 4.1.0 : zlib 1.2.11 : libwebp 0.6.1 : libopenjp2 2.3.0
 Found AVX512BW
 Found AVX512F
 Found AVX512VNNI
 Found AVX2
 Found AVX
 Found FMA
 Found SSE4.1
 Found libarchive 3.3.3 zlib/1.2.11 liblzma/5.2.4 bz2lib/1.0.6 liblz4/1.8.3 libzstd/1.3.8
 Found libcurl/7.64.0 NSS/3.42.1 zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.11.0 nghttp2/1.59.0 librtmp/2.3

Operating System
Debian 11 Bullseye
Other Operating System
No response
uname -a
GNU/Linux x86_64
Compiler
g++ 8.3.0
CPU
Intel Xeon Gold
Virtualization / Containers
VMWare
Other Information
No response

Does the crash depend on the input data? I tried a build with g++ 12.2.0 and your configuration. Running unicharset_extractor --output_unicharset /tmp/unicode --norm_mode 2 all-gt works fine, no crash occurred.
Maybe older versions of g++ are simply broken with regard to sanitizers?

No – I just tried with all my previous trainings (without touching the existing files), it happens everywhere.
I also rebuilt completely – to no avail.
Will try with clang, and with an older version of Tesseract...

According to the libstdc++ manual, for GCC
8.x -lstdc++fs is needed if <filesystem> is included in the code.

Wow, same happens with clang++ 11.0.1-2~deb10u1!

-lstdc++fs is needed

that's what I initially suspected here

For gcc and configure I think you need to add:
LIBS="$(LIBS) -lstdc++fs"
Not sure if that is all you need to add.

-lstdc++fs is needed

that's what I initially suspected here

Wow, I did manage to fix this by recompiling with -lstdc++fs!!

For gcc and configure I think you need to add:
LIBS="$(LIBS) -lstdc++fs"

I used LDFLAGS=-lstdc++fs make ... (because I noticed that this variable is not used otherwise). Not sure where to put it correctly.
But mind that clang++ behaves just the same.

Wow, same happens with clang++ 11.0.1-2~deb10u1!
But mind that clang++ behaves just the same.

Wait, looking more closely, it seems that passing CXX=clang++-11 (as instructed by the git compilation guide) was not enough to effect that compiler be used. Will investigate...

Did you installed clang and libc++?
Also read my comment about clang: https://github.com/tesseract-ocr/tesseract/issues/4200#issuecomment-1981295304

Did you installed clang and libc++?
Also read my comment about clang: #4200 (comment)

I used the recipe from tessdoc, i.e. passing CXX=clang++  to configure, which has autoconf check whether it supports -std=c++17 or -std=c++20 – the latter being true, that's what gets passed to each compiler/linker call.
Anyway, so just to confirm: I just recompiled with clang++-11 again, and the segfault is back.
I then applied the same trick (make unicharset_extractor LDFLAGS=-lstdc++fs -W src/training/unicharset_extractor.cpp to force recompilation) and voila the segfault is gone.
To sum up: both clang++ and g++ do need -lstdc++fs.

Not sure where to put it correctly.

So basically we could either put it in the respective targets' rules in Makefile.am, like for example checkmk does, or in LDFLAGS in configure.ac, like Libreoffice online does or Mega does.
But since this seems to be the only place in the whole source where std::filesystem::path is used, mabe we should only declare that locally in Makefile.am's unicharset_extractor_LDADD, right?

On the other hand, I wonder why that library gets used at all. Wouldn't tesseract::ReadFile be the best fit actually (and so no extra library would be needed)?
Ha! That's indeed what it used to be...

@zdenop since this originates with you, could you please comment?

Your system has libstdc++ 8. This version does not have the filesystem header in it. This header is included in another external library. This is why you need the addition linker flag.
On Linux, Clang by default will use GNU libstdc++. In your case, it will use libstdc++ 8 which does not have the filesystem header...
In both cases, the soure of the problem is not the compiler but the standard C++ (17) library which is not part of the compiler.
As I mentioned, there is a way to tell clang to use llvm's libc++ instead of gnu libstdc++.

As I mentioned, there is a way to tell clang to use llvm's libc++ instead of gnu libstdc++.

ok, but how does that work?
configure --disable-openmp --disable-shared CXX=clang++-11 LDFLAGS="-stdlib=libc++" CXXFLAGS="-g -O2 -fPIC"

checking whether the C++ compiler works... no
configure: error: in `/data/ocr-d/ocrd_all/venv38/build/tesseract':
configure: error: C++ compiler cannot create executables

also, are you saying I must switch to clang because my libstdc++ is too old?
if that's correct, shouldn't Tesseract build be a little more tolerant/versatile?

also, are you saying I must switch to clang because my libstdc++ is too old?

I'm just saying: Don't blame clang for an issue in old libstdc++ which does not have the filesystem header in it.
Even if we fix the code / the documentation now, we can't keep support for old compilers versions forever. We want to move forward. Fpr comparison, latest PyTorch requires GCC 9 pr a newer version. It seems TF also need GCC 9+.

BTW, PyTorch is planing to drop support for pre-m1 Macs (Intel Macs) soon. And Microsoft will drop support for its own MSVC 2019 in the next version of Onnx-Runtime.
Moving forward...

I'm just saying: Don't blame clang for an issue in old libstdc++ which does not have the filesystem header in it.

Understood.

Even if we fix the code / the documentation now, we can't keep support for old compilers versions forever.

The problem was just introduced recently. It's the only place where that library gets used so far. Even if kept, it can be fixed easily, as I have shown. It's just a matter of 1-2 lines of configuration.
Also, Tesseract is not Pytorch, or ONNX  – it's neither an ML framework nor state of the art. In fact, it's a legacy codebase, but very stable and reusable. That's why it still gets used and integrated so much. So there's a special responsibility not to arbitrarily break things here.

@bertsky : As far as  remember std::filesystem::path was most easier multiplatform way how to handle file extension, so I just use it.  Decision to use c++17 instead of c++14 was done 5 years ago and it is required for 3 years. But in code we still try to avoid it. Why?
According GA non of supported major platform and compiler has problem with it.

@zdenop

As far as remember std::filesystem::path was most easier multiplatform way how to handle file extension, so I just use it.

Understood. So how about the proposed fixes (configure.ac or Makefile.am)?

Decision to use c++17 instead of c++14 was done 5 years ago and it is required for 3 years. But in code we still try to avoid it. Why?

I wouldn't know.

According GA non of supported major platform and compiler has problem with it.

None of the GHA workflows test this, hence they don't detect the segfault.

@bertsky, is there a good reason why a rather old compiler like g++ 8.3.0 with the related libstdc++ and sanitizer flags should be supported? If not, then this issue should be closed.

@stweil yes, there is a good reason – see above.
Also, the install instructions say "you need a C++17 compiler", not "you need a C++17 compiler, but not that one, and not that certain version of its libstdc++".
BTW, how do you know only g++ 8.3.0 and its libstd++ are affected?

@stweil yes, there is a good reason – see above.

I don't see a good reason for using g++ 8.3.0 with sanitizer flags in your comments above. Which supported Linux distribution uses that compiler version?

To sum up: both clang++ and g++ do need -lstdc++fs.

That was not needed in my test with g++ 12.2.0.

@stweil

I don't see a good reason for using g++ 8.3.0 with sanitizer flags in your comments above.

Perhaps you overlooked it.

don't break things lightly (there is practically no cost for fixing this)
you don't even know what other versions are affected, since unicharset_extractor is not covered by any tests

Sorry, "it works for me" is not an answer I can accept. Why do you support multiple platforms in the first place?

Robert, please answer my questions. Which supported Linux distribution uses a compiler version which does not work? Without that information reproduction of the segfault is unnecessarily difficult, and then I'd suggest to close this issue.

The Linux distros that have GCC 8.x as their default compiler:

Debian 10 'buster' (oldoldstable). Note that the Debian project does not support buster anymore. A third party organization provides extended security support for buster.
RHEL 8 (and its clones). GCC 13 is also available (gcc-toolset in AppStream).

Personally, I don't think we should care about GCC 8 anymore.

https://github.com/tesseract-ocr/tesseract/blob/main/README.md#installing-tesseract


Fdfu implementation for the console in Rust

Not ready to merge
I wanted to go ahead and open this because I'm at the point where I'm going to need some debugging help. I think I've got things set up pretty nicely as far as utility methods go (pretty much everything in struct SamBa), but I'm not quite sure how to go about testing things with the actual device.
The main logic is in SamBa::upload, and the command to run to flash a file is cargo run -- flash <filename>.
So if I execute this while attached to fvm, in enter_update_mode I receive an ack with 000. This kind of makes sense, because the uart_pull implementation is probably some sort of no-op. But when I attach it to the actual device I get the same thing. So I'm not sure whether this is a uart binding problem, or a procedure problem, or what. I'm not sure how to know what to expect when pulling from uart. If you could take a look at this and try some stuff out and let me know your thoughts, that'd be very helpful.

Before we merge this I'd like for you to verify that it works on your machine. Let me know if there are any changes needed before we merge.


AppAccess doesn't need architechture fields

If you want to check if it's a specific architecture, just do
isinstance(app, X86Access) or whathaveyou.
This has the advantage of telling the type system the type
you're looking at -- if you do that, you can do app.x86dictionary
without having to assert that it's an X86Access or cast to x86Access
or something

Thank you very much for the contribution!


Add invalid_tenant_domain_response.html file to product

Proposed changes in this pull request
Resolves https://github.com/wso2/product-is/issues/10741
When to Merge
After merging https://github.com/wso2-extensions/identity-carbon-auth-rest/pull/137

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/470772004

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/470772004

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/470772004
Status: success

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/470772004
Status: success