Houdini: Reset JOB environment

Is there an existing issue for this?

[X] I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?
$JOB always has the same value of $HIP
Unless you save the hip file in another asset!, it keeps the old $JOB
This can be solved by this enhancement:

How would you imagine the implementation of the feature?
by implementing function set_job_path()
import os
import hou
job = os.environ["HIP"]
hou.hscript("set JOB=" + job)

Are there any labels you wish to add?

[X] I have added the relevant labels to the enhancement request.

Describe alternatives you've considered:
No response
Additional context:
No response

I wouldn't make this a manual menu entry in the menu to be honest since it's easily forgotten by an artist and still means that just opening a scene might not be entirely right, yes? - this should be either automatic or studio-managed?
E.g. we have JOB set to a specific resources folder of the project, not particularly to the current asset.

Thanks for bringing this discussion @mustafa-zarkash
I agree with @BigRoy  here, this should be automaticlly changed when we saving file in different task.
Also I would like to ask if possible we can save all hip files in "hip"folder, so the files will be more organised. IMO the better way of handling files is

sh001 should be the path for JOB
inside we can create hip file and save tasks there.
This way, even if the other department people want to access the files in the same shot, cross department people can use $JOB environment and access all task project files from there.

Also I would like to ask if possible we can save all hip files in "hip"folder, so the files will be more organised. IMO the better way of handling files is

I feel like this is more of a workfile template issue then related to this issue. It's a good question, but probably be rephrased and asked on the community forum since I believe there are ways to currently do so.

sh001 should be the path for JOB

That's roughly similar to what we do - but not exactly the same.

I agree with @BigRoy here, this should be automaticlly changed when we saving file in different task.

If we can automate the $JOB variable to autoset that should solve the problem.

this should be either automatic or studio-managed?

I agree, this makes more sense!

For us if JOB==HIP then why use JOB?

I have the same question actually!
but let me rephrase my thought :

What JOB value should be ?
even if JOB is redundant , it shouldn't have the value of another asset path!

What JOB value should be ?

As explained, it's likely studios would have their own requirements for that?

even if JOB is redundant , it shouldn't have the value of another asset path!

I agree with that - that it'd be quite confusing to operate like that yes. 🗡 So we might want to at least have a mechanism in-place to allow updating it on task change.
I recall @fabiaserra having done something with that in the past and actually sharing some code snippets about that.

As explained, it's likely studios would have their own requirements for that?

Maybe we can expose it to settings and leave it to studios to decide! IDK, maybe we can post it in another issue.

isn't $JOB already automatically defined in Houdini to be the parent folder of $HIP?

isn't $JOB already automatically defined in Houdini to be the parent folder of $HIP?

Yes, However, when you open asset A and save file in asset B
$JOB of asset B still points to the asset A path!
I think there should be a post save action that sets $JOB if doesn't match $HIP for example.

then we should just need to add this in a 456.py file
hou.allowEnvironmentToOverwriteVariable("JOB", True)

?
https://www.sidefx.com/docs/houdini/hom/hou/allowEnvironmentToOverwriteVariable.html

then we should just need to add this in a 456.py file
hou.allowEnvironmentToOverwriteVariable("JOB", True)

? https://www.sidefx.com/docs/houdini/hom/hou/allowEnvironmentToOverwriteVariable.html

nvm, I see that would be only if $JOB actually changed on the env... maybe we just explicitly set it on the 456.py to whatever context it loads? it would probably just match $AVALON_WORKDIR?

maybe we just explicitly set it on the 456.py to whatever context it loads?

I think it will be easier to add that inside
https://github.com/ynput/OpenPype/blob/fd64e261df0371b16395aa5238fee1eb6f0fd705/openpype/hosts/houdini/api/pipeline.py#L307-L314


Update kubernetes-walkthrough-portal.md

Updated spelling from "ASK" to "AKS"

@CreativeManix thank for this update.
#sign-off

@CreativeManix : Thanks for your contribution! The author, @ neilpeterson, has been notified to review your proposed change.

@CreativeManix : Thanks for your contribution! The author, @neilpeterson, has been notified to review your proposed change.

@CreativeManix : Thanks for your contribution! The author, @neilpeterson, has been notified to review your proposed change.

#sign-off

@neilpeterson: I'm sorry - only the author of this article, @neilpeterson, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


use /ga4gh/tes service prefix

closes #68

Note that I moved the service-info endpoint here. Now that we have a service namespace, this doesn't need to fall under that "tasks" namespace.

Generally, it is nice that WES and TES now have a common URL pattern, plus serviceInfo not under tasks is cleaner. But is there a way of actually extracting a base path, as in WES: basePath: /ga4gh/wes/v1?

Yes, we should strive for consistency across Cloud WS APIs. There is a general schema cleanup coming that will do a couple of things:

Make the swagger definition the canonical spec
Remove the protobuf schema and makefile
clean up the swagger schema to remove a lot of the protobuf artifacts (mainly title)

After those are pulled in, we will make structural changes like the above.
Move to close this PR in favor of new issues and PRs that focus on openapi schema.

This was solved in #113


Blazor WebAssembly + GitHub Pages - Failed to load resource due 404

Currently, when trying to Deploy the Blazor WASM to GitHub Pages it cannot load most resources (CSS, Scripts & Co) due a 404. This might be due a misconfigured Deployment since some of the expected paths exist, but the files don't.

404 could be "fixed". The problem was we used DnDCharCtor.Pwa instead of DnDCharCtor in sed.
But currently the Redirects are wrong. It redirects to the Base-URL (which we use intern) instead of /DnDCharCtor.
You can see that it correctly loads the Start-Page (/ or /DnDCharCtor in GitHub-Pages)  but then redirects to /editCharacter instead of /DndCharCtor/editCharacter in GitHub-Pages. This problem is only after Deployment on GitHub-Pages. When we manually enter the Url that GitHub-Pages expects then everything works fine.

Fixed with:
https://github.com/YeGaSoft/DnDCharCtor/commit/82eaacccb6c21bb8f7e7a3fd7bd147ddf12bbe43
The problem was that we Routed to example /editCharacter but we should have used NavigateTo("editCharacter") instead of NavigateTo("/editCharacter") since our Root in GitHub-Pages is /DnDCharCtor and not / and if we Prefix / it'll try to Navigate to (for example) /editCharacter instead of /DnDCharCtor/editCharacter`.


2 gang switch doesn't work with scenes that involves the two

Hey, I'm experiencing an issue with a 2 gang switch, when using inside scenes.
I have a "Good Night" scene that turns off both gangs of the switch, but since both commands are sent to the device at the exact same time, the device only gets one of them and therefor the scene is not working as expected.
Related devices
Using a Tuya 2 gang wall switch by Moes.
To Reproduce
I guess you can reproduce it with any device that has 2 services that can be set simultaneously in a scene
Expected behavior
I would expect of course both switches to turn OFF or ON when needed
Versions used

This plugin v1.1.3
Homebridge v1.3.4
Zigbee2MQTT v1.18.2
Homebridge Config UI X v4.41.1

hint for solution
the plugin developer of ewelink has mention this happened to him with homekit automations, he solved it by adding a small delay, you can see his mention about it here:
https://github.com/bwp91/homebridge-ewelink/wiki/Multi-Channel-Devices/07370bfc6a7b1aa971b5c19495b28afd60089317#using-homekit-automations

Can you also add the MQTT messages, as requested in the Bug Report issue template?
MQTT messages
If possible (and applicable), please provide the following:

The device entry from zigbee2mqtt/bridge/devices (note: this is different from zigbee2mqtt/bridge/config/devices)
Status update from zigbee2mqtt/[FRIENDLY_NAME]
Messages published by this plugin that might be related to your issue (can also be seen in the homebridge logs)

Personally I have a 2 gang smart dimmer (from Lonsonho, but I believe it is also sold as one from Tuya).
I have never experience the issue you are describing.
I would think that the MQTT message to Zigbee2MQTT also gets combined into a single message.
After that, it is out of the plugins control how it is communicated with the device itself over Zigbee.
Depending on what the MQTT messages look like, I would think this might be something that can only really be solved in Zigbee2MQTT.

hav you tried adding both dimmers to the same scene? have you tested that it turns on/off both in the same scene?

I think I have. Nowadays I just use the "built-in" Siri commands rather than scenes (i.e. "Turn off all lights in the livingroom"). Not sure how one is handled versus the other in terms of the "low level" HomeKit commands that are being communicated.

device entry:
{
    "date_code": "",
    "definition": {
      "description": "Wall touch light switch (2 gang)",
      "exposes": [
        {
          "endpoint": "l1",
          "features": [
            {
              "access": 3,
              "description": "On/off state of the switch",
              "endpoint": "l1",
              "name": "state",
              "property": "state_l1",
              "type": "binary",
              "value_off": "OFF",
              "value_on": "ON",
              "value_toggle": "TOGGLE"
            }
          ],
          "type": "switch"
        },
        {
          "endpoint": "l2",
          "features": [
            {
              "access": 3,
              "description": "On/off state of the switch",
              "endpoint": "l2",
              "name": "state",
              "property": "state_l2",
              "type": "binary",
              "value_off": "OFF",
              "value_on": "ON",
              "value_toggle": "TOGGLE"
            }
          ],
          "type": "switch"
        },
        {
          "access": 1,
          "description": "Link quality (signal strength)",
          "name": "linkquality",
          "property": "linkquality",
          "type": "numeric",
          "unit": "lqi",
          "value_max": 255,
          "value_min": 0
        }
      ],
      "model": "ZTS-EU_2gang",
      "supports_ota": false,
      "vendor": "Moes"
    },
    "endpoints": {
      "1": {
        "bindings": [
          {
            "cluster": "genOnOff",
            "target": {
              "endpoint": 1,
              "ieee_address": "0x00124b0018e332e6",
              "type": "endpoint"
            }
          }
        ],
        "clusters": {
          "input": [
            "genBasic",
            "genGroups",
            "genScenes",
            "manuSpecificTuya"
          ],
          "output": [
            "genOta",
            "genTime"
          ]
        },
        "configured_reportings": []
      }
    },
    "friendly_name": "Kitchen Lights",
    "ieee_address": "0x60a423fffeb29907",
    "interview_completed": true,
    "interviewing": false,
    "model_id": "TS0601",
    "network_address": 15027,
    "power_source": "Mains (single phase)",
    "supported": true,
    "type": "EndDevice"
  },

while both switches are off, trying to set both ON in the same scene is producing the following logs:
May 04 14:29:22 raspberrypi npm[20009]: Zigbee2MQTT:debug 2021-05-04 14:29:22: Received MQTT message on 'zigbee2mqtt/0x60a423fffeb29907/set' with data '{"state_l1":"ON","state_l2":"ON"}'
May 04 14:29:22 raspberrypi npm[20009]: Zigbee2MQTT:debug 2021-05-04 14:29:22: Publishing 'set' 'state' to 'Kitchen Lights'
May 04 14:29:22 raspberrypi npm[20009]: Zigbee2MQTT:info  2021-05-04 14:29:22: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"linkquality":57,"state_l1":"ON","state_l2":"OFF","state_l3":"OFF","state_l4":"OFF"}'
May 04 14:29:22 raspberrypi npm[20009]: Zigbee2MQTT:debug 2021-05-04 14:29:22: Received Zigbee message from 'Kitchen Lights', type 'commandGetData', cluster 'manuSpecificTuya', data '{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":1,"fn":0,"status":0,"transid":173}' from endpoint 1 with groupID 0
May 04 14:29:22 raspberrypi npm[20009]: Zigbee2MQTT:info  2021-05-04 14:29:22: MQTT publish: topic 'zigbee2mqtt/Kitchen Lights', payload '{"linkquality":57,"state_l1":"ON","state_l2":"OFF","state_l3":"OFF","state_l4":"OFF"}'

So the plugin sends a single MQTT message ({"state_l1":"ON","state_l2":"ON"}).
The plugin can't know that this device requires special treatment.
For verification, you could send this message manually over MQTT to Zigbee2MQTT, to see if it doesn't respond correctly either (although I don't expect any different behavior).
If that's the case, I would suggest opening up an issue on the Zigbee2MQTT GitHub repository.

so I've tested everything and it appears you are right... the plugin sends both states together and zigbee2mqtt can't handle it this way... it's actually not a problem if you send them in 2 different messages simultaneously.
so if the plugin will split the message it will be good.
another reason to split the devices is as follow:
I have 2 gang wall switch that control the light in 2 different rooms, because the way that this plugin works, it exposes the lights as 2 services on the same accessory and there is no way to split them into 2 different rooms... I feel like if we're splitting the services to 2 accessories it will solve actually both issues.
what do you think?

so i've kept researching here and apparently all switches with the same duplicated services cannot get commands in the same message... I've digged into z2m code and it appears to be the normal behaviour:
both l1 and l2 are attached to the 'state' key, and when you send a message with 2 services that use this key, it will only replace one of them and use it to set the desired command.
as i've said, i think it will be easier to set the plugin to split accessories when same service is available more then once, or at least have the choice in the configuration.

apparently all switches with the same duplicated services cannot get commands in the same message

Can you indicate how you came to that conclusion exactly?
Both lights also use a different JSON property for the state (state_l1 and state_l2 as you can see in the Zigbee2MQTT log you have shared earlier).
For my 2 gang smart dimmer, this works without any problem.
The thing is, I believe this should be solved in Zigbee2MQTT. So far, I haven't heard anything "wrong" with what this plugin is doing. As mentioned before, I would suggest opening up a bug on the Zigbee2MQTT repository describing the MQTT message, the current behavior and the expected behavior.

I have 2 gang wall switch that control the light in 2 different rooms, because the way that this plugin works, it exposes the lights as 2 services on the same accessory and there is no way to split them into 2 different rooms... I feel like if we're splitting the services to 2 accessories it will solve actually both issues.

With regards to your proposal to split up all accessories into separate accessories: I think this is a bad idea.
Besides in reality, the accessory itself is one physical device, it can't physically be in multiple locations.
Ofcourse, I understand that for your specific use case, this complicates things and I can understand that you would want to have this different.
From a UX perspective, I don't think it makes sense however to split up all accessories into multiple accessories, by default.
Official HomeKit accessories also won't expose itself that way.
I'm open to feature requests/proposals that describe how this "splitting up" can be introduced as optional behavior. I'm not sure if it should be splitting up all services into separate accessories, or rather use the different Zigbee endpoints as separate accessories, but I guess that also depends on your use case/accessory you are using perhaps.
For now, you could workaround your use case by excluding the properties/keys of one of the two switches in homebridge-z2m and adding that one manually to your Homebridge configuration using the MQTT-Thing plugin.


Update trace tooling

Remove and simplify some trace wrapping internal code that made it
harder to migrate to htrace4 or complicated deprecating htrace
(whichever we end up choosing)

This is ready for review for now. I'd like to merge this in as a checkpoint towards further upgrading htrace to 4.1.

I am not familiar with the changes between versions but I can take a look at this.

HTrace has been retired.  I am not sure how well the newer supported Java.  Is this worth the effort?  Could move to Zipkin or Opentracing

haha, @mikewalch is too fast

HTrace has been retired. I am not sure how well the newer supported Java. Is this worth the effort? Could move to Zipkin or Opentracing

I've looked into Opentracing. I don't think it's mature enough at this point. I would prefer to unretire the HTrace project, have it graduate, and add opentracing compatibility to it. For now, it is worth the effort to get in line with what Hadoop 3 is using... which is 4.1.0-incubating. However, getting to 3.2 was aa major checkpoint towards that.


W: C:\Users\Vlad\Downloads\brawl-stars-45-225.apk-decompiled\res: error: failed to open directory: Can't find the file. (2).

Information

Apktool Version (apktool -version) - 2.6.1
Operating System (Mac, Linux, Windows) - Windows
APK From? (Playstore, ROM, Other) - Other

Stacktrace/Logcat
I: Using Apktool 2.6.1
I: Checking whether sources has changed...
I: Checking whether sources has changed...
I: Checking whether resources has changed...
I: Building resources...
W: C:\Users\Владик\Downloads\brawl-stars-45-225.apk-decompiled\res: error: failed to open directory: Can't find the file. (2).
brut.androlib.AndrolibException: brut.common.BrutException: could not exec (exit code = 1): [C:\Users\Vlad\AppData\Local\Temp\brut_util_Jar_80584639274089049219025431455675242125.tmp, compile, --dir, C:\Users\Vlad\Downloads\brawl-stars-45-225.apk-decompiled\res, --legacy, -o, C:\Users\Vlad\Downloads\brawl-stars-45-225.apk-decompiled\build\resources.zip]
Process exited with code 1.

Steps to Reproduce

apktool

Frameworks
If this APK is from an OEM ROM (Samsung, HTC, LG). Please attach framework files
(.apks that live in /system/framework or /system/priv-app)
APK
If this APK can be freely shared, please upload/attach a link to it.
https://brawl-stars.ru.uptodown.com/android/download (site in russian)
Questions to ask before submission

Have you tried apktool d, apktool b without changing anything? Yes
If you are trying to install a modified apk, did you resign it? No
Are you using the latest apktool version? Yes

Also got the same error on another apk, it is another

 ➜  2895 apktool d brawl-stars-45-225.apk
I: Using Apktool 2.6.1 on brawl-stars-45-225.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /home/ibotpeaches/.local/share/apktool/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Baksmaling classes2.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
I: Copying META-INF/services directory
➜  2895 apktool b brawl-stars-45-225
I: Using Apktool 2.6.1
I: Checking whether sources has changed...
I: Smaling smali folder into classes.dex...
I: Checking whether sources has changed...
I: Smaling smali_classes2 folder into classes2.dex...
I: Checking whether resources has changed...
I: Building resources...
I: Copying libs... (/lib)
I: Copying libs... (/kotlin)
I: Copying libs... (/META-INF/services)
I: Building apk file...
I: Copying unknown files/dir...
I: Built apk...
➜  2895

Sorry couldn't replicate.


Security/TLS: DTLS 1.2 image update & corrections

Description:
As reported in issue tickets #4031 (DTLS 1.1), #4627 (DTLS 1.1 (not a thing)), #4731 (Invalid DTLS 1.1 references), and #4976 (Incorrect column heading), there are several details in need of update in this page. Among them is the need to replace the DTLS 1.1 fictional information with factual DTLS 1.2 information.

The example for "DTLS 1.1" mentions a non-existing protocol
Column header "Time" over the values TRUE/FALSE (boolean)
Typo: "explcitly" (instead of explicitly)

Changes proposed:

Replace the existing DTLS 1.1 image with a DTLS 1.2 image
Replace text containing DTLS 1.1 with DTLS 1.2 .
Replace the column header "Time" with "Default behavior"
Replace "explcitly" with 'explicitly'

Additional whitespace changes:

add missing MD indent marker compatibility spacing in the "Applies to:" line
add centering in table column 2 above TRUE T& FALSE
remove all underscores from line 218 (H2 codestyle)
add NewLine to the end of the document page

Post Scriptum:
Thanks to @RAJU2529 for his patience and for inspiring me to create this PR, seeing that I was unable to contribute directly to his existing PRs .
Ticket closure or reference(s):
Closes #4031
Closes #4627
Closes #4632
Closes #4731
Closes #4737
Closes #4976

@illfated : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

@illfated: I'm sorry - only the author of this article, @justinha, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

Thanks for the proposed updates. One additional thought to Microsoft Documentation team:

Please fix any other DTLS 1.1 references across the entire MIcrosoft Docs ecosystem.
Here is an example of another document referencing a non-existent DTLS 1.1. That one seems to be in the location where I cannot submit any feedback.

Feel free to separate those into additional issue.

@ixtlanian : Thank you for the useful feedback. I am prepared to create additional Pull Requests to have the other pages corrected.
By the way, I have answered a handful of tickets where other users have claimed that the images do not show the correct state of the services being disabled, because they (in my opinion) claim that the Registry key DisabledByDefault should have the value 1 instead of 0, whereas I find that the images seem to be correct by showing the key Enabled = 0. Do you have any views on that detail?

@ixtlanian : Thank you for the useful feedback. I am prepared to create additional Pull Requests to have the other pages corrected.
By the way, I have answered a handful of tickets where other users have claimed that the images do not show the correct state of the services being disabled, because they (in my opinion) claim that the Registry key DisabledByDefault should have the value 1 instead of 0, whereas I find that the images seem to be correct by showing the key Enabled = 0. Do you have any views on that detail?

Well, this is a standard case where Microsoft makes things difficult with double negation and further complicates it with dual flags overriding each other. So let's break it down.

DisabledByDefault and Enabled control different things, but we can think of DisabledByDefault as a subset of Enabled=1 setting.
When Enabled flag is set to 0, the respective protocol version is disabled and cannot be negotiated no matter what the value of DisabledByDefault flag is. In this cases the value of DisabledByDefault is essentially ignored.
If Enabled=1 AND DisabledByDefault=1 the respective protocol is not advertised, but it can still be explicitly requested through SSPI.
If Enabled=1 AND DisabledByDefault=0 the respective protocol is available and advertised.
In short, DisabledByDefault flag is somewhat useless and confusing because no matter what the value is here, it does not really disable the protocol.

So, back to your question, while the clean settings for a completely disabled protocol are:

DisabledByDefault=1 (Disabled by Default)
Enabled=0 (Disabled)

in reality, the following combination also completely disables the protocol:

DisabledByDefault=0 (Enabled by Default)
Enabled=0 (Disabled)

Thank you very much. It is always great to see someone as knowledgeable as you on a certain topic answering a question with all necessary details included. Very good, sir.

Reminder to myself: follow up on ticket #4926 (or open a new one) to add clarification about the 2 Registry keys and their real-world actual functionality, to reduce the amount of confusion in this topic detail.

Also ref. my closed PR #4987, which did not work as intended, causing me to create my own PR (this one).

#sign-off

@illfated: I'm sorry - only the author of this article, @justinha, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

@illfated : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

@illfated: I'm sorry - only the author of this article, @justinha, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

@Kiwifulla : Could we continue our discussion in this PR?

@illfated : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Sorry, it was a difficult day yesterday. I wasn't paying attention enough and made some mistakes in my branch updates.

#sign-off

#sign-off

@illfated: I'm sorry - only the author of this article, @justinha, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

@illfated: I'm sorry - only the author of this article, @justinha, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

Yes, I know, but this is currently the only way we can signal that the PR is ready for final review & merge.

Yes, I know, but this is currently the only way we can signal that the PR is ready for final review & merge.


Incorrect returning number

I am using ionic2 with createNumberMask function to add the sum of particular fields in a loop.
It was correct when the input < 10000 (1-9999), but once input larger than 10000, it gave "NaN".
Tried inputting "10000", displaying "10,000"(what I expected), but alerted "1,0000" when I tried to add the values, so "NaN" resulted.

Can you show an example of what your trying to do.. If you could create a filaing test that would be really helpfull.

Actually, what I have:
product.html
<ion-grid *ngFor="let item of Items">
<ion-input [textMask]="{mask: mask}" [(ngModel)]="item.osBal" placeholder="Balance">
.
.
.
product.ts
public mask: Array<string | RegExp>;
numberMask = createNumberMask({
prefix: '',
suffix: '',
integerLimit: 8,
});
this.totalOutstandingBalance = 0;
for (let ele of this.Items) {
this.totalOutstandingBalance += ele.osBal * 1;
}
I just input 1000 for all fields, masking and operation OK
Once input 10000, masking display: 10,000, but total balance gave me "NaN"

Please find my attached screen cap, what I did.

input "0", the following digit cannot be input (ideal)
input "1000", the output was "10,00" (failed)
delete the input field, re-input "1000", output "1000" (ideal)
input "10000", output "1,0000" (failed)

Hope this help.


chore(master): release 1.9.6

:robot: I have created a release beep boop
1.9.6 (2023-03-22)
Bug Fixes

修改 Editor 的 z-index 使其不会遮挡『综合示例 - 新增』界面的下拉菜单 (c046e45)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/kailong321200875/vue-element-plus-admin/releases/tag/v1.9.6 :sunflower:


Draw method for BackendConfiguration

What is the expected enhancement?
It would be nice to have a method, draw() on the BackendConfiguration in qiskit.providers.models which prints out the device topology. This could be done by at least using the coupling_map, and hopefully also showing more configuration info if available / sensible.

What is wrong with plot_gate_map and the other routines?

Yeah at the level of showing the coupling map this is covered by the plot_gate_map.
However does it make sense to have a visualization of channels and busses for a pulse backend?
Also I don't think there is a method to visualize arbitrary coupling maps, only those that have been hardcoded with coordinates for the current devices. It might be useful to visualize arbitrary coupling maps (with some smartly chosen coordinates to make the look nice).

Was hoping it could include channels and maybe hamiltonian info. To be honest, I just didn't know about plot gate map. I'm fine if you guys want to close this


 I'm trying to lazy load Galaxyline but loading it at VimEnter, but it's not working. I asked other people about it and they are experiencing the same issue. Any other event works fine what the VimEnter event, which is the one I want, doesn't work.
I'm using Packer.nvim to achieve this and any other plugin that I've set to load at VimEnter works well, so I assume it's a Galaxyline issue.
What happens when I lazy load it with this event is that the line simply doesn't appear. This is what I use to lazy load it:
        use {
			"glepnir/galaxyline.nvim",
			opt = true,
			event = "VimEnter",
			config = function ()
				print("ran")
				require('nd-plugins.nd-galaxyline.lines.bubbles')
			end
		}

Entering nvim:

As you can see, the word  "ran" appeared in the command line, which means that it should have required what's after the print (Galaxyline).
If it matters, here is my Galaxyline config.

Did you find a solution?


Grammar is missing optional semicolons in some productions

Location
https://github.com/apple/swift-book/blob/main/TSPL.docc/ReferenceManual/SummaryOfTheGrammar.md?plain=1
In multiple places throughout this document.
Description
Thank you in advance for consideration of this very lengthy issue.
Consider the following example program.
This program is compilable in swiftc.
It is a trivial program just used to demonstrate allowable syntax.
class MyClass {
	//semicolons optional:
	let x = 0;
	let y = 0;
	let z = 0;

	//semicolons necessary:
	let a = 0; let b = 0; let c = 0
}

struct MyStruct {
	//semicolons optional:
	let x = 0;
	let y = 0;
	let z = 0;

	//semicolons necessary:
	let a = 0; let b = 0; let c = 0
}

actor MyActor {
	//semicolons optional:
	let x = 0;
	let y = 0;
	let z = 0;

	//semicolons necessary:
	let a = 0; let b = 0; let c = 0
}

extension Double {
	//semicolons optional:
	var km: Double { return self * 1_000.0 };
	var m: Double { return self };

	//semicolons necessary:
	var cm: Double { return self / 100.0 }; var mm: Double { return self / 1_000.0 }
}

protocol MyProtocol {
	//semicolons optional:
	var someProperty: Int { get };
	var someOtherProperty: Int { get set };

	//semicolons necessary:
	var someProperty2: Int { get }; var someOtherProperty2: Int{ get set }
}

enum MyEnum {
	//semicolons optional:
	case firsCase;
	var myVar: Int {return 0};
	case secondCase;

	//semicolons necessary:
	case thirdCase; var myOtherVar: Int {return 0}; case fourthCase
}

The above program demonstrates that in multiple cases semicolons are optional, and sometimes required to separate things.
In the Swift grammar the only place that optional semicolons show up is in the grammar for statements: https://github.com/apple/swift-book/blob/main/TSPL.docc/ReferenceManual/Statements.md?plain=1#L22
This supports the idea that statements can/may need to be separated by semicolons.
I see that these things from a theoretical point of view are mostly statements. (Except the enum cases)
But they are declaration statements.
And they are derived in the grammar (mostly) through the production -> declaration
I've already pointed out enum cases being an exception to this as they are derived through either -> union-style-enum-case-clause or -> raw-value-style-enum-case-clause
Along with protocol members which are derived through -> protocol-member-declaration
The issue I'm trying to point out here is that there is no way to derive any of the things in the example program above from the Swift grammar because there's no way to derive a semicolon(except through statement which these things do not pass through).
I understand this is a little pedantic, especially since using semicolons and putting multiple statements or things in this case on the same line goes against the Swift Style Guide.
It just seems as if the grammar contains optional semicolons for the statement productions, it should include them for all productions that can have optional semicolons.
Or at the least detail this out somewhere in the doc. (which it very well might be but I haven't been able to find anything)
In case you want to entertain this, I'll leave individual explanations below for each sub-example in the larger example above.
Class Members:
class MyClass {
	//semicolons optional:
	let x = 0;
	let y = 0;
	let z = 0;

	//semicolons necessary:
	let a = 0; let b = 0; let c = 0
}

class-members → class-member class-members?
class-member → declaration | compiler-control-statement

We can see that none of the productions for class-members allow for derivation of a semicolon.
It is too specific through the change it to
class-members → class-member | class_member ; class_members
class-member → declaration | compiler-control-statement

Because this will now allow semicolons after compiler-control-statements which use special syntactic requirements around them reminiscent of C compiler directives.
Struct Members:
struct MyStruct {
	//semicolons optional:
	let x = 0;
	let y = 0;
	let z = 0;

	//semicolons necessary:
	let a = 0; let b = 0; let c = 0
}

struct-members → struct-member struct-members?
struct-member → declaration | compiler-control-statement

This has a similar argument to Class Members.
Actor Members
actor MyActor {
	//semicolons optional:
	let x = 0;
	let y = 0;
	let z = 0;

	//semicolons necessary:
	let a = 0; let b = 0; let c = 0
}

actor-members → actor-member actor-members?
actor-member → declaration | compiler-control-statement

Similar argument to Class Members as well.
Extension Members
extension Double {
	//semicolons optional:
	var km: Double { return self * 1_000.0 };
	var m: Double { return self };

	//semicolons necessary:
	var cm: Double { return self / 100.0 }; var mm: Double { return self / 1_000.0 }
}

extension-members → extension-member extension-members?
extension-member → declaration | compiler-control-statement

Similar argument to Class Members as well.
Protocol Members
protocol MyProtocol {
	//semicolons optional:
	var someProperty: Int { get };
	var someOtherProperty: Int { get set };

	//semicolons necessary:
	var someProperty2: Int { get }; var someOtherProperty2: Int{ get set }
}

protocol-members → protocol-member protocol-members?
protocol-member → protocol-member-declaration | compiler-control-statement

protocol-member-declaration → protocol-property-declaration
protocol-member-declaration → protocol-method-declaration
protocol-member-declaration → protocol-initializer-declaration
protocol-member-declaration → protocol-subscript-declaration
protocol-member-declaration → protocol-associated-type-declaration
protocol-member-declaration → typealias-declaration

Protocol member will derive to a protocol-member-declaration rather than just a declaration.
But it's generally the same argument as Class Members and the other ones like it.
Enum Members
enum MyEnum {
	//semicolons optional:
	case firsCase;
	var myVar: Int {return 0};
	case secondCase;

	//semicolons necessary:
	case thirdCase; var myOtherVar: Int {return 0}; case fourthCase
}

union-style-enum-members → union-style-enum-member union-style-enum-members?
union-style-enum-member → declaration | union-style-enum-case-clause | compiler-control-statement
union-style-enum-case-clause → attributes? indirect? case union-style-enum-case-list
union-style-enum-case-list → union-style-enum-case | union-style-enum-case , union-style-enum-case-list
union-style-enum-case → enum-case-name tuple-type?
enum-name → identifier
enum-case-name → identifier

and
raw-value-style-enum-members → raw-value-style-enum-member raw-value-style-enum-members?
raw-value-style-enum-member → declaration | raw-value-style-enum-case-clause | compiler-control-statement
raw-value-style-enum-case-clause → attributes? case raw-value-style-enum-case-list
raw-value-style-enum-case-list → raw-value-style-enum-case | raw-value-style-enum-case , raw-value-style-enum-case-list
raw-value-style-enum-case → enum-case-name raw-value-assignment?
raw-value-assignment → = raw-value-literal
raw-value-literal → numeric-literal | static-string-literal | boolean-literal

Now we have two additional derivations to worry about which are union-style-enum-case-clause and -> raw-value-style-enum-case-clause which cannot derive a semicolon either.
We also would have a similar issue with the compiler control statements explained in Class Members if trying to separate the enum members with a semicolon.
Correction
Proposed solution:
Add ;? (an optional semicolon) to the end of:
-> declaration
-> protocol-member-declaration
-> union-style-enum-case-clause
and
-> raw-value-style-enum-case-clause
in the productions where it is appropriate to do so.
I can detail this out if necessary.

An optional semicolon should also be added in the Grammar of a precedence group in the production of precedence-group-attributes between precedence-group-attribute and precedence-group-attributes.


Bug: New version won't load.

Latest version only gives me this. Gnome 43.9 Debian

I'm already aware of this issue, it's a packaging issue. The updated packages have already been submitted, please wait for the updates.

You can fix this manually by running the following command in the terminal:
$ glib-schema-compile<EMAIL_ADDRESS>


Integrate into pub

Introducing a pub new or pub init backed by a project scaffolder like Stagehand is important to encouraging an experimental attitude towards creating Dart packages.
I know with that node, npm init along with yeoman are my gotos for creating quick one off script projects. Moments ago, I found myself in that position with Dart. I reached for that ability, didn't find it, and felt the barrier to entry. Worth considering.

This issue would belong on https://github.com/dart-lang/pub, and you're welcome to file it there, but the tendency has been for pub to do less, not more.
E.g. see https://github.com/dart-lang/pub/issues/1847.

https://github.com/dart-lang/pub/issues/2938

https://github.com/dart-lang/pub/issues/1847
https://github.com/dart-lang/pub/issues/2938
https://github.com/dart-lang/sdk/issues/35364
https://github.com/dart-lang/stagehand/issues/610


Add platformSupported flag to enable daemon mode by platform.

Supersedes #15162
/cc @tiborvass
Signed-off-by: David Calavera<EMAIL_ADDRESS>

LGTM once janky is done

LGTM


[BUG] The connection failed because the addresses could not be automatically updated between longhorn-Manager components

Chart_version: v1.0.1
Describe the bug
The pods was rebuilt after the node restarted, and the Longhorn-Manager log showed the connection :8500 timeout.
To Reproduce
Because I forgot the screenshot, now I can only use my description to explain this problem, but I think this problem is quite serious.

The host has to be restarted due to configuration optimization or failure.
After the host is restarted and the cluster is back to normal, the application has been unable to run properly. Viewing the workload log shows that the PV could not be mounted properly.
Longhorn was normal in terms of workload status. But going into the Longhorn UI to check the status of the volume is unhealthy.
Viewing the Longhorn workload log in the Rancher UI, the Longhorn-Manager workload kept prompting the connection :8500 timeout. After querying that the IP address is no longer available in the current cluster.

Temporary solution
Not sure if there were any other dependency issues, so manually recreated all the Pod associated with Longhorn, and then the PV could mount normally.
Issue analysis
From the logs, Longhorn-Manager kept prompting for connection timeouts, but Longhorn-Manager Pod was running normally and the container did not restart automatically. So can we add logic here to force the container to exit after connection failure and timeout?
Sorry, I don't know much about how Longhorn-Manager (or any other component) gets the instance-Manager IP.  If the IP is automatically acquired when the container is started, the new IP should be available after the container is automatically restarted.

@xiaoluhong Is there any log you can provide? I think the instance manager IP might be the issue here. But we should already test this scenario multiple times, so it's better if we can take a look at the log to see what triggers the issue.
CC @khushboo-rancher

Yes, we have tried this scenario multiple times and never faced this issue.
Scenarios we have tested:

Reboot the node where the pod exists.
Result:
Instance-manager, longhorn-manager pods got recreated and no problem observed.
Node down and added a new node.
Result:
Pod moved to the new node and Instance-manager, longhorn-manager pods got created on the new node.

@xiaoluhong In your case, did longhorn-manager never recreated on the rebooted node? Do you know how much time it took for the node to restart roughly?

Hi @yasker ,
Sorry, it was very late that night, the user wanted to recover the storage as soon as possible, so we directly deleted and recreated all pods, and forgot to record the log information at that time.  However, we looked at the running logs of all the components, and the most fatal problem I located was that longhorn-manager prompted a connection < IP >:8500 timeout, and other pods did not report a fatal error message. This is not the first time that similar problems have arisen, according to colleagues. So we recreated all the Pods associated with Longhorn.
Hi @khushboo-rancher,
We have restarted all the worker nodes, so the Pods of the whole cluster should be affected. None of us have operated longhorn-related Pods since the node rebooted. From the workload level, the state is normal. We are restarting nodes one by one, not all at once. Some node restarts have been abnormal, causing the reboot to take a long time, possibly more than half an hour. Can you tell me about the logic of Longhorn-Manager updating the Instance-Manager ip? Thank you.

@xiaoluhong Next time you can use Generate Support Bundle at the bottom of the UI to generate the support bundle before reinstallation, so we can keep the necessary log and look into it.
This kind of issue is likely a race condition. It's hard to troubleshoot without reproducing it or have any related log.

Ok, I will collect the log when there is a problem again. Thank you

Hi, @yasker
I have also experienced a similar problem although its fairly rare occurrence (once every month or so).
This is just my homelab playground so by all means not particularly stable environment.
I have had this occur since 0.7 to current 1.0.1
On Rancher OS nodes & now ubuntu 18.04/20.04
Rancher based cluster 2.4.5 k8s 1.18.6
Firewall log
  | Aug 5 11:39:22 | DMZHOSTING | Default deny rule IPv4<PHONE_NUMBER>) | <IP_ADDRESS>:45188 | <IP_ADDRESS>:8500 | TCP:S
  | Aug 5 11:39:22 | DMZHOSTING | Default deny rule IPv4<PHONE_NUMBER>) | <IP_ADDRESS>:46642 | <IP_ADDRESS>:8500 | TCP:S
  | Aug 5 11:39:22 | DMZHOSTING | Default deny rule IPv4<PHONE_NUMBER>) | <IP_ADDRESS>:59012 | <IP_ADDRESS>:8500 | TCP:S
  | Aug 5 11:39:22 | DMZHOSTING | Default deny rule IPv4<PHONE_NUMBER>) | <IP_ADDRESS>:44502 | <IP_ADDRESS>:8500 | TCP:S
I get lots of traffic leaving the cluster and hitting the firewall interface from kubernetes internal IP addresses.
Source: longhorn-manager-9m922  1/1     Running     0          14d     <IP_ADDRESS>
Destination: Unsure, but i am certain that no currently running Pod/Service exists on that IP address anymore
All nodes are on the same subnet, i assume that the traffic leaving the cluster is only because that IP no longer exists therefore it gets routed to the node/default gateway(firewall).
Longhorn support bundle
https://drive.google.com/file/d/1tEbZLqeuFkHbaA2-rALle6qeFLyCYYr2/view?usp=sharing
I am not really sure what causes this issue initially, i expect node instability or some sort of environment failure. However once it happens longhorn is constantly sending traffic to a no longer existent IP. Although in many cases such as the above support bundle is it running without issues.
Bundle environment info:
Currently one pod is scaled to zero so it has one unattached volume
One node seems to be full on storage, although i suspect this is longhorn leaving redundant replicas on the node/another issue.
A few more firewall logs to show the range of IPs which this is occurring within the cluster
Aug 5 13:15:48 | DMZHOSTING | <IP_ADDRESS>:53932 | <IP_ADDRESS>:8500 | TCP:S
  | Aug 5 13:15:48 | DMZHOSTING | <IP_ADDRESS>:54466 | <IP_ADDRESS>:8500 | TCP:S
  | Aug 5 13:15:48 | DMZHOSTING | <IP_ADDRESS>:52740 | <IP_ADDRESS>:8500 | TCP:S
  | Aug 5 13:15:48 | DMZHOSTING | <IP_ADDRESS>:42794 | <IP_ADDRESS>:8500 | TCP:S
  | Aug 5 13:15:48 | DMZHOSTING | <IP_ADDRESS>:42760 | <IP_ADDRESS>:8500 | TCP:S
  | Aug 5 13:15:48 | DMZHOSTING | <IP_ADDRESS>:54268 | <IP_ADDRESS>:8500 | TCP:S
  | Aug 5 13:15:48 | DMZHOSTING | <IP_ADDRESS>:59398 | <IP_ADDRESS>:8500 | TCP:S
More than happy to provide any further info you would like,
I am currently unable to find a way to recreate this but i will have another go on a new cluster.
Regards,
Andrew

Keep this open

After upgrade from 1.0.0, we also see similar problem in one of the node. longhorn manager keep flooding logs like this:
time="2020-10-23T20:49:47Z" level=error msg="Failed to get the notifier of instance manager instance-manager-e-4d44ba64 before monitoring: failed to open process update stream: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:8500: connect: no route to host\""
time="2020-10-23T20:49:47Z" level=warning msg="Error syncing Longhorn engine longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: fail to sync engine for longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: failed to get process pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:8500: connect: no route to host\""
time="2020-10-23T20:49:50Z" level=error msg="Failed to get the notifier of instance manager instance-manager-e-4d44ba64 before monitoring: failed to open process update stream: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:8500: connect: no route to host\""
E1023 20:49:50.261243       1 engine_controller.go:209] fail to sync engine for longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: failed to get process pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:8500: connect: no route to host"
time="2020-10-23T20:49:50Z" level=warning msg="Dropping Longhorn engine longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4 out of the queue: fail to sync engine for longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: failed to get process pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:8500: connect: no route to host\""
time="2020-10-23T20:49:53Z" level=warning msg="Error syncing Longhorn engine longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: fail to sync engine for longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: failed to get process pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:8500: connect: no route to host\""
time="2020-10-23T20:49:56Z" level=warning msg="Error syncing Longhorn engine longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: fail to sync engine for longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: failed to get process pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:8500: connect: no route to host\""
time="2020-10-23T20:49:59Z" level=warning msg="Error syncing Longhorn engine longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: fail to sync engine for longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: failed to get process pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:8500: connect: no route to host\""
E1023 20:50:02.549217       1 engine_controller.go:209] fail to sync engine for longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: failed to get process pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:8500: connect: no route to host"
time="2020-10-23T20:50:02Z" level=warning msg="Dropping Longhorn engine longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4 out of the queue: fail to sync engine for longhorn-system/pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: failed to get process pvc-46e38adf-828c-4358-9d93-7979db4ab9a7-e-6bf5e1d4: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:8500: connect: no route to host\""

@ElisaMeng Assume your workloads on that node are already down, can you kubectl delete the instance-manager-e-xxxx on that node? Longhorn will recreate the instance manager and that should sort things out.
Alternatively, if you take a look at kubectl -n longhorn-system get lhim -o yaml, you should be able to see an instance-manager-e-xxx has the IP <IP_ADDRESS>. The name of that instance-manager-e should be the same one that on this node.
We will fix this issue for v1.1.0 release.

This issue should be a duplicate of https://github.com/longhorn/longhorn/issues/1880

@andrewdavies-net Thanks for reporting. We've recently found another case of the issue in #1880. I've checked your support bundle and found the symptoms are the same - Longhorn is trying to communicate with IP addresses doesn't exist, and those address were the IP of the instance managers once. I believe the reason is the same as I explained in https://github.com/longhorn/longhorn/issues/1880#issuecomment-708717733 .
It's also very rare to reproduce since it requires the Longhorn manager to miss a few events before getting into this state.
I will close this issue as a duplicated and we will fix the issue in v1.1.0 release.

@yasker Thank you so much! This seem happen quite frequently in  a 50 nodes cluster. When 1.1.0 is coming out? We love longhorn!
BTW,  what happen when instance-manager crash/restart? will it cause data lost?

@ElisaMeng v1.1.0 is scheduled for next month.
Also, instance manager crash will not result in data lost. If it's the replica instance manager, you will only lose a replica temporarily; If it's the engine instance manager, it will be recreated and volume will be reattached to the node, however the pod needs to be recreated to get back the mount point. For v1.0.x, we suggested set liveness probe (see https://longhorn.io/docs/1.0.2/high-availability/recover-volume/ ) to trigger the pod restart; for v1.1.0, we will delete the workload pod automatically to trigger the recreation of the pod, so the service should recover automatically.

Has this been fixed? I'm having the exact same issue with v1.4.2. and also port 8500 as described above.


Provide BigQuery Storage API library and samples

Provide integration wrapper for BigQuery Storage API.

samples for common queries
error handling samples

Just wanted to confirm what you're envisioning here, given the nature of the BQ storage API is more oriented to distributed system patterns which are less common in PHP.  Are you primarily interested in the projection and filter pushdown aspects with a single reader?

I envision consuming something by GRPC.There are Plugins and libraries in PHP to consume Grpc feeds.
Otherwise something that will have a scroll_id concept. So run the initial request, return a session ID/or scroll ID. And let the parallel PHP processes like message queue worker agents to read based on the session/scroll id.
The whole idea is that get faster to data returns, something that can be intensive parallelized and it's beyond traditional pagination.


Updates.

Current coverage is 38.02% (diff: 100%)

Merging #14 into test will not change coverage

@@               test        #14   diff @@
==========================================
  Files           578        578
  Lines         25325      25325
  Methods        4584       4584
  Messages          0          0
  Branches        106        106
==========================================
  Hits           9629       9629
  Misses        15684      15684
  Partials         12         12

Powered by Codecov. Last update 25b5ca0...a388029


[imgui-sfml] Force imgui-sfml to be a static library

Force imgui-sfml to be a static library to avoid the issue of loading global variables in imgui twice.
Related: #9660.

I was one of those affected by issue #9660.
I tried this PR and it indeed fixes the crash.
There is one new small annoyance though. On Windows (at least), I now get link errors unless I add opengl32.lib to my project, which was not required when this was a dynamic library. I'm not sure if this is to be expected or if there is a way to automatically link to opengl32.lib too using vcpkg. I tested with VS2019 in Debug x64 configuration.
Sample of link errors:
1>ImGui-SFML.lib(imgui-SFML.cpp.obj) : error LNK2019: unresolved external symbol __imp_glBindTexture referenced in function "void __cdecl `anonymous namespace'::RenderDrawLists(struct ImDrawData *)" (?RenderDrawLists@?A0x823403ac@@YAXPEAUImDrawData@@@Z)
1>ImGui-SFML.lib(imgui-SFML.cpp.obj) : error LNK2019: unresolved external symbol __imp_glBlendFunc referenced in function "void __cdecl `anonymous namespace'::RenderDrawLists(struct ImDrawData *)" (?RenderDrawLists@?A0x823403ac@@YAXPEAUImDrawData@@@Z)
1>ImGui-SFML.lib(imgui-SFML.cpp.obj) : error LNK2019: unresolved external symbol __imp_glColorPointer referenced in function "void __cdecl `anonymous namespace'::RenderDrawLists(struct ImDrawData *)" (?RenderDrawLists@?A0x823403ac@@YAXPEAUImDrawData@@@Z)

@VincentZalzal The issue that the system library is not automatically added after integration using the msvc project(sln/vcxproj) is currently unresolved. So you need to add them manually now.

@JackBoosY That's ok, it's still a lot better to be able to use vcpkg to handle all the rest!

@Neumann-A At present, x64-linux is used to generate static libraries by default. If there is a dynamic library in lib, it must be a port bug.

there is x64-osx-dynamic in the community triplets so somebody adding x64-linux-dynamic is not that far away. Also having vcpkg_check_linkage(ONLY_DYNAMIC_LIBRARY) in x64-linux won't trigger an error since it is perfectly allowed by vcpkg since VCPKG_CRT_LINKAGE is dynamic in x64-linux.

/azp run

/azp run

@strega-nil Please review this PR.
Thanks.

Cool, thanks @JackBoosY :)

This has been merged broken despite @neumann-a review... :(

@Neumann-A @cenit I will continue to fix this issue.

oh shoot, I'm sorry -.-


[GHSA-296w-6qhq-gf92] Django denial of service via file upload naming

Updates

Affected products
References

Comments
add a patch for v1.7: https://github.com/django/django/commit/3123f8452cf49071be9110e277eea60ba0032216

Hey @MarkLee131, I'm going to reject this one as we don't have a 1.7.x affected product and the patch is largely the same as others which we already have.


manual mode -nc 0 stuck in low speed forever

Hello,
client config:
-mode=manual -interval 10 -datashard 10 -parityshard 3 -nodelay 1 -resend 2 -nc 0 \
    -rcvwnd 4096  -sndwnd 4096 -conn 25 -l "<IP_ADDRESS>:%SS_LOCAL_PORT%" \
    -r "%SS_REMOTE_HOST%:%SS_REMOTE_PORT%" -nocomp -crypt salsa20 -key "key"

server config:
{
        "listen": ":41444",
        "target": "localhost:22112",
        "mode": "manual",
        "crypt": "salsa20",
        "key": "key",
        "nocomp": true,
        "sndwnd": 4096,
        "rcvwnd": 4096,
        "interval": 10,
        "datashard": 10,
        "parityshard": 3,
        "nodelay": 1,
        "resend": 2,
        "nc": 0
}

WIth nc = 1, the server floods my internet connection with UDP packets and causes all other apps and PCs on LAN to experience packet loss. Since congestion control is off, there's no way to tell the sender to "slow down" by router QoS packet dropping.
So I set nc = 0 on client and server, but in this case the download throughput remains locked at 70 kilobytes per second never increasing. If I turn off nodelay on client and server also, I get better speed of a few hundred kilobytes per second, but it's still very slow. I tried changing sndwnd/rcvwnd, interval, datashard and parityshard and resend with no result.
There is no documentation on how to make nc = 0 (congestion control active) working correctly. Is there something wrong in my usage ? From what I read on kcp project, I see that it's supposed to behave as TCP slow start/ramp up, but it's not working for my case.
Thanks.

decrease the sndwnd & rcvwnd, you can start from 256

I tried, it didn't help. It just made the low speed starting level lower. When I tried changing the sendwnd / rcvwnd to different values. It seems that larger values make the starting speed faster but then it either never enlarges the window or actually decreases it (it slows down). Maybe this is related to RTT ? My RTT to my VPS is around 80ms and I'm testing a normal https download from a server near to my VPS (~82ms).

OK here's an interesting thing, iperf3 forced through ss + kcp behaves seemingly correctly, but a normal http download through ss + kcp does not. I will investigate more.


Setup landing page with a plugin player

https://smartpodcastplayer.com/product

Dependent on: https://github.com/heptio/thekubelets/issues/7


Markdown files with a dot in the filename don't get rendered by the right parser

Example:
advanced-laravel-5.1.md

error:
View [_blog.advanced-laravel-5.1] not found.

I can fix it by renaming it advanced-laravel-5-1.

Addressed in https://github.com/tightenco/jigsaw/pull/141


add refresh capability to debug.log (#81)

Description
The debug.log file currently retains debug information from previous runs of TerminusBrowser. With this patch, the file is deleted before running the browser again.
Fixes #81
Type of change
New feature (non-breaking change which adds functionality)

Great work :)


Fix bug where algorithm names weren't being logged properly in traces

Turns out some of our tests rely on things being done the previous way, hence engine tests now fail, and this could cause some strange behaviors if the same algorithm is used more than once as in the tests. So, this will take some more work.

Nice -- has this now exposed a passing test is actually failing?

No, things work correctly on current dev, only issue is some of our docstrings are misleading, and changing code to be in line with the docs causes things to break.

Closing this for now until I fix it properly.


Changed the Phone number in the Home Screen

The phone number in the home screen has turned to purple.

I changed the colour as it was previously.

Thanks for the PR @tharuka01 !
Btw, we don't do any changes to the material-lit.css file as a practice. If you need to change CSS, please create a custom class on /assets/css/custom.css file

Ok I will do


(📚) documentation for B028 is misleading

The warnings.warn method uses a stacklevel of 1 by default, which limits the rendered stack trace to that of the line on which the warn method is called.

https://docs.astral.sh/ruff/rules/no-explicit-stacklevel/#no-explicit-stacklevel-b028
reading this, it implies that if a higher number is set, then the stack trace will contain multiple entries

It's recommended to use a stacklevel of 2 or higher, give the caller more context about the warning.

- give
+ giving
OR
+ to give

maybe
The `warnings.warn` method uses a stacklevel of 1 by default, which will output a stack frame of the line on which the `warn` method is called. Setting it to a higher number will output a stack frame from higher up the stack.

It's recommended to use a `stacklevel` of 2 or higher, to give the caller a more appropriate context about the warning.

Nope! Hoping for a new contributor to take it as an excuse to pull down the repo and get comfortable with the PR process 😄

Yeah I was starting to look at it but the PR process is a bit complex so I won't be able to get into it during this month, so anyone can feel free to do it

I thought I would try this to learn the process for a pull request. Sorry about the mess with the commits.

@glthm Please don't hesitate to reach out and I can help navigate the PR process! Also would love feedback if the CONTRIBUTING docs could be made more helpful / less intimidating 😄

Thanks @njhearp! No need to apologize for the commits - great contribution!


An Idea: Use vectors instead of text

This is ideal when we need to compute the embeddings for any other steps (vector search, ...). Instead of creating vectors embeddings two times, for semantic routing and semantic search.
We can compute one time the embeddings and use it for semantic routing and search.

Great idea, we've now added it with #121


Modify docs for adding a new workflow

Copied over from this private PR: https://github.com/mendix/Mendix10-docs/pull/14
Please replicate all comments yourself here, as they cannot be ported over.

@Yiyun333 , I approved changes and took the Needs language review label off.


Import JSON data with MiXiT 2017 format

Export data from Mongo
Cleanup data (remove english articles written in french for example)
Create the relevant JSON files
Cleanup DTO and import mechanism to only import new data

Pre-requisite for #139


Code up API submission for arrivals with transitOperation from user answers

Can also add https://github.com/hmrc/manage-transit-movements-departure-frontend/blob/b51886314786ab962f7814980e75f7de8cef24e4/build.sbt#L65 to remove warnings being generated by the scalaxb library. Otherwise looks good I think 🙂


Merge changes to test coordinate system manager

Hello @vhirtham! Thanks for opening this PR.

In the file tests/_helpers.py:

Line 8:80: E501 line too long (87 > 79 characters)
Line 45:80: E501 line too long (84 > 79 characters)

In the file tests/test_geometry.py:

Line 185:80: E501 line too long (86 > 79 characters)
Line 408:80: E501 line too long (86 > 79 characters)
Line 849:80: E501 line too long (88 > 79 characters)
Line 1064:80: E501 line too long (81 > 79 characters)
Line 1071:80: E501 line too long (81 > 79 characters)
Line 1204:80: E501 line too long (84 > 79 characters)
Line 1443:80: E501 line too long (86 > 79 characters)
Line 1611:80: E501 line too long (84 > 79 characters)
Line 1614:80: E501 line too long (80 > 79 characters)
Line 1617:80: E501 line too long (86 > 79 characters)
Line 1621:80: E501 line too long (86 > 79 characters)
Line 1624:80: E501 line too long (82 > 79 characters)
Line 1691:80: E501 line too long (81 > 79 characters)
Line 1939:80: E501 line too long (80 > 79 characters)
Line 2081:80: E501 line too long (84 > 79 characters)
Line 2171:80: E501 line too long (86 > 79 characters)
Line 2288:80: E501 line too long (86 > 79 characters)
Line 2337:80: E501 line too long (80 > 79 characters)
Line 2368:80: E501 line too long (82 > 79 characters)
Line 2370:80: E501 line too long (83 > 79 characters)
Line 2371:80: E501 line too long (82 > 79 characters)
Line 2374:80: E501 line too long (84 > 79 characters)
Line 2375:80: E501 line too long (82 > 79 characters)
Line 2407:80: E501 line too long (85 > 79 characters)
Line 2410:80: E501 line too long (88 > 79 characters)
Line 2585:80: E501 line too long (82 > 79 characters)

In the file tests/test_transformations.py:

Line 84:9: W503 line break before binary operator
Line 96:9: W503 line break before binary operator
Line 97:9: W503 line break before binary operator
Line 108:80: E501 line too long (87 > 79 characters)
Line 150:80: E501 line too long (85 > 79 characters)
Line 190:80: E501 line too long (83 > 79 characters)
Line 244:80: E501 line too long (84 > 79 characters)
Line 551:80: E501 line too long (86 > 79 characters)
Line 552:80: E501 line too long (86 > 79 characters)

In the file weldx/geometry.py:

Line 479:80: E501 line too long (82 > 79 characters)
Line 707:80: E501 line too long (81 > 79 characters)
Line 708:13: W503 line break before binary operator
Line 837:80: E501 line too long (85 > 79 characters)
Line 850:80: E501 line too long (81 > 79 characters)
Line 1133:80: E501 line too long (81 > 79 characters)
Line 1165:80: E501 line too long (88 > 79 characters)
Line 1194:80: E501 line too long (83 > 79 characters)
Line 1198:80: E501 line too long (85 > 79 characters)
Line 1203:80: E501 line too long (82 > 79 characters)
Line 1329:80: E501 line too long (87 > 79 characters)
Line 1391:80: E501 line too long (84 > 79 characters)
Line 1399:80: E501 line too long (88 > 79 characters)
Line 1404:80: E501 line too long (83 > 79 characters)
Line 1409:80: E501 line too long (84 > 79 characters)
Line 1420:80: E501 line too long (87 > 79 characters)
Line 1422:80: E501 line too long (83 > 79 characters)

In the file weldx/transformations.py:

Line 52:80: E501 line too long (85 > 79 characters)
Line 92:9: W503 line break before binary operator
Line 93:9: W503 line break before binary operator
Line 95:80: E501 line too long (81 > 79 characters)
Line 123:80: E501 line too long (83 > 79 characters)
Line 135:80: E501 line too long (86 > 79 characters)
Line 155:80: E501 line too long (84 > 79 characters)
Line 190:80: E501 line too long (88 > 79 characters)
Line 219:13: W503 line break before binary operator
Line 220:13: W503 line break before binary operator
Line 279:80: E501 line too long (81 > 79 characters)
Line 290:80: E501 line too long (81 > 79 characters)
Line 305:80: E501 line too long (80 > 79 characters)
Line 317:80: E501 line too long (85 > 79 characters)
Line 326:80: E501 line too long (80 > 79 characters)
Line 338:80: E501 line too long (85 > 79 characters)
Line 347:80: E501 line too long (80 > 79 characters)
Line 359:80: E501 line too long (85 > 79 characters)
Line 449:80: E501 line too long (88 > 79 characters)
Line 453:80: E501 line too long (83 > 79 characters)
Line 467:80: E501 line too long (87 > 79 characters)
Line 471:17: W503 line break before binary operator
Line 476:80: E501 line too long (81 > 79 characters)

Do see the Hitchhiker's guide to code style


Document encoding-profiles parameter in ComposeWorkflowHandler

The compose operation has a encoding-profiles parameter that is not documented.
This PR adds the parameter to the parameters table and an example.

Sorry for the delay. Nearly forgot about this.


Add ServiceMonitor configuration for integration service

Signed-off-by: Jing Qi<EMAIL_ADDRESS>

/lgtm


Added a proxy build image for maistra-2.1

Not sure if GCLOUD_VERSION is set to a correct version.

I'm also working on it (using clang as well) and will modify it in a near future.

Sweet. I needed a container to update deps and run tests for 2.1 proxy...

Can you add a target for it in Makefile in addition to the 2.0 one?

Done.

I'm also working on it (using clang as well) and will modify it in a near future.

Sweet. I needed a container to update deps and run tests for 2.1 proxy...

Can you add a target for it in Makefile in addition to the 2.0 one?

Done.


WebVR support doesn't work

Testing with the Cardboard APK build of chromium webvr
ig.system.setStereoMode(true);
Uncaught TypeError: Cannot read property 'projection' of null
Uncaught (in promise) TypeError: this.hmdDevice.getEyeTranslation is not a function
at Class.tpf.StereoRenderer.tpf.Renderer.extend.enumerateVRDevices
Uncaught TypeError: Failed to execute 'uniformMatrix4fv' on 'WebGLRenderingContext': No function was found that matched the signature provided.

I'll retry this later with a proper development environment (not baked) - so that you can get line numbers and files (all in StereoRenderer).
I will be working to get WebVR support into my game before it releases, and intend to fork, fix, and pull request if you don't get around to it.
I tried to get it to work as-is with chrome and firefox webvr builds and a DK2 during a game jam, so it was more of a "if it works, great" situation.

https://twitter.com/phoboslab/status/744508131410120704
Hopefully this means you're working on this?

I was, yes. I stopped short, because of the sound issue mentioned in the tweet.
I'll try to push my changes so far to this repo sometime this week!

Poke? @phoboslab ?


exercises(circular-buffer): fix name of instructions append file

The name must use a dot, not a dash.
From the docs:

.docs/instructions.append.md: additional introduction text to append after the existing instructions (optional)

Ping @ErikSchierboom

Thanks


Lost some already built modules after ru

System information

CPU: Intel i7-8700
Memory: 32 GB
Video Card: GeForce GTX 1080 Ti
OS Platform and Distribution (e.g., Linux Ubuntu 18.04): Linux Ubuntu 20.04.1
Apollo installed from (source or binary): source
Apollo version (3.5, 5.0, 5.5, 6.0): 6.0, master branch
Output of apollo.sh config if on master branch:

Steps to reproduce the issue:

first, enter apollo container:

cd ~/Downloads/apollo/
./docker/scripts/dev_into.sh

then, build apollo with gpu in container:

./apollo.sh build_opt_gpu

when apollo build finished, check modules in bazel-bin directory:

ll bazel-bin/modules/

modules list as below:

run bootstrap.sh script, and it works well:

then, build python api example named talker.py with bazel build command:

bazel build //cyber/python/cyber_py3/examples:talker

and talker example built successfully:

when I stop and start bootstrap.sh script again, apollo complains missing cyber_launch:

check alreay built modules in bazel-bin again, I found that some modules have lost:

as we can see, module list is much shorter than before!

I don't know it is a bug or feature of Bazel, it may clean bazel-bin directory when perform bazel build or bazel run command, it causes I can't build and debug my own python script in apollo container!

n't build and debug my own python script in apollo container!

The reason was as follows:
When you run ./apollo.sh build_opt_gpu, bazel runs bazel build --config=opt --config=gpu under the hood.
And the compilation mode is -c opt implied by --config=opt.
When you run bazel build //path/to:your_target, the compilation mode is -c fastbuild which is bazel's default configuration.
So, my suggestion would be, either use ./apollo.sh build_opt_gpu all the time, or use
bazel build --config=opt --config=gpu //path/to:your_target

to avoid this problem.
See doc: https://github.com/ApolloAuto/apollo/blob/master/docs/specs/apollo_build_and_test_explained.md

I have tried your solution, and it works! Thanks a lot!

It seems that your problem has been solved and this issue will be closed. Please feel free to reopen it or open a new issue if you still have any other questions. Thanks for your support for Apollo!


Bump to 21.23.1

Change attachment request format text to match Whitehall (PR #1306)

@andysellick Sorry, early morning brain not functioning.  Done!


refactor(dispatch-service): separated internal from external HSDS basepath configuration

:tada: This PR is included in version 6.0.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Hotfix cannot get transaction status

update the base url
add base url v1

kindly help to review too, mas @omarxp and @Xaxxis

Temporary urgent hotfix has been released: https://github.com/Midtrans/midtrans-php/releases/tag/v2.5.1
It revert to last stable version of v2.4.4
So you have more time to properly fix this issue now, let's be more mindful and ensure stability on next release.

Kindly help to review again kak @rizdaprasetya


Implemented basic route planing, now without printing every stop.

Implemented basic route planing functionality as described in issue #5
Now without printing every stop.

Awesome, thanks for your work! 😊

Glad I could help. If it needs some improvement in the future just let me know.


Line Chart backgroundColor looks scratched when assigning segment borderColor, 200~ points on dataset

Expected behavior
Line background should be continuous.

Current behavior

When defining segment color inside a dataset with  200~ elements, background looks like sliced.
Reproducible sample
https://codepen.io/Alejgolop/pen/vYQRvmd
Optional extra steps/info to reproduce
No response
Possible solution
No response
Context
No response
chart.js version
4.3.0
Browser name and version
Google Chrome V 114.0.5735.199
Link to your project
No response

I also encountered this error too. I tried many settings.
What helped me is to show the dataset twice and use one just for the background color. Rather a workaround than a bugfix though.


How to handle multiple loaders with different plugins using postcss.config.js?

Hi,
I have the full issue here. The problem is that the user needs to run different plugins on different loaders. One should get only stylelint and so on.
I can see you can return a function from postcss.config.js, but then the problem becomes how to tell the loader definitions apart. Webpack 2 doesn't allow setting custom fields per a loader definition. Maybe we could piggyback on options, though?
Any ideas on how to handle this?

I will add config option on this week.

Ok, cool. 👍

@bebraw What context would be needed ? ctx.webpack is on the ctx by default, it's just not 'harmonised' with other build tool integrations, due to time leakings of mine atm. (ctx.env, ctx.ext, ctx.dir etc.)
ctx.env = process.env.NODE_ENV ( :shipit: )
ctx.dir = dirname(webpack.resourcePath) (:shipit: as ctx.webpack)
ctx.ext = webpack.resourcePath.endsWith('.sss') (:shipit: as ctx.webpack)
Anything else that could be shimmed from ctx.webpack to its own prop? Note that build tool specific ctx should be always on it's own ctx['webpack'], but things like dir, ext, file || filename etc can be harmonised between them.
@ai Implementation proposal for config 💪 😛
webpack.config.js
{
  test: /\.css/,
  use: [
    { loader: 'css-loader', options: { importLoaders: 1 } },
    {
       loader: 'postcss-loader',
      // options.config is -1 in terms of code style/cide cleaness,
      // maybe better solution can be found :)
       options: {
         config: { file: 'alternative/path/to/postcss.config.js', ctx: { modules: true } }
       }
    }
  ]
}

postcss.config.js
module.exports = (ctx) => ({
    parser: ctx.ext === '.sss' ? 'sugarss' : false
    plugins: {
      'postcss-import': { root: ctx.dir },
      'postcss-modules': ctx.modules ? {} : false
      'postcss-whatever': ctx.whatever ? {...ctx.foo} : {..ctx.bar}
    }
})

Besides that, since webpack core member is present, I like to propose merging postcss-loader/css-loader 😛 . css-loader uses postcss for CSS Modules under the hood anyways
webpack.config.js
{
  test: /\.css/,
  use: [
   // via postcss.config.js
    {
       loader: 'css-loader',
       options: {
         config: { file: 'alternative/path/to/postcss.config.js', ctx: { modules: true } }
       }
    },
   // or inline
    {
      loader: 'css-loader',
      options: {
         parser: 'sugarss',
         modules: true,
         plugins: () => [...plugins]
      }
    }
  ]
}

And by the way the same would apply to html-loader+ posthtml-loader + posthtml.config.js :)

Do we need a ctx magic if we will have different config paths? But I am OK with both syntax: config: "path" and config: "path", ctx: { … }

To refer to https://github.com/survivejs/webpack/issues/129, in that case it would be enough if you could perform a check against enforce option, right @Velenir?
I'm sure this is not the only use case, though. It would be good to know how people are actually using postcss-loader in their projects now.

Besides that, since webpack core member is present, I like to propose merging postcss-loader/css-loader 😛 . css-loader uses postcss for CSS Modules under the hood anyways

My understanding is that we actually might want to go to the opposite direction in the future as it feels like the current css-loader does too much. This would mean pushing the CSS Modules functionality out of it entirely and possibly handling it through postcss-loader.
That said, I would love to see a strong design for CSS pipeline as it feels like a sore point at the moment. Simplifying css-loader would just push the problem elsewhere.
I have a feeling we might need some kind of concept of context in the design in order to eliminate weirdness like importLoaders index. I guess at minimum this might mean a separate option for css-loader where you specify which loaders it should use to parse on @import (loader definition within loader definition).
Minification is another interesting point, but that goes beyond this issue so I won't expand on that. The things I mentioned above are more of longer term concerns.

Yes, in case of linting in a preloader it would be enough to check for enforce. But there may be cases of postcss-loader in different arbitrary positions in the loaders' chain, so some kind of loader specialization would still be necessary.
Also, currently in the context a preloader is simply appended to the loaders array with nothing to distinguish it from a normal first loader -- both would be first in the chain (first from the right in the array) -- no enforce property, no nothing.

@ai Yes and no 😛 . If it's clear separation of concerns like e.g linting .scss files with postcss-loader and stylelint => use separate postcss.config.js in .scss directory
It's not possible to override plugin options via context, if required e.g ctx.modules
postcss.config.js
module.exports = (ctx) => ({
   parser: 'sugarss'
   plugins: {
     'postcss-nested' : ctx.package ==='spa' : {} : false
     'postcss-bem':  ctx.package !=== 'spa' && ctx.style === 'bem' ? { style: bem } : { style: 'suit' }
     'postcss-modules': ctx.package === 'spa' && ctx.modules ? {} :  false
   }
})

webpack.config.js
{
   loader: 'postcss-loader',
   options: { ctx:  { style: 'bem' modules: true, package: 'spa' } }
}

Is it really needed? Probably not, but it gives you max control over your config for whatever usecase you might have.

Also, currently in the context a preloader is simply appended to the loaders array with nothing to distinguish it from a normal first loader -- both would be first in the chain (first from the right in the array) -- no enforce property, no nothing. So loaderIndex === loaders.length -1 doesn't guarantee that the current loader is pre.

@Velenir I never understood that feature from the beginning since the loader chain is an array which gets reduced/composed  loader3(loader2(loader1())), setting anylint-loader/test-loader related loader as the first in the chain should basically do the same.
use: [ 'style-loader', 'css-loader', 'postcss-loader' (build), 'sass-loader', 'postcss-loader' (lint) ]

My understanding is that we actually might want to go to the opposite direction in the future as it feels like the current css-loader does too much. This would mean pushing the CSS Modules functionality out of it entirely and possibly handling it through postcss-loader.

My understanding is that we actually might want to go to the opposite direction in the future as it feels like the current css-loader does too much. This would mean pushing the CSS Modules functionality out of it entirely and possibly handling it through postcss-loader.

That said, I would love to see a strong design for CSS pipeline as it feels like a sore point at the moment. Simplifying css-loader would just push the problem elsewhere.
@bebraw Actually people even want to use it with postcss-loader when the getting started with all that fuss, the issue here is that postcss-loader lacks the logic to include CSS Modules into the bundle like css-loader does. Then folks switch to the 'css-loaderimplementation of CSS Modules. If someone could enlighten/guide me where/howcss-loaderhandles that I will try to find a solution forpostcss-loader`
// css-loader { modules: true }
import $ from 'style.css'

// postcss-loader { modules: true }
import $ from 'modules.json'

I have a feeling we might need some kind of concept of context in the design in order to eliminate weirdness like importLoaders index.

How in details does importLoaders work? :)
e.g postcss-import with result.messages.dependency returns all @import paths && postcss-loader adds them to this.addDependencyTo(...messages.dependencies) automatically. Would that be enough to replace it, assuming that loaders like less/stylus/sass-loader take care of adding there @imports to webpack theirselves?
I guess at minimum this might mean a separate option for css-loader where you specify which loaders it should use to parse on @import (loader definition within loader definition).

Simplifying css-loader would just push the problem elsewhere.

Yep, to some point. Sourcemaps, Minifier, CSS Linter, CSS Modules, @import (Loading && Tracking) that's all provided by PostCSS.  The problem is the implementation 'chaos', itäs just smells like this could be handled in a easier way with the right combo.
                /------CSS*(AST)--------\
bundle.js                                             ------.....
                \------CSS**(STRING)---/

*PostCSS: Lint, Minify, Modules, @import, plugins ('advanced')
**: Just bundle CSS ('simple')

So basically postcss-loader 'lacks'  advanced webpack support, while on the other hand css-loader 'lacks' advanced postcss support.  ¯_(ツ)_/¯

@bebraw postcss-loader now offically support plugins parameter in webpack config. https://github.com/postcss/postcss-loader#plugins
Do we need multiple config anymore?

So basically postcss-loader 'lacks' advanced webpack support, while on the other hand css-loader 'lacks' advanced postcss support. ¯_(ツ)_/¯

That's the core point. Some design decisions are needed. Esp. importLoaders feels like a hack and this particular overlap is troublesome. I'll get more eyes on this.

@bebraw postcss-loader now offically support plugins parameter in webpack config. https://github.com/postcss/postcss-loader#plugins

That looks good to me. 👍

Do we need multiple config anymore?

I'm not sure. Is the above the recommended way now?

@bebraw Could we ask Tobias to guide someone though the css-loader code base?

Do we need multiple config anymore?

1. Inline (no postcss.config.js)
const options = { parser: 'sugarss'  map: 'false' }
const plugins = (ctx) => [ require('postcss-import')({ root: ctx.resourcePath }) ]

{
  loader: 'postcss-loader',  options: {...options, plugins: plugins(webpack) } // ctx == webpack
}

2. Common Config (postcss.config.js)
{
  loader: 'postcss-loader',  options: {}
}

3. Common Config (postcss.config.js) Advanced
{
  loader: 'postcss-loader',  options: { file: 'path/to/postcss.config.js', ctx: {} }
}

@ai These 3 should cover 99,9% of usecases and personal dev preferences

@bebraw Could we ask Tobias to guide someone through the css-loader code base?

Yeah, I'll try to get a little session together. Let's continue on Slack about that.

@michael-ciniawsky OK, let’s add config. But I want a PR for it :).

@ai ok, postcss-load-config seems to need revisited for error handling first (postcss-cli) beforehand + config.file. The latter I have locally working for a while, mainly bc of #66 (Hotreload ´postcss.conig.js) to work, but also for postcss-clinow. When resolved I senf PR withctx option + harmonisedctx (ctx.dir/ctx.ext`), maybe hotreload if that works as expected

@Velenir @bebraw @ai anything left here or can I close? PR for context support is underway 😛

Yeah, let's close. Thanks for the fixes. 👍

@bebraw I have seen the styling-team channel, while I'm uncertain if I can add immediate value to it atm, I will definitely take a look when spare time


App 257 cnab api tests

- What I did
Check mandatory fields in the CNAB bundle for v1.
Added E2E test for running an app generated with an old docker app version.
- Description for the changelog
E2E test for backwards compatibility
- A picture of a cute animal (not mandatory)

Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "app-257_cnab_api_tests" git@github.com:aiordache/app.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842354111120
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.


hvplot.interactive stops working and raises errors

Panel: 0.12.6, Bokeh: 2.2.4, hvplot: 0.7.3, holoviews: 1.14.7
In https://github.com/holoviz/hvplot/issues/695 I noted that hvplot.interactive does not seem to output nicely to a responsive hvplot. I can now see that it does not matter whether responsive or not.
I've attached a reproducible notebook.
As you can see the plot only updates the first time its dragged.
As you can see I can also trigger the exception.
https://user-images.githubusercontent.com/42288570/149610618-ce42e4c2-2053-4b0e-8c3d-c97655cf2006.mp4
The consequence is that hvplot.interactive is not useful currently. Sophia and I are in the process of releasing a blog post on hvplot interactive. I guess it would not make sense to post before this is solved.
Notebook
Rename from .csv to .ipynb.
hvplot_interactive_not_working.csv

I also see this issue. The panel served notebook looks fine. The bug seems to happen in the notebook with the slider.

This can be recreated with:
import hvplot.pandas
import pandas as pd
import panel as pn

df = pd.DataFrame({"a": [0], "b": [0]})
idf = df.interactive()
slider_a = pn.widgets.IntSlider(start=0, end=1)
ipipeline = idf[idf.a == slider_a]
ipipeline.hvplot(by="a")

https://user-images.githubusercontent.com/19758978/156053051-dbb94fe5-3e6a-4cd6-9c4a-9b6172ee246d.mp4


I'd like to see the community board section disassociated from the CD profile

To make clear that that portion is not the view of the NYC Planning

@allthesignals There's a PR for this. Reassigning…


[api-minor] Implement a permissions API

Fixes #9972.
@Snuffleupagus Would you be willing to review this if you have time? I recommend to review this per commit and with the ?w=1 flag. For some reason the ?w=1 flag doesn't seem to work on GitHub for the second commit, but it does locally if you use git show HEAD~1 --ignore-all-space with this branch checked out.

/botio-linux fonttest

/botio-windows fonttest

/botio-linux preview

/botio unittest


flixel 5 & flixel addons 3 fixes & Other things

yoshicrafter renamed the hscript fork
and also I stole code from mayo78, sorry not sorry (that's what you get for blocking me you ass)
and some other adjustments

aweosm!


ci: disable cluster cleanup on test fail

Default ON_FAIL to stop in scripts/e2e-test.sh
Add CLEANUP option to scripts/e2e-test.sh
use it to select desired beahviour for uninstall
test check or cleanup
Add support methods to common/util to
Check that no volume resources exist
Check no test pods exist
invoke those checks in uninstall if cleanup
is not selected.
Refactor uninstall to support
a) check resource leakage and fail immediately
b) check resource leakage, cleanup and fail.

bors try

bors try

bors merge

bors merge

bors merge

bors merge

bors merge

bors merge

bors merge

bors merge

bors merge


vendoring a skypark dependency

I wonder if you could please help me diagnose a problem I am having vendoring a package?
I am building an application that has a skypark dependency for graphql-type-json.
    "graphql-type-json": "https://cdn.skypack.dev/graphql-type-json@0.3.2?dts",

The app builds ok but when running the application against the compiled source, I get this error:

error: Expected a JavaScript or TypeScript module, but identified a Unknown module. Importing these types of modules is currently not supported.
Specifier<EMAIL_ADDRESS>at file:///Users/paulcowan/projects/graphgen/server/.ultra/src/graphql/schema.35f27db4.js:1:72

Looking at the generate importMap.server.json it is creating an entry for graphql-type-json with no file extension:
"graphql-type-json"<EMAIL_ADDRESS>
And looking at the file system, it is generating a file with no file extension:

Looking at the output, it is actually creating files with no .js extension:

Hey @dagda1 thanks for reporting this! I'll investigate, I don't use skypack as I've always had issues with it, so I haven't got a test case for it.

Hey @dagda1 I've now fixed this issue in the latest alpha. If you want to test it in your project, could you add the following line in your importMap imports, to force using the latest version?
"imports": {
<EMAIL_ADDRESS><EMAIL_ADDRESS>}

@deckchairlabs i can confirm this works.  Many thanks!


Post-processing filters removing Depth metadata

Required Info

Camera Model
{ D400 }

Firmware Version
(5.9.11)

Operating System & Version
{Win 10 / Linux (Ubuntu 16)

SDK Version
{ legacy / 2.11.0 }

Issue Description
We have found that using the temporal post-processing filter strips the frame of the depth metadata. This causes a problem with our system as we check the timestamps to verify we have a new one and not a repeated frame. Is this intended functionality? The metadata fields all become 0. We have observed this on both Linux and Windows.

Hello @Jason420Git , the metadata should be preserved.
This is probably a bug and we will look into this.
Thanks for reporting this.

Merged now to the development branch, will be released soon

Should be resolved in 2.14.0


Unmerge Arrays containing Hashes as well

@Blargel, #easy_unmerge fails with the same error as that in https://github.com/Blargel/easy_diff/pull/5. Implemented comparable fix here.

It seems silly that I overlooked unmerge when the merge error was brought up previously now that I think about it...


Make zk connection retries configurable

Description

This makes the zookeeper connection retry count configurable. This is presently hardcoded to 29 tries which ends up taking a long time for the druid node to shutdown in case of ZK connectivity loss.
Having a shorter retry count helps k8s deployments to fail fast. In situations where the underlying k8s node loses network connectivity or is no longer able to talk to zookeeper, failing fast can trigger pod restarts which can then reassign the pod to a healthy k8s node.
Existing behavior is preserved, but users can override this property if needed.

Key changed/added classes in this PR

CuratorConfig

This PR has:

[x] been self-reviewed.
[x] added documentation for new or modified features or behaviors.
[x] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
[x] been tested in a test Druid cluster.

@abhishekagarwal87 We have this currently set to 5 on clusters which prompts a pod restart in ~30 seconds. Maybe we could reduce the default retry count and also keep it configurable for a release or so and then remove the config after that? That gives some time to see if a shorter retry count is leading to any negative impact for other users.

ok. in that case, lets not document the config in docs. You can just add a javadoc in the config class. does that sound good?

@abhishekagarwal87 Sounds good to me. I've made the needed changes


Unable to sign in and create oauth token.

This is what I get when trying to use hub today.
→ hub --version
git version 1.9.2
hub version 1.12.3
github browse
github.com username<EMAIL_ADDRESS>github.com password for<EMAIL_ADDRESS>(never stored):
two-factor authentication code: 385930
/usr/local/bin/hub:680:in `block in fetch_value': no value for key :oauth_token (RuntimeError)
	from /usr/local/bin/hub:678:in `fetch'
	from /usr/local/bin/hub:678:in `fetch_value'
	from /usr/local/bin/hub:778:in `oauth_token'
	from /usr/local/bin/hub:561:in `apply_authentication'
	from /usr/local/bin/hub:600:in `apply_authentication'
	from /usr/local/bin/hub:489:in `perform_request'
	from /usr/local/bin/hub:611:in `perform_request'
	from /usr/local/bin/hub:439:in `get'
	from /usr/local/bin/hub:305:in `block in username_via_auth_dance'
	from /usr/local/bin/hub:764:in `block in username'
	from /usr/local/bin/hub:679:in `block in fetch_value'

+1 Same for me.

:+1:

Sorry, this is a problem with an old version of hub due to GitHub API changes. Please upgrade to either 1.12.4 or, even better, the new 2.2.x series. Thanks

@mislav, brew update; brew upgrade hub is not working. Wondering what's the correct way to upgrade? Thanks.

@randomor What is the result or error message of brew commands you listed? They look correct.

@mislav, it just says Error: hub HEAD already installed I'm guessing the brew recipe is not up to date?

Ah, then please first uninstall hub and then install it again with Homebrew. It's because you've installed the HEAD version before, and Homebrew doesn't know how to brew upgrade it (it's a limitation of Homebrew)

@mislav, that's it! Thanks for the great tool. :100:


Update test to use openblas_make_complex_float and openblas_make_comp…

Update test to use openblas_make_complex_float and openblas_make_complex_double functions

Just out of interest - is this to fix an actual compatibility issue for some platform/compiler, or "just" to improve code quality ?

I was trying to build OpenBLAS with FORCE_OPENBLAS_COMPLEX_STRUCT turned on.
When I did that, the test_potrs.c file would fail to compile because it would use float _Complex and double _Complex even though OpenBLAS was using the struct.
This is why I changed this test to use the openblas_make_complex_float and openblas_make_complex_double functions.


Fixed broken links in README after documentation relocated.

Documentation was relocated from https://matt-cornell.github.io/cobalt-docs to https://cobalt-language.github.io/ - The README has been updated to reflect this.

Thank you for your contribution!


Add Lyceum of the Philippines University

Official University website https://www.lpu.edu.ph/
Office 365 emails of students ends with @lpunetwork.edu.ph

@earlisreal First stage of verification passed, official domain is lpu.edu.ph as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision. Proof of domain ownership: https://manila.lpu.edu.ph/ict/ict-announcement/online-id-application/

@earlisreal Thank you for your patience while waiting for a review and processing your request. Pull request merged.


Search with HumanName

Describe the bug
I read the document about querying with the patient's name,and it said that we can query through family, give, prefix, suffix, suffix, and/or text,but only family and given are implemented in the spark code
https://github.com/FirelyTeam/spark/blob/d1c29b54c8a5eb2c147126c1983151f041a511e2/src/Spark.Engine/Search/ElementIndexer.cs#L439-L454
Is there any special purpose?

Definitely, seems we need to update that index


Add error handling for pipeline if there are not changes to commit

Describe the bug
In the Dataset Pull Automation pipeline (the weekly friday refresh) in gh actions - if there are no changes to commit, the pipeline errors.
To Reproduce
Steps to reproduce the behavior:

Run the pipeline once successfully so all new changes are committed.
Run the pipeline again immediately after and this will result in no new changes to commit.

Expected behavior
Instead of erroring and no slack message being sent, handle this specific error and post to slack "no changes made to dataset listing after refresh" << feel free to modify slack message wording.
Screenshots

Hardware and software used
N/A
Additional context

Closing as duplicate of #5