Support tick on deactivate for ForceLayout

Hello!
Was looking into using the tick function for D3 Force in order to render a static graph at a specific tick similar to the demo here:
https://observablehq.com/@d3/simulation-tick?collection=@d3/d3-force
While taking a look at the library, I saw it has a deactivate function which essentially stops the forceSimulation, was thinking we could add a default null variable that can be set to the tick for a .tick(x) call which would allow the deactivation to be done to a specific tick.
I'm thinking of making a quick MR for this, please let me know what you think!

Hi @adrianlungu,
Thank you for your suggestion!
I have made the necessary modifications to manually specify the d3-force ticks and perform the initial rendering.
v0.9.2
However, I am not confident that this will accomplish what you need. If there are any shortcomings, MR is most welcome!!
The following is an example of how a static graph layout is calculated with d3-force and then switched to the default layout thereafter.
<script setup lang="ts">
import { reactive } from "vue";
import * as vNG from "v-network-graph";
import {
  ForceLayout,
  ForceNodeDatum,
  ForceEdgeDatum,
} from "v-network-graph/lib/force-layout";
import data from "./data"

const defaultConfigs = vNG.defineConfigs({
  view: {
    autoPanAndZoomOnLoad: "fit-content",
    layoutHandler: new ForceLayout({
      createSimulation: (d3, nodes, edges) => {
        const forceLink = d3
          .forceLink<ForceNodeDatum, ForceEdgeDatum>(edges)
          .id((d: ForceNodeDatum) => d.id);
        return d3
          .forceSimulation(nodes)
          .force("edge", forceLink.distance(150).strength(1))
          .force("charge", d3.forceManyBody().strength(-1000))
          .force("x", d3.forceX())
          .force("y", d3.forceY())
          .stop() // tick manually
          .tick(100);
      },
    }),
  },
  node: {
    label: {
      visible: false,
    },
  },
});
const configs = reactive(defaultConfigs);

const eventHandlers: vNG.EventHandlers = {
  "view:load": () => {
    // Switch to default layout handler after initial layout calculation.
    configs.view.layoutHandler = new vNG.SimpleLayout();
  },
};
</script>

<template>
  <v-network-graph
    :nodes="data.nodes"
    :edges="data.edges"
    :configs="configs"
    :event-handlers="eventHandlers"
  />
</template>

<style lang="scss" scoped>
.v-network-graph {
  width: 600px;
  height: 400px;
  border: 1px solid #aaa;
}
</style>

// data.ts
import { Nodes, Edges } from "v-network-graph"

const nodes: Nodes = {
  node0: {},
  node1: {},
  node2: {},
  node3: {},
  node4: {},
  node5: {},
  node6: {},
  node7: {},
  node8: {},
  node9: {},
  node10: {},
  node11: {},
  node12: {},
  node13: {},
  node14: {},
  node15: {},
  node16: {},
  node17: {},
  node18: {},
  node19: {},
}

const edges: Edges = {
  "edge0-5": { source: "node0", target: "node5" },
  "edge1-0": { source: "node1", target: "node0" },
  "edge2-0": { source: "node2", target: "node0" },
  "edge3-0": { source: "node3", target: "node0" },
  "edge4-0": { source: "node4", target: "node0" },
  "edge5-10": { source: "node5", target: "node10" },
  "edge6-5": { source: "node6", target: "node5" },
  "edge7-5": { source: "node7", target: "node5" },
  "edge8-5": { source: "node8", target: "node5" },
  "edge9-5": { source: "node9", target: "node5" },
  "edge10-15": { source: "node10", target: "node15" },
  "edge11-10": { source: "node11", target: "node10" },
  "edge12-10": { source: "node12", target: "node10" },
  "edge13-10": { source: "node13", target: "node10" },
  "edge14-10": { source: "node14", target: "node10" },
  "edge15-0": { source: "node15", target: "node0" },
  "edge16-15": { source: "node16", target: "node15" },
  "edge17-15": { source: "node17", target: "node15" },
  "edge18-15": { source: "node18", target: "node15" },
  "edge19-15": { source: "node19", target: "node15" },
}

export default {
  nodes,
  edges,
}

Awesome! I'll give it a shot very soon! Thanks @dash14

You're right, I was not able to get it to work as expected.
Trying to rebuild the demo from d3-force and changing the tick via some kind of input yielded various interesting results.
I was able to get something up and running by doing the following changes
This allows me to call
  'view:pan': () => {
    forceLayout.ticked(300)
  },

and even change the tick by calling ticked afterwards with other values, although it does not behave exactly like the d3-force demo for some reason.
I also couldn't get it to load properly in the view:load event on my end, not sure why though.
What do you think ? Should I make a MR although I'm not confident that my changes are the best implementation for this.

Awesome, thanks for the update @dash14
I'm still getting a few weird artifacts on my end, not sure why though, I'll try to build a vue component to extract the logic I'm using and have a demo up and running.
It also seems that once I reset the nodes using layouts.value = { nodes: {} } the actual nodes disappear from the graph on my end. 🤔
The rest seems to be working as expected!

I am still unable to reproduce the problem on my end.
It has been a long time, but if you are still suffering from the same problem, I would appreciate it if you could provide me with the minimal code where the problem occurs, so that I can analyze the problem.
Best regards

Hey @dash14 ,
Been caught with other stuff lately, I'll try to setup a demo asap

I tried to reproduce the issue that I'm having locally in another environment but it seems that I can't get it to work exactly as it does in the project I'm using it when isolating just the v-network-graph, so there may be more to it than this.
Using nextTick does solve the issue I'm having so, if I manage to identify the root cause, I'll update this ticket or open a new one, but for now I think we can close this one as the updates you've done already improved the behavior alot.
Thanks again @dash14 !


Missing QEMU image file in AGL configuration

Hi @jwinarske
The current configuration file for the AGL QEMU (master and octopus) environment references a file that no longer exists.

Missing file: qemux86-64/agl-ivi-demo-platform-flutter-qemux86-64.wic.vmdk.xz
Referenced in:"artifacts": {
  "http": {
    "url": "https://download.automotivelinux.org/AGL/release/${RELEASE_NAME}/${RELEASE_VERSION}",
    "artifacts": {
      "x86_64": [
        {
          "endpoint": "/qemux86-64/deploy/images/qemux86-64/agl-ivi-demo-platform-flutter-qemux86-64.wic.vmdk.xz"
        }
      ],
      // ...
    }
  }
}

Is it possible that the file agl-ivi-demo-flutter-qemux86-64.wic.vmdk.xz is the intended replacement for the missing file?
https://download.automotivelinux.org/AGL/snapshots/ricefish/latest/qemux86-64/deploy/images/qemux86-64/
Thanks again!

Please use downstream configs found in meta-agl-flutter as I indicated in other issue.  These configs here are for reference only; they were created here, with no intent to maintain.
flutter_workspace.py (implementation) is independent of the data (configs).

This config will be merged to meta-flutter-agl end of week:
https://github.com/meta-flutter/workspace-automation/blob/jw/ricefish_18.0.0/configs/agl-qemu-ricefish-18.0.0.json


time_switch_clock

first steps in javascript - maybe the adapter can be included in the beta repository.

RE-CHECK!

Automated adapter checker
ioBroker.time_switch_clock

:thumbsup: No errors found

[ ] :eyes: [W400] Cannot find "time_switch_clock" in latest repository

Add comment "RE-CHECK!" to start check anew

A short review.

Please sort in your adapter alphabetically. Currently, it is just added at the bottom of the JSON file.
you might want to remove the deprecated unit test.
In io-package.json you define a local link https://github.com/XSDiVer/ioBroker.time_switch_clock/blob/main/io-package.json#L146 -> but it seems to just link to the local vis edit. Is that correct? If so, then I think that should be removed. It should be sufficient that the vis-adapter contains this link. Distributing this link to other adapters will make it hard, if this link is once to be changed. Also, is it not possible to use this adapter with a different visualization adapter? (also, there is neither a dependency on vis nor on web...)
Please remove the info.connection state (and info channel) from your io-package.json and your adapter-code. They are only meant to indicate a connection to an out-world server / device which is not what your adapter does.
You add an object Setup.number_of_triggers. Please also add Setup as channel or folder (similar to the info channel from above).
You don't process object changes, please remove the handler (here and here)
Similar to the Setup-channel there are neither channels / folders for Weekday and trigger_1 to trigger_6 created.
Why do you check the time here? Just cancel the timeout (i.e. make sure that it does not run, for example in compact mode!).

Regarding your code... There is a LOT of code duplication. Feel free to ask in the starter-telegram group or somewhere else on how to reduce that... But, I guess this is optional for the time being.
Note to other reviewers: There is a widgets folder and contents seem sensible to me, but I have no experience with widgets.

@XSDiVer Ready for a re-review?

@XSDiVer Next time please do a post when ready ... emote reactions are not notified as email :-)
Here my review comments:

please remove the localLink, as @Garfonso already told you because it is "just" open the vis ... This is not needed. Vis has its own link
Your adapter contains a widget so you should add a common.restartAdapters['vis'] to io-package to make sure the new plugin gets seen by vis
async here (example, maybe more such plavces!) not needed because no await is used https://github.com/XSDiVer/ioBroker.time_switch_clock/blob/main/main.js#L1118
state changes should only ne processed as commands when ack-flag is set to false ... Please add this check
when using a *Async method you should also use "await "... OR remove the Async from the method name. Otherwise can end in crashes

I did not really checked all code because yes, much duplicated ... ;-)
Thank you for checking and adjusting

@XSDiVer Is there anything we can help with?

@XSDiVer Is there anything we can help with?

Hello Apollon,
in the moment I have not the time to fix the Adapter, but I tink in the near future I will go forward.
If anyone wants to remove the code duplcations or is interessted to develop the Adapter together with me,
feel free to contact me :o)
If I need some help (and I am sure I need) I contact you in our Telegram Channel 👍

the code duplications are no blocker for repo btw (they hjust make a proper review a bit harder)

Happy new year,any update?

@XSDiVer How we should continue?

Please remove node 14 from test-and-release.yml and (optionally) add node 20 to testing matrix.
Node 14 is no longer supported and tests will fail since 22.5.2023.
Thanks
McM1957

Please remove node 14 from test-and-release.yml and (optionally) add node 20 to testing matrix. Node 14 is no longer supported and tests will fail since 22.5.2023.
Thanks McM1957

Done...

@XSDiVer How we should continue?

If I had more time I would start the whole thing all over again. But it's a little tricky at the moment.

RE-CHECK!

Automated adapter checker
ioBroker.time_switch_clock

[ ] :heavy_exclamation_mark: [E518] "@alcalzone/release-script" is used, but ".releaseconfig.json" not found
[ ] :eyes: [W105] "common.titleLang" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W109] "common.desc" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)
[ ] :eyes: [W400] Cannot find "time_switch_clock" in latest repository

Add comment "RE-CHECK!" to start check anew

RE-CHECK!

Automated adapter checker
ioBroker.time_switch_clock

* [ ]  ❗ [E518] "@alcalzone/release-script" is used, but ".releaseconfig.json" not found

* [ ]  👀 [W105] "common.titleLang" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

* [ ]  👀 [W109] "common.desc" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

* [ ]  👀 [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

* [ ]  👀 [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

* [ ]  👀 [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

* [ ]  👀 [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

* [ ]  👀 [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

* [ ]  👀 [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

* [ ]  👀 [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

* [ ]  👀 [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, uk, zh-cn)

* [ ]  👀 [W400] Cannot find "time_switch_clock" in latest repository

Add comment "RE-CHECK!" to start check anew

RE-CHECK!

RE-CHECK!

@XSDiVer
First of all - THANK YOU for the time and effort you spend to maintain this adapter.
After a long time I checked this old PR again. According to github you did some further work on the adapter -although the last release is from Aigust 2022. If you are still interested in listing the adapter at repos, I will try to get the re-review done within a few days after you gave feedback to the small number of current issues (see below).
This is NOT an offical review and @Apollon77 might have several additional suggestions or even a different oppinion to one or the other statement. Please feel free to contact him (or wait for a response from him) if you cannot follow my suggestions or want to discuss some special aspects.

[ ] package.json must specifiy required nodejs version
Please consioder adding en engines clause to package.json. Especially if you use adapter-core 3.x.x or newer nodegs 16 or newer must be reuested:
  "engines": {
  "node": ">= 16"
},

[ ] please verify that all dependencies are up to date
Several plugins for alcalcone/releasescript are missing.

[ ] log messages should be english
All log messages (adapter.log.xxx /this.log.xxx) should be english. Some of your messages are german, please translate.
If really desired, messages could use multiple languages - but this is strongly discoured as support might be complicated. Could you read an chinese error log?

[ ] onStateChange handler ignores ack flag
The adapter must honor the ack flag when processing onStateChange events resulting from users changing the adapters state. Whenever the onStateChange handler is called for an own state (a state owned by the processing instance of the adapter) it must ignore this event if the ack flags is set. Only stateChanges with ack==false are allowed to be processed.
If the adapter subsribes to own states and wants to react whenever the adapter writes to its own state reacting on ack is ok.
When processing foreign states which are output of another adapter  processing must only occure if the ack flag is true.
REacting on special states (0_userdata_0, alias, javascript) ack might be ignored as prefered by you as many users do not understand ackusage.

[ ] reevaluate state roles
Only the values specified here (https://github.com/ioBroker/ioBroker.docs/blob/master/docs/en/dev/stateroles.md) may be used as state roles. Do not invent new names as this might disturb the functionalyity of other adapters or vis.
In addition the roles MUST match the read/write functionality. As an example a role value.* requires that the state is a readable state. Input states (write only) should have roles like level.*. Please read the description carefully. States with role 'button' should (must) have attribute 'common.read=false' set. A button ( "Taster" in german only triggers when you press but else has no state), so it should also be not readable. This is also like HomeMatic does it. A switch has clear states true or false and so can be read.
Please avoid using general roles (state, value) whnever a dedicated role exists.

[ ] some labels seem to have no translation into all languages
It seems that some labels are not translated into all supported languages, i.e. ...
Please consider adding missing translations

[ ] Is there any reason to not use i18n translation environment?
I suggest to evaluate to use i18n translation environment and the iobroker/adapter-dev environment (https://github.com/ioBroker/adapter-dev#iobroker-adapter-dev). You could easyly add new strings to the english json and run npm run translate afterward. When using i18n environment activating iobrokers weblate translation system (see https://github.com/ioBrokerTranslator/doc) is trivial.

[ ] consider using adapter.setTimeout / this.setTimeout instead of (standard) setTimeout
The adapter package provides wrapper routines for native setTimeout, setInterval, clearTimeout and clearInterval. Using those routines ensures that timers are cancelled on on load. Additional checks on thomse limits might be performed, too. So consider replacing native setTimeout/clearTimeout by adapter.setTimeout/adapter.clearTimeout or this.setTimeout/this.clearTimeout. The same refers to setInterval/clearInterval.
You already use this.setTimout, but not everywhere, i.e. https://github.com/XSDiVer/ioBroker.time_switch_clock/blob/445139370205031a3c2ca0d4d0b155fce8956799/main.js#L912

[ ] all Timers / Intervalls must be canceled at onUnload
All timers / intervallls must be cancelled at onUnlad. This is required as otherwise the timer could be fired when using compact mode after unloading the stopped adpater which will crah the compact process afterwards.
see as an exaple https://github.com/XSDiVer/ioBroker.time_switch_clock/blob/445139370205031a3c2ca0d4d0b155fce8956799/main.js#L912

Thanks for reading and evaluating this suggestions.
McM1957
Please add a comment when you have reviewed and fixed the suggestionsor at least commented the suggestions and you think the adapter is ready for a re-review!

Hello McM1957,
Thank you for your kind words and for taking the time to review the adapter. I truly appreciate your efforts and dedication to the ioBroker community.
I've carefully considered your suggestions and feedback. While I value the improvements you've highlighted, I regret to inform you that, due to current time constraints, I am unable to address these issues promptly.
I understand the importance of maintaining and updating the adapter, and I am grateful for your detailed insights. If you or @Apollon77 have any urgent concerns or specific questions that require immediate attention, please feel free to reach out to me, and I'll do my best to assist as time allows.
I want to express my gratitude for your understanding and patience. I will certainly plan to revisit and address these suggestions when my schedule permits.
Thank you once again for your support and valuable input.
Best regards,
XSDiVer


fix: allow highlighting within code wells on doc site

Description
Code wells were not allowing highlighting which made copying code from them rather annoying. Removed the code that did this. Not sure why this was in there in the first place, doesn't make much sense.

Unrelated change: https://github.com/dialpad/dialtone/pull/504/files#diff-84eea9b6753b9c80d5de7859df92589a68bb68d0704a86a88a162e6a0f3a20afR49
it should be inherit


[Bug]: Backups causing crash

Contact Details
No response
What happened?
Turned on the backups option last night, leaving all of the variables as default. Woke up this morning to the docker container stopped and the logs showing the below. Let me know if you want me to re-create with different log level.
Version
0.1.0
What browser did you experience the the problem on?
No response
What operating system are you using?
Docker
Relevant log output
2024-06-12T08:00:09.262Z [error]: Error creating backup
    err: {
      "type": "Error",
      "message": "EIO: i/o error, scandir '//sys/kernel/slab'",
      "stack":
          Error: EIO: i/o error, scandir '//sys/kernel/slab'
      "errno": -5,
      "code": "EIO",
      "syscall": "scandir",
      "path": "//sys/kernel/slab"
    }

Can you share your backup config? it is in the settings.json file

Settings.json Backup config...
{"backup":{"configurations":[{"enabled":true,"schedule":{"type":"every","increment":1,"unit":"day","offsetMs":10800000},"outputs":[{"type":"file","outputPath":"","archiveFormat":"tar","maxBackups":3}]}]}
Same output on with Debug logging on.
2024-06-12T14:33:46.374Z [error]: Error creating backup
err: {
"type": "Error",
"message": "EIO: i/o error, scandir '//sys/kernel/slab'",
"stack":
Error: EIO: i/o error, scandir '//sys/kernel/slab'
"errno": -5,
"code": "EIO",
"syscall": "scandir",
"path": "//sys/kernel/slab"
}

Cool, thanks for posting. I guess the default empty path is causing some issues on Unraid. Either that, or there is an issue dealing with the temporary directory (where Tunarr works on the backup) within the Unraid container. Based on the log message though, I think it is the former.
Can you try setting the output path to a path within your container and see if the issue persists?

Ah wait a minute, if there are truly no other logs, then this might be happening sooner in the backup than I thought and could actually be a tmpdir issue... but I would still expect something else in the logs around here or here

Adding a directory path, allows it to create a backup successfully.

Interesting. I'll do some testing. We may have to forcefully resolve the empty path relative to the process's cwd

Sounds good. Agreed.

Weirdly, I thought this was the default. Node CLI seems to show the same...
) ✗ node
Welcome to Node.js v20.11.1.
Type ".help" for more information.
> const path = require('node:path')
undefined
> path.resolve("")
'/home/christian/Code/tunarr'
> process.cwd()
'/home/christian/Code/tunarr'
>

Within a container -- this doesn't look quite right. We should probably try and use the default config directory if we detect we're running in a container:
) ✗ docker run --rm -it --name tunarr --entrypoint /bin/bash chrisbenincasa/tunarr:latest
root@8a554d4bfdc4:/# node
Welcome to Node.js v20.14.0.
Type ".help" for more information.
> const path = require('node:path')
undefined
> path.resolve("")
'/'
> path.resolve(process.cwd())
'/'

Interestingly the default settings in a fresh container seem to work for me:
2024-06-12T17:11:34.643Z [info] <>: Writing backup to /tunarr-backup-20240612_171134.tar
2024-06-12T17:11:38.231Z [info]: Successfully generated backup to /tunarr-backup-20240612_171134.tar
2024-06-12T17:11:38.231Z [info]: Task BackupTask ran in 3598.45 ms

with the backup generated:
root@f45432afe826:/# ls -la /tunarr*
-rw-r--r-- 1 root root 266752 Jun 12 17:11 /tunarr-backup-20240612_171134.tar

Perhaps this is something Unraid specific with how the root directory works in containers

This could potentially be due to a misconfigured PUID/PGID in the Docker container (which I just pushed out a fix for for the Unraid template, should be live in an hour). Previously, it was accidentally set to use 1001:1001 for file permissions. Now it should use 099:100 (nobody:users), which is the default for the Unraid file system.

I made the change to PUID/PGID on my container and reset the backup settings. That seems to still trigger the same error as above.
If I assign an Output Path of "/backups" in Tunarr. The logs show it successfully creating a backup to "/tmp/tunarr-backup-XXXXXXHuQzWR".
Can we have a variable in the Unraid Template for the backup output path that is mapped to a backup folder in the config?

Ah, I think I see the problem. The template for Unraid only maps /tunarr/server/build/.tunarr rather than just the root /tunarr directory, so anything written above that directory in the app doesn't make it to the host file system. That's my bad. @chrisbenincasa if you can confirm that mapping /tunarr from the container to the host would cover all permanent data storage, I can change the template real quick.

Maybe we should mount /config instead? Or both? I can't think of immediate harm of mounting /tunarr, but fwiw there is code already that attempts to detect a container runtime and chooses /config as the default output for logs. Perhaps we could do the same by default for backups in a container. And in the future, maybe even the DB directory should be under that path (in containers).
At the end of the day the backup path is configurable in the UI but we should try to provide a sane default. I think for containers that's generally thought to be /config. But I'm open to discussion

Addressed the default empty path in docker here: https://github.com/chrisbenincasa/tunarr/pull/530
After that PR, an empty backup path within a docker container will write backups to /config/tunarr/backups

I have added /config/tunarr/backups as a mappable path in the Unraid template.

Thanks!

Just pulled the changes from this weekend and I'm not seeing this path addition to the Unread template. Maybe I am missing something?

Just pulled the changes from this weekend and I'm not seeing this path addition to the Unread template. Maybe I am missing something?

The template only updates if you delete and re-add the app via the CA store (and specifically skip using the cached template in your system). This is independent of "updating" the template due to a new Docker image being available.

Appreciate that. Didn’t know that.

Rebuilt my container with the updated template. Mapped directories accordingly. Set the backup path two different times in Tunarr as both blank and as the default path typed out "/config/tunarr/backups". I am successfully saving a backup file but each time the container also crashes right after. Below debug log...
2024-06-17T18:22:39.114Z [debug] <>: Added entry to backup: channel-lineups/fef02f92-bef2-461f-944a-a31029b8b238.json
2024-06-17T18:22:43.431Z [error]: Error creating backup
err: {
"type": "Error",
"message": "EIO: i/o error, scandir '//sys/kernel/slab'",
"stack":
Error: EIO: i/o error, scandir '//sys/kernel/slab'
"errno": -5,
"code": "EIO",
"syscall": "scandir",
"path": "//sys/kernel/slab"
}
2024-06-17T18:22:43.434Z [info]: Task BackupTask ran in 5303.83 ms
Also getting a random crash on startup that seems new without any errors in the logs. Happens after this line...
2024-06-17T18:28:47.248Z [debug]: Push event: Started building tv-guide at = 2024-06-17T13:28:47-05:00
Can open new bug reports for each of these if preferred.

Hmmm yea, really not sure what's up there. Happy to look into it more with full logs. You can open a separate issue (ro Q&A discussion) for the other failure too.


propTypes validation on data causes performance issue

Because of the propTypes defined on data, when dealing with multiple graphs of +180 ticks, you start to get a serious lag and browser hanging because of prop types validation

Thanks for the report. I'm not willing to give up propTypes validation outright but if you have a suggested fix, I'd love to see a PR. In any case this issue impacts dev workflows only, since propTypes checks are generally not used in production.

A good compromise here might be to use a custom validation function in place of (the outermost) React.propTypes.arrayOf, so that we'll always inspect an O(1) sample of the data array, rather than all elements. That way we'll still guard against major errors and ensure that the user at least appears to know what they're doing.

I faced a similar performance hit when in developing environment.

@pgruenbacher
https://github.com/Infinidat/react-dygraphs/commit/ef501e18f36271a9a6c51ceb94d62a5b60c72cd7
published as infinidat-react-dygraphs


Ignore non-integer ranges in Style/RandomWithOffset

This cop only works correctly for ranges with literal integer bounds.

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

The previous behaviour was a crash, so I don't think marking as unsafe will cut it:
$ rubocop _0.91.0_ --debug --only Style/RandomWithOffset --stdin foo.rb <<< "rand(0..limit) + 1"
For /Users/eugene/test: Default configuration from /Users/eugene/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/rubocop-0.91.0/config/default.yml
Inspecting 1 file
Scanning /Users/eugene/test/foo.rb
An error occurred while Style/RandomWithOffset cop was inspecting /Users/eugene/test/foo.rb:1:0.
undefined method `+' for nil:NilClass
/Users/eugene/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/rubocop-0.91.0/lib/rubocop/cop/style/random_with_offset.rb:112:in `block in corrected_rand_op_integer'
/Users/eugene/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/rubocop-0.91.0/lib/rubocop/cop/style/random_with_offset.rb:95:in `random_call'
/Users/eugene/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/rubocop-0.91.0/lib/rubocop/cop/style/random_with_offset.rb:105:in `corrected_rand_op_integer'
/Users/eugene/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/rubocop-0.91.0/lib/rubocop/cop/style/random_with_offset.rb:83:in `autocorrect'
/Users/eugene/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/rubocop-0.91.0/lib/rubocop/cop/style/random_with_offset.rb:68:in `block in on_send'

This happens because the range bounds are assumed to be integer literals here later:
https://github.com/rubocop-hq/rubocop/blob/760d98ba562de63f66cfd789b77d065faf9e664f/lib/rubocop/cop/style/random_with_offset.rb#L147-L149
It might be possible to extend the cop to accept non-integer bounds (perhaps unsafely), but I think that can be a followup.

Cool, thanks!


Use gateway id instead of name in API_GW_RESTRICTED rules

I confirm these files are made available under CC0 1.0 Universal (https://creativecommons.org/publicdomain/zero/1.0/legalcode)
Issue #, if available:
#342
Description of changes:
Use gateway id instead of name in API_GW_RESTRICTED rules

@rickychau2780 up for a review?

@chrgut @jschwarzwalder does it look alright?


[#1003] Apply basic auth on staging environment

Closes #1003.
This pull request addresses Issue #1003, focusing on setting up basic authentication for the staging environment. The implementation of basic authentication is crucial to control access to the staging environment and ensure that only authorized users can access it.
The changes in this pull request involve setting up environment variables for different environments (dev, test, and staging) to enable distinct configurations. Specifically, modifications were made to the .envrc file to define environment variables based on the selected environment, and adjustments were applied to the config.mk file to generate the necessary nginx authentication file tailored to the chosen environment. These changes improve the security of the staging environment by enforcing basic authentication for access control.

credentials updated on https://bw.binarapps.com/#/organizations/7a607653-09a5-432b-9783-809494c16cbe/vault


Change return type code action suggested for stdlib function call expression

Description:
Case 1

For the diagnostic depicted above, the code action change return type to int|error` is suggested as a quick fix.However, when I accepted the quick fix any text edit was not performed. We shouldn't suggest the above code action in this case as this was a function/method def from a stdlib/external lib.
Case 2
Further, in this case there are few missing code actions/quick fixes.

Add check code action
Change variable type code action

Case 3
When I removed the select clause, any code action was not suggested.

Steps to reproduce:
type MedalStats record {
    int rank;
    string country;
    int gold;
    int silver;
    int bronze;
    int totalMedals;
};

function getMedalStats() returns stream<MedalStats, error?>|error {
    int abc;
    string cd;
    int[] myArr;
    string zzz;
    stream<string[], io:Error?>|error tsvStream = readTsvAsStream("/data/Medals.tsv");
    if  tsvStream is stream<string[], io:Error?> {
        return stream from var entry in tsvStream
        where entry.length() == 7
        where int:fromString(entry[0]) is int
        let int rank = int:fromString(entry[0])
        select

    }
}

Case 4
function findTop10MedalWinners() returns error? {
    string[]|error countries = from var stats in getMedalStats() select
}

Add check code action is not suggested for getMedalStas() method call.  Instead type guard code action is suggested.
Affected Versions:
slbeat5-snapshot

Fixed with #33971


monodepth weird results

Hello @yan99033  and thank you for sharing this usefull repo.
I am working on a depth estimation project. I searched a lot an found your amazing repo.
I built tensorflow from source and can ran your code on my local systems successfully.
Systen information :
OS : ubutnu 18.04 LTS
Tensorflow version : 1.15.0
Protobuf  version : 3.8.0
Bazel : 0.25.0
OpenCV : 4.3.0
Used model  : model_city2kitti.pb
Testing dataset : kitti dataset
When i run the inference_monodepth on my command  , i have this picture as result :

The result is disappointing and i dont know why i have this result.
What i can to do to solve this problem ?
Thanks in advance.

I am almost certain that this has to do with the invalid access to the memory buffer.
Can you just visualize the imshow the  depth_visual variable? Just want to make sure that the error doesn't occur in the image stacking.

@yan99033  thank you so much for your answer .
I visualized the depth_visual and have this result :

Seems the program is working well and i have the true output . thank you so much for your solution.
Is my previous problem due to opencv issue ?

It might be due to the difference in opencv version.
Try to change
depthmap_visual.convertTo(depthmap_visual, CV_8U);
to
depthmap_visual.convertTo(depthmap_visual, CV_8UC3);
Normally when you do applyColorMap(), it should give you 3 channels. I suspect that's the problem.

It might be due to the difference in opencv version.
Try to change
depthmap_visual.convertTo(depthmap_visual, CV_8U);
to
depthmap_visual.convertTo(depthmap_visual, CV_8UC3);
Normally when you do applyColorMap(), it should give you 3 channels. I suspect that's the problem.

@yan99033  Thank you
I did depthmap_visual.convertTo(depthmap_visual, CV_8UC3); but no thing changed.
I have the old issue yet. I think like you the problem is in opencv version.

@yan99033  i resized depthmap_visual to image size and the problem is solved.
Now the code is working very well.


[FLOC-2158] Remove Fedora 20 install instructions from the GSG

Fixes https://clusterhq.atlassian.net/browse/FLOC-2158
This also fixes https://clusterhq.atlassian.net/browse/FLOC-1309 by removing the last untested OS in the GSG.

OK to merge.


Incorrect state in link tracing: ERROR in one stage but whole stage link tracing shows SUCCESS

Please answer these questions before submitting your issue.

Why do you submit this issue?
[ ] Bug

Bug

Which version of SkyWalking, OS and JRE?

OS: CentOs 7.5
JDK: jdk8u 241
SkyWalking: 6.6.0-es7

Which company or project?

What happen?

when searching the trace link with the endpoint of the facade which state is SUCCESS,  I found that there is an error in this link, so the final state should be ERROR, I am a little confused about this.

Requirement or improvement

trace link should be set as state of ERROR within this condition;
better if skywalking could print out the ERROR Jstack

What is error jstack? What is related to SkyWalking?

What is error jstack? What is related to SkyWalking?

I mean, the threaddump of the error, nevermind, It is a good to have function, the main problem is the misstate in link tracing result

@Fine08finCould you take a look how the UI visualize the error status?

CC

@regardfs Now, UI according to isError from server data to visualize trace list. I didn't find this error case. Could you check if your data that isError is true but logs are errors is dirty? cc: @wu-sheng

@regardfs If you could the trace query result(Graphql response), it would be helpful to identify the issue.

Probably there is another possibility that @regardfs  misunderstand the trace table. Now the trace table doesn't show error status,  like trace list. If it's necessary, I can add this. @wu-sheng

Oh, I think that is the case, let's add it in 8.1.0


Error while running the built docker image

Describe the bug

Downloaded the beta release source and build the docker image. While running the image, got the syntax error.
Expected behaviour

Expected to run the docker image smoothly
Environment

Version: Beta Version 2.0.0
Platform: Web App
OS: Windows
Browser: chrome

To Reproduce

docker build -t owasp-threat-dragon:dev .
docker run -it --rm -p 8000:3000 -v %CD%/.env:/app/.env owasp-threat-dragon:dev
Got the error
td.server/index.js: line 1: syntax error: unexpected "("

Any additional context, screenshots, etc

Thanks @vineetpandey , the bug is much appreciated. If you have a fix then that would be great

OK, thanks @vineetpandey
It works OK on my MacOS - I can will it on my Linux and my Windows machines later this week

Great @jgadsden .
If that works for windows. Please state away the steps as well please. Thanks!

Was this beta published on docker hub as well?
I was checking it but couldn't find on docker hub. Though I'll give a try. Thanks for the information @jgadsden

@jgadsden looks like this docker image is working fine. Though I'll check it thoroughly tomorrow. Thanks for this.

@jgadsden : now able to run from docker image but another trouble came up while returning the oauth code.
Below are the environment variables passed in .env file:
GITHUB_CLIENT_ID=Iv.1854ce0c2e723a
GITHUB_CLIENT_SECRET=esdf3423432423463453rfwe
GITHUB_SCOPE=repo
NODE_ENV=development
SERVER_API_PROTOCOL=http
ENCRYPTION_KEYS='[{"isPrimary": true, "id": 0, "value": "sdfsdfs4erw45345345"}]'
ENCRYPTION_JWT_SIGNING_KEY=sdfsdfs4erw45345345
ENCRYPTION_JWT_REFRESH_SIGNING_KEY=sdfsf5434r4fd4erf34dre34
And, this is the error while clicking on "Login with Github"

Hello @vineetpandey
If you are running these commands:
docker pull threatdragon/owasp-threat-dragon:v2.0.0-beta
docker run -it --rm -p 8080:3000 -v %CD%/.env:/app/.env threatdragon/owasp-threat-dragon:v2.0.0-beta

then you are mapping for port 8080 on your localhost, so you should try http://localhost:8080/#/
The backend Express server is listening on port 3000 for requests from the Vue application front end or from the browser - but these requests are mapped to port 8080

Hi @jgadsden : yes, I ran this URL only: http://localhost:8080/#/
while clicking on "Login with Github", let me authorize and throwing the error as shown in the image attached in my last comment. Not sure what to do, since my Github app configuration is:
HomePage URL: http://localhost:8080
Callback URL: http://localhost:3000/api/oauth/return
Also, I gave my discord webhook as well.

Hi @jgadsden : had a chance to look into the above error??
Thanks!

Hello @vineetpandey sorry for the delay - been busy times
can you check your dotenv value for SERVER_API_PROTOCOL? If it is https then this will fail because the certificates are (probably) not in place

Hello @vineetpandey , I think I need to create a step by step guide to running the docker image locally, and that should show any errors. I can put the step by step guide onto the documentation site

Hello @vineetpandey I have created instructions for github access, which include running the docker image locally, in the documentation pull request

@jgadsden thanks for this.
One more query, can we also run this in gitlab. If yes, then can you also include the step-by-step instructions for gitlab deployment since gitlab is popular alike GitHub and gives you the feasibility to host it on-premise which large organisations do prefer.


Add resolved IP of http-probes' targets into a label

In short I am probosing to add a label that informs the user to which ip a hostname was resolved. This helps to debug unstable DNS-configs or problems related to DNS-load-balancing.
Usecase:
Imagine you use DNS load balancing and than thanks to your cloudprober metrics you get a warning that something is wrong.
However, it just tells you https://example.net/awesome-api is down. However, that url resolves to different deployments depending on origin of the request and/or load-situation.  So, now you just know that at least one deployment is broken but not which one... This already helps but it would be even better to know to which deployment (in other words to which ip) the request that failed actually went.
Details/additional notes:
In request.go line 112 that information is already present.  If my understanding of the source-code is correct the url_host variable contains the target's ip which was retrieved from dns.   It is however only internally available and at least I found no option to configure cloudprober to just save that data as a value to a label.
I would recommend to add an option to http-probes which allows this.
I furthermore want to add that enabling this feature might lead to a potentially huge amount of metrics in case the hostname tested resolves to a new ip on each request. From my experience this is very unlikely but I still want to point it out.

Thanks for filing a detailed enhancement request, @momoXD007. I think it makes sense. I want to give it more thought though.
If we do it, I think it will make sense to do it through additional labels.

Actually, now I remember that I had thought about some thing similar sometime back.
The right way to do this will be to store IP address in the endpoint.Endpoint struct and update it when we resolve it. It will then be easy to add IP to labels. It will take multiple changes to do this cleanly. I'll update this issue with a plan.

making this feature optional sounds like a good plan to me!
Thanks for considering my request :)

Possible implemetation: https://github.com/cloudprober/cloudprober/pull/82.

#82 has been merged. It will go out in the next release.

Closing this now. Please see #82 for how IP label can be added to the metrics.


gltf version

Hello,
Can it be made more clear which version of gltf 1.0 or 2.0 this tutorial targets? If both, does it consistently point out the differences when they arise?
Thank you!

The tutorial targets version 2.0 only (but it's true that this is not mentioned explicitly...)
A (very technical) list of the differences between 1.0 and 2.0 is contained in https://github.com/KhronosGroup/glTF/issues/605 , but it would be hard to understand this without a lot of background knowledge about the spec. Some of them are on a low technical level, e.g. the change from using "dictionaries" in 1.0 to using arrays in 2.0. We considered creating some "1.0-to-2.0 change log" from issue 605 - and in fact, this was assigned to me, if I "... have the bandwidth." - but until now, there didn't seem to be so much demand for that: Most people either adapted 2.0, or started using glTF with version 2.0 altogether...
On a higher level:
Most of the concepts have remained the same between 1.0 and 2.0. The largest conceptual difference refers to the material handling: Version 2.0 uses the PBR materials. In 1.0, the materials had been described with shader programs that had been contained in the assets (which brought some complexity, and possible portability issues)
Pointing out the differences between 1.0 and 2.0 in the tutorial could be difficult (and potentially confusing). A dedicated "mini-tutorial" about the way how materials had been handled in 1.0 could make sense.
Do you have a particular interest in the comparison of 1.0 and 2.0?

It also seems to me after some inspection that the phrase "gltf2" is a community created term, and not an official Khronos term. So, I suppose maybe the tutorial should clear up some naming issues about how to identify gltf with respect to its version.

I'm not entirely sure what you mean: I think that (unfortunately) the only way to determine the glTF version of an asset (when it is given as JSON) is to parse it, and then look at the version number. (Been there, done this, in https://github.com/javagl/JglTF/blob/82bb96b0064732436fdc9e771bdbe717a2b8d8f2/jgltf-model/src/main/java/de/javagl/jgltf/model/io/GltfReader.java#L130 ... not so much a problem for the "untyped JavaScript world", though...).
However, it could indeed be made clear(er) that the tutorial is about glTF 2.0....

I guess what I mean is that unless I already fully understood the glTF 1.0 and glTF 2.0 specification and differences therein, I wouldn't realize which version the tutorial was targetting in its explanation since it wasn't clear in its introduction.
I do get what you say about having to parse the gltf forms to see what actual version it turns out to be.
I think at this point though, we've extracted all the usefulness out of this issue. Some updates to the tutorial introduction that mentions its focus on glTF 2.0 is good enough for me.
Thank you!

I've added the statement

This tutorial focuses on glTF version 2.0, where support for Physically Based Rendering was introduced, but the other concepts that are explained here are similar to how they had been implemented in glTF version 1.0.

at https://github.com/javagl/glTF-Tutorials/tree/master/gltfTutorial#gltf-tutorial
Do you think that will resolve ambiguities? (I considered adding a reference to https://github.com/KhronosGroup/glTF/issues/605, but that would likely not be helpful for readers at that point...)
If so, I'd PR+merge this change.

I'm satisfied. Thank you!


hey!!, sorry again :'D

ive done everything in the README but, when i type in "yarn" and "yarn start-dev" it says "yarn : The term 'yarn' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again." i understand if your too busy to help me!! im just really new to github so i'll learn overtime!! :), have a nice day!!

You need to install Yarn.
By the way, BobaPS is completely broken and nonfunctional in its current state. There is nothing much to gain from setting it up.

oh?? may i ask what happened??

i also got in but it says incorrect password, am i supposed to put in a specific login?


Subdirectory deployment, unable to request JS and CSS

How is Anse deployed?
Others (Specify in description)
Describe the bug
I have deployed the node project in a subdirectory with the domain name xxx.com/ai, but the resources inside are still requesting the root path, so the request cannot be made. May I know how to modify it so that GPT can support sub paths
Console Logs

Participation

[ ] I am willing to submit a pull request for this issue.

You can set base to /ai in astro.config.mjs. See https://docs.astro.build/en/reference/configuration-reference/#base


Update checking of $this usage to only error in static methods.

This rolls back a few of the changes in #528 to address the concerns in #536. It will now only produce an error in static methods, and leave usages of $this in the root and in closures alone.

Personally, I'd prefer the approach in https://github.com/felixfbecker/php-language-server/pull/543


fix a bug

"/api/v1"  is useless, it is already included by func (c *Client) getParsedResponse(...)

LGTM

LGTM


weird number of prefixes received and resources used when testing with gobgp mrt files

I'm using gobgp to send mrt data from a routeviews mrt file. I'm trying to send 100K routes. For some reason gobgp doesn't actually send that many, but it's close. I have 10 gobgp processes, each in it's own container sending data and one monitor just listening and receiving routes.
What's weird is that here are different numbers of accepted routes, including one that is 93051, just 93% of the data.
$ docker exec bgperf_rustybgp_target /root/gobgp neighbor
Peer         AS  Up/Down State       |#Received  Accepted
<IP_ADDRESS>  1004 00:04:29 Establ      |    99305     99305
<IP_ADDRESS>  1009 00:02:55 Establ      |    99305     99305
<IP_ADDRESS>  1003 00:04:46 Establ      |    99305     99305
<IP_ADDRESS>  1008 00:03:12 Establ      |    99272     99272
<IP_ADDRESS>  1001 00:04:53 Establ      |        0         0
<IP_ADDRESS>  1007 00:03:32 Establ      |    99305     99305
<IP_ADDRESS> 1012 00:01:59 Establ      |    93051     93051
<IP_ADDRESS>  1006 00:03:53 Establ      |    99236     99236
<IP_ADDRESS> 1011 00:02:18 Establ      |    93051     93051
<IP_ADDRESS>  1005 00:04:07 Establ      |    99305     99305
<IP_ADDRESS> 1010 00:02:39 Establ      |    93051     93051

When I do the same test with FRR 7.5.1, it's consistent.
$ docker exec bgperf_frrouting_target vtysh -c 'sh ip bgp summary'

IPv4 Unicast Summary:
BGP router identifier <IP_ADDRESS>, local AS number 1000 vrf-id 0
BGP table version 99309
RIB entries 181579, using 33 MiB of memory
Peers 11, using 157 KiB of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
<IP_ADDRESS>       4       1001        13     28020        0    0    0 00:05:35            0    99207
<IP_ADDRESS>       4       1003    100014     28019        0    0    0 00:05:20        99305    99207
<IP_ADDRESS>       4       1004    100015     25786        0    0    0 00:05:02        99305    99207
<IP_ADDRESS>       4       1005    100013     23216        0    0    0 00:04:44        99305    99207
<IP_ADDRESS>       4       1006    100012     23213        0    0    0 00:04:27        99305    99207
<IP_ADDRESS>       4       1007    100012     23213        0    0    0 00:04:09        99305    99207
<IP_ADDRESS>       4       1008    100011     23212        0    0    0 00:03:54        99305    99207
<IP_ADDRESS>       4       1009    100011     23212        0    0    0 00:03:36        99305    99207
<IP_ADDRESS>      4       1010    100010     23211        0    0    0 00:03:15        99305    99207
<IP_ADDRESS>      4       1011    100009     23210        0    0    0 00:02:58        99305    99207
<IP_ADDRESS>      4       1012    100008     23210        0    0    0 00:02:39        99305    99207

Total number of neighbors 11

and gobgp as the target
$ docker exec bgperf_gobgp_target /root/gobgp neighbor
Peer         AS  Up/Down State       |#Received  Accepted
<IP_ADDRESS>  1001 00:05:52 Establ      |        0         0
<IP_ADDRESS>  1003 00:05:43 Establ      |    99305     99305
<IP_ADDRESS>  1004 00:05:24 Establ      |    99305     99305
<IP_ADDRESS>  1005 00:05:06 Establ      |    99305     99305
<IP_ADDRESS>  1006 00:04:50 Establ      |    99305     99305
<IP_ADDRESS>  1007 00:04:30 Establ      |    99305     99305
<IP_ADDRESS>  1008 00:04:13 Establ      |    99295     99295
<IP_ADDRESS>  1009 00:03:54 Establ      |    99305     99305
<IP_ADDRESS> 1010 00:03:35 Establ      |    99305     99305
<IP_ADDRESS> 1011 00:03:14 Establ      |    99305     99305
<IP_ADDRESS> 1012 00:02:58 Establ      |    99305     99305

Now the even more confusing, If I don't stop the tests, they just keep going forever with rustybgpd growing in memory and using lots of CPU. One test I had ran for almost an hour and it was up to > 50 GB of RAM. Even though the amount of received or accepted prefixes does not change.
Actually, I see the same behavior with gobgp as the target. So maybe there's a problem with gobgp as the mrt sender?
With FRR, after gobgp sends the 99305 prefixes then both gobgp and frr don't grow or consume CPU, so it works fine with FRR.

I suppose that this is related with rustybgp bugs, which were fixed.


Tests are not found for nose.

Environment data
Version: 1.60.0-insider (user setup)
Commit: 699084fdb48460c68086b85b5c08f3d39055e772
Date: 2021-08-12T19:13:28.730Z
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.17134
Build of python-insider: 2021.9.1125171759-dev
Build of jupyter-insider: 2021.8.2025984474
Expected behaviour
Tests are discovered.
Actual behaviour
Tests are not found.

Steps to reproduce:

Input below code:

def test_passing():
    assert 42 == 42
def test_failure():
    assert 42 == -13

Run tests with nose framework

"python.testing.nosetestsEnabled":true

Install Nose in current environment.
Run command: "Run All Tests"

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

User belongs to experiment group 'pythonaa'
User belongs to experiment group 'pythonJediLSP'
User belongs to experiment group 'pythonDiscoveryModuleWithoutWatcher'
User belongs to experiment group 'pythonTensorboardExperiment'
User belongs to experiment group 'PythonPyTorchProfiler'
User belongs to experiment group 'pythonDeprecatePythonPath'
User belongs to experiment group 'pythonSortEnvs'
Python interpreter path: C:\Python39-64\python.exe
Error 2021-08-13 07:31:49: Failed to check if file needs to be fixed [EntryNotFound (FileSystemError): Unable to read file 'c:\Users\vting\AppData\Roaming\Code - Insiders\User\settings.json' (Error: Unable to resolve non-existing file 'c:\Users\vting\AppData\Roaming\Code - Insiders\User\settings.json')
	at _handleError (c:\Users\vting\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:85:159261)
	at processTicksAndRejections (internal/process/task_queues.js:93:5)
	at async y.readText (c:\Users\vting\.vscode-insiders\extensions\ms-python.python-2021.9.1125171759-dev\out\client\extension.js:9:338733)
	at async p.doesFileNeedToBeFixed (c:\Users\vting\.vscode-insiders\extensions\ms-python.python-2021.9.1125171759-dev\out\client\extension.js:59:559685)
	at async c:\Users\vting\.vscode-insiders\extensions\ms-python.python-2021.9.1125171759-dev\out\client\extension.js:59:558812
	at async Promise.all (index 0)
	at async p.getFilesToBeFixed (c:\Users\vting\.vscode-insiders\extensions\ms-python.python-2021.9.1125171759-dev\out\client\extension.js:59:558758)
	at async p.updateTestSettings (c:\Users\vting\.vscode-insiders\extensions\ms-python.python-2021.9.1125171759-dev\out\client\extension.js:59:558385)] {
  code: 'FileNotFound'
}
Error 2021-08-13 07:31:49: Failed to check if file needs to be fixed [EntryNotFound (FileSystemError): Unable to read file 'c:\Users\vting\Downloads\Test5\.vscode\settings.json' (Error: Unable to resolve non-existing file 'c:\Users\vting\Downloads\Test5\.vscode\settings.json')
	at _handleError (c:\Users\vting\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:85:159261)
	at processTicksAndRejections (internal/process/task_queues.js:93:5)
	at async y.readText (c:\Users\vting\.vscode-insiders\extensions\ms-python.python-2021.9.1125171759-dev\out\client\extension.js:9:338733)
	at async p.doesFileNeedToBeFixed (c:\Users\vting\.vscode-insiders\extensions\ms-python.python-2021.9.1125171759-dev\out\client\extension.js:59:559685)
	at async c:\Users\vting\.vscode-insiders\extensions\ms-python.python-2021.9.1125171759-dev\out\client\extension.js:59:558812
	at async Promise.all (index 1)
	at async p.getFilesToBeFixed (c:\Users\vting\.vscode-insiders\extensions\ms-python.python-2021.9.1125171759-dev\out\client\extension.js:59:558758)
	at async p.updateTestSettings (c:\Users\vting\.vscode-insiders\extensions\ms-python.python-2021.9.1125171759-dev\out\client\extension.js:59:558385)] {
  code: 'FileNotFound'
}
Starting Pylance language server.

Nose is not supported from the next version of python extension. https://github.com/microsoft/vscode-python/issues/16371


List of available REST clients

When I click to get the 'full list of available REST clients and their references here', I get sent to https://docs.microsoft.com/en-us/vsts/extend/reference/client/core-sdk?view=vsts. Is this the right page? I'm not sure where to go to get specific clients I need to call.
In the example provided, the link for the 'Work Item Tracking Client' has a hyperlink to https://www.visualstudio.com/en-us/docs/integrate/extensions/reference/client/api/tfs/workitemtracking/restclient/workitemtrackinghttpclient2_2
But this just redirects to the same list, https://docs.microsoft.com/en-us/vsts/extend/reference/client/core-sdk?view=vsts
Where can I go to get reference on the names of the clients to call in VSS.require(), and then the methods they make available?

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

ID: 0f99e26d-54fa-ac2c-1814-e1b3f97a87b5
Version Independent ID: 0ed84e7f-b46f-3a44-16f6-d9bcf77bf11d
Content: How to Call a REST API
Content Source: docs/extend/develop/call-rest-api.md
Service: unspecified
GitHub Login: @erickson-doug
Microsoft Alias: elbatk

web.archive.org helps: https://web.archive.org/web/20161204030435/https:/www.visualstudio.com/en-us/docs/integrate/extensions/reference/client/rest-clients

Thanks a lot

Thanks, that's great, appreciate it. Looks like I'll need another way. I'm calling the graph API (https://docs.microsoft.com/en-us/rest/api/vsts/graph/groups/get) to get security groups, which it looks like the rest clients don't support (https://web.archive.org/web/20161204031624/https://www.visualstudio.com/en-us/docs/integrate/extensions/reference/client/api/tfs/core/restclient/corehttpclient2_2)

Well, I was digging in MS repositories on GitHub and here is what I've found:
https://github.com/Microsoft/vss-web-extension-sdk/blob/master/typings/vss.d.ts
This file describes all RestClients for VSS. Just search for VSS/Graph/RestClient. The module declaration contains all method declarations as well. You'll find getGroup(groupDescriptor: string): IPromise<Contracts.GraphGroup>; - I think that's what you were looking for.
Moreover I think this file contains all modules declarations, so other RestClients should be there also. I wonder if that's documented somewhere...

Why have the dead links not been fixed yet?


Meta data and symbol definitions should be consolidated into a more generic format

Currently, the metadata file is a strange thing. It must be named a certain way, and it expects some very specific columns and data.
It should remain, because it is very useful, however, it should be consolidated into a simpler format: i.e., something really simple like:

@definition
@value

version
1

copyright
(c) 2016

small
10x10

This is much more versatile and useful than only having one row and just adding more, and longer, columns.

Added in 2ecb38b1f3d97a86c919ec4309904d4de8e7a068


Add do-notation

For simple cases, a do-notation would be easier than adding ".then" to each line:
Promise.do -> [
	read(someStuff)
	_.map Stuff.toString
	_.join '\n\n'
	console.log
]

You could use this implementation:
exports.do = (promises) -> Promise.try -> promises().reduce (l,r) -> l.then r

Or as JavaScript:
exports.do = function(promises) {
  return Promise["try"](function() {
    return promises().reduce(function(l, r) {
      return l.then(r);
    });
  });
};

(I did not send this implementation as a pull request because I'm not sure where to put it)

I'm having a hard time understanding why you call a parameter that expects a function that evaluates to an array of functions "promises" - which usually means an array of promises.
I think what you are actually looking for is function composition, like Ramda offers it with composeP and pipeP:
R.pipeP(read, _.map(Stuff.toString), _.join('\n\n'), console.log)(someStuff);

I don't think we need this in Bluebird.

Promise.coroutine(function* (){
     yield* [yourTaskList]
});

?

@bergus The reasons why the parameter is a function that returns the list is so that any errors get caught by Promise.try; if the parameter was just a list then the entries in the list would get evaluated too early.
Your ramda code is equivalent to my proposed do-notation. But that's not the point. The point is that of these three options, I find the do-notation easiest to read:
# regular bluebird
Promise.try ->
  read(someStuff)
  .then _.map Stuff.toString
  .then _.join '\n\n'
  .then console.log

# ramda promise pipe:
R.pipeP(
  read,
  _.map Stuff.toString,
  _.join '\n\n',
  console.log
)(someStuff);

# do-notation
Promise.do -> [
    read(someStuff)
    _.map Stuff.toString
    _.join '\n\n'
    console.log
]

The bluebird version has ".then" at the beginning of each line and the ramda version has a comma at the end of each line except for the last one and it has the thing to read at the end (which is often useful, but sometimes it's easier to start with a promise instead of a function that returns a promise).
I'm not asking for a new feature here, I'm just asking for syntactic sugar.

Why not use coroutines?

I'm not sure I understand your argument. Are you saying one of these two?:

"We won't include any syntactic sugar for functionality that is already built-in or can be achieved by using other libraries"
"We will include syntactic sugar but this 'do' syntax is not good enough."
Which one is it? Or are you arguing for something else?

If you are saying (1) then I would disagree since bluebird itself is syntactic sugar for node's callback apis, so adding a bit more syntactic sugar to it would make it better.
If you are saying (2) then there is nothing more to discuss since I can't improve the syntax any more and I would have to accept your decision against it, since "better" is subjective in this case.

More like 1. We're trying to prevent API bloat here, and tend not to include syntactic sugar that only marginally improves established methods, and can trivially be shimmed; or that is not very very common and allows better lower-level optimisations.
You are encouraged to use this method yourself, but we don't think it's super useful to everybody who uses Bluebird.

Fair enough, in that case I have no further arguments and accept that it won't get included. I think the issue can be closed.
Thank you both for taking the time to discuss it!
P.S.:
If anyone besides me would actually use it: You can find it here now: https://www.npmjs.com/package/fstuff


Expose filename header in model training api

Rasa version: Rasa 1.10.1
Python version: 3.6.9
Operating system: Ubuntu 18.04.3 LTS (Bionic Beaver)
Issue:
I train a model using HTTP /model/train API and want to get a trained model filename as response header as defined in docs.
Unfortunately it seems like I can't do this: browser doesn't see response 'filename' header.
All I get are following:
HTTP/1.1 200 OK
Connection: keep-alive
Keep-Alive: 5
Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type
Access-Control-Max-Age: None
Access-Control-Allow-Methods: DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT
Vary: Origin
Content-Length: 0

Looks like this is issue about 'Access-Control-Expose-Headers'. Can we add 'filename' to exposed headers?

Thanks for the issue, @melindaloubser1 will get back to you about it soon!
You may find help in the docs and the forum, too 🤗

Can you post the request you're making/how you're making it? I do see the filename header returned with the request below:
curl --request POST --url http://localhost:5005/model/train \
--output model.tar.gz   \
  --header 'content-type: application/json' \
  --data '{
  "domain": "intents:\n  - greet\n  - goodbye\n  - affirm\n  - deny\n  - mood_great\n  - mood_unhappy\n\nactions:\n  - utter_greet\n  - utter_cheer_up\n  - utter_did_that_help\n  - utter_happy\n  - utter_goodbye\n\ntemplates:\n  utter_greet:\n  - text: \"Hey! How are you?\"\n\n  utter_cheer_up:\n  - text: \"Here is something to cheer you up:\"\n    image: \"https://i.imgur.com/nGF1K8f.jpg\"\n\n  utter_did_that_help:\n  - text: \"Did that help you?\"\n\n  utter_happy:\n  - text: \"Great carry on!\"\n\n  utter_goodbye:\n  - text: \"Bye\"",
  "config": "language: en\npipeline: supervised_embeddings\npolicies:\n  - name: MemoizationPolicy\n  - name: KerasPolicy",
  "nlu": "## intent:greet\n- hey\n- hello\n- hi\n## intent:goodbye\n- bye\n- goodbye\n- have a nice day\n- see you\n## intent:affirm\n- yes\n- indeed\n## intent:deny\n- no\n- never\n## intent:mood_great\n- perfect\n- very good\n- great\n## intent:mood_unhappy\n- sad\n- not good\n- unhappy",
  "stories": "## happy path\n* greet\n\n  - utter_greet\n\n* mood_great\n\n  - utter_happy\n\n## sad path 1\n* greet\n\n  - utter_greet\n\n* mood_unhappy\n\n  - utter_cheer_up\n\n  - utter_did_that_help\n\n* affirm\n\n  - utter_happy\n\n## sad path 2\n* greet\n\n  - utter_greet\n\n* mood_unhappy\n\n  - utter_cheer_up\n\n  - utter_did_that_help\n\n* deny\n\n  - utter_goodbye\n\n## say goodbye\n* goodbye\n\n  - utter_goodbye",
  "force": false,
  "save_to_default_model_directory": true
}' --dump-header header.txt

@melindaloubser1, sure, curl or other tool like that will see custom header. But for js code in browser it won't be accessible by default. Please check this link for more info.
I have prepared a demo app here, you can reproduce this yourself.
It starts a simple react app, containing one button which launches model training at http://localhost:5005 and prints to browser console available response's headers:

Then add the line here to configure sanic-cors:
 app.config.CORS_EXPOSE_HEADERS = '*'

After that much more info is available to browser:

Or less broadly:
 app.config.CORS_EXPOSE_HEADERS = 'filename'

If one of options above is suitable for you I can create a PR.

Ok that makes sense! Yes, if you could open a PR for exposing just filename additionally that'd be great.

@melindaloubser1 created a PR. Please check it when you have time.

@Ezhvsalate I don't think the commit you linked to is actually part of a PR, I left a comment on it


How to do request with SSL connection certificate in cardano testnet?

I've used this following code :
curl --cacert ./state-wallet-mainnet/tls/client/ca.crt https://localhost:8090/api/settings/sync/progress

But It's getting following errors:
curl: (35) gnutls_handshake() failed: Error in the push function.

Add --cert ./state-wallet-mainnet/tls/client/client.pem to your curl command.

Thank you.. It's solved.


Pydantic refuse to validate my schema

Description
Hi,
I'm pretty new with Pydantic validation but it makes me think a lot to Golang structures.
I'm trying to POST a pretty simple JSON payload but Pydantic keeps refusing the validation when using curl.
{
  "target": "https://google.fr",
  "link": "BHDH",
  "extras": {
    "code": "ABCDE"
  }
}

Here is my schemas.py.
from typing import Optional, Any, Dict
from pydantic import BaseModel, HttpUrl, Json

class Link(BaseModel):
    link: str
    target: httpUrl
    extras: Json[Dict[str, Any]]

print(Link(link='BHDH', target='https://google.com, extras='{"code": "ABCDE"}'))

Here is the curl command used to POST the JSON payload.
$ curl -X POST http://localhost:8000 -d '{"target": "https://google.fr", "link": "BHDH", "extras": {"code": "ABCDE"}}'

And this is the error I got:
{"detail":[{"loc":["body","extras"],"msg":"JSON object must be str, bytes or bytearray","type":"type_error.json"}]}

Thanks for your help :)
Environment
OS: Linux
FastAPI Version: 0.63.0
Python-version: 3.9.2

This will work for you:
curl -X POST "http://<IP_ADDRESS>:8000/" -H  "accept: application/json" -H  "Content-Type: application/json" -d "{\"link\":\"BHDH\",\"target\":\"https://google.fr\",\"extras\":\"{\\\"code\\\": \\\"ABCDE\\\"}\"}"

Code to test:
from fastapi import FastAPI
from typing import Optional, Any, Dict
from pydantic import BaseModel, HttpUrl, Json

class Link(BaseModel):
    link: str
    target: HttpUrl
    extras: Json[Dict[str, Any]]

app = FastAPI()

@app.post("/")
async def home(link: Link):
    return link

Swagger input:
{
  "link": "BHDH",
  "target": "https://google.fr",
  "extras": "{\"code\": \"ABCDE\"}"
}

But... I do believe that you don't want to do this :sweat_smile:
That whole body is a JSON, you probably want to use typing.Dict instead of pydantic.Json.

@Kludex ahah indeed, I prefer to avoid the \ !!
typing.Dict did the trick, thanks.

Thanks for the help here @Kludex ! 👏  🙇
Thanks for reporting back and closing the issue @goldyfruit  👍

Sorry for the long delay! 🙈  I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.


Update logger-name for clean

Pull Request Checklist

[ ] implement the feature
[ ] write the documentation
[ ] extend the test coverage
[ ] update the specification
[ ] adjust plugin docstring
[ ] modify the json schema
[ ] mention the version
[ ] include a release note

Seems like a typo

/packit test

/packit build

Failing tests were infra problems + avc check on rawhide (irrelevant, needs to be investigated).


Stability set to Unknown intially and triggering assert on non-empty value coming in

In attempting to implement @since and related feature gates in jco I ran into an issue that may be long here.
First, all the Stability values in functions on the Resolve seem to be Unknown.
Secondly, it seems that there's a panic when running wit-bindgen on newer WITs with @since annotations in them -- in particular the code that panics is the following:
https://github.com/bytecodealliance/wasm-tools/blob/v1.212.0/crates/wit-parser/src/resolve.rs#L2350
I'm not sure exactly why but there is already a value of Unknown in place and when the new value (correct seeming) value comes along, the previous one existing triggers the assertion.
Assuming this case really shouldn't be happening (if the idea is that once the stability is encountered it should never change), it seems that at the very least a more complete error message (perhaps a bail rather than the assert_eq there) should be used at the very least
@cpetig ran into the panic due to that assert_eq:
thread 'main' panicked at …/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wit-parser-0.212.0/src/resolve.rs:2350:21:
assertion `left == right` failed
  left: Interface { id: Id { idx: 1 }, stability: Unknown }
 right: Interface { id: Id { idx: 1 }, stability: Stable { since: Version { major: 0, minor: 2, patch: 0 }, feature: None } }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

With a pretty basic WIT-only project with the following deps.toml:
cli = "https://github.com/WebAssembly/wasi-cli/archive/main.tar.gz"
clocks = "https://github.com/WebAssembly/wasi-clocks/archive/main.tar.gz"

(i.e. you could reproduce it with a folder named wit with only that deps.toml and a call to wit-deps then a recent version of wit-bindgen

Thanks for the report! Definitely agreed this shouldn't be a panic. The issue I think is that in wasi-clocks itself it's using @since but in wasi-cli it's not. That discrepancy leads to this panic where the panic was designed for before stability annotations and now it's surfacing this discrepancy. I'll work on fixing this.

Ahhh -- thanks @alexcrichton , this makes sense -- @cpetig noted something along the same lines IIRC, thinking that the problem was with wasi-cli in particular.
So if I'm understanding right, basically the WIT for wasi-cli got pulled in before the WIT for wasi-clocks (which lexicographically makes sense anyway, though not sure if it's ordered that way)?

I wonder if this is perhaps the same issue we're seeing here https://github.com/WebAssembly/wasi-http/pull/114#issuecomment-2197661559 ?
thread 'main' panicked at /Users/yosh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wit-parser-0.209.1/src/resolve.rs:2105:21:
assertion `left == right` failed
  left: Interface { id: Id { idx: 1 }, stability: Stable { since: Version { major: 0, minor: 2, patch: 0 }, feature: None } }
 right: Interface { id: Id { idx: 1 }, stability: Unknown }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I went ahead and tested https://github.com/bytecodealliance/wasm-tools/pull/1669 as part of a local wit-bindgen build. That seems to work to resolve the issue in https://github.com/WebAssembly/wasi-http/pull/114#issuecomment-2197661559!

Thanks for the super quick resolution on this @alexcrichton :bow:


Implement f32.max, f64.max, f32.min and f64.min

This is just a start. I think correct handling of NaN payloads would require more work than just Math.min and Math.max. I haven't fully looked into it though. Here are the relevant spec parts:
https://webassembly.github.io/spec/core/exec/numerics.html#op-fmin
https://webassembly.github.io/spec/core/syntax/values.html#syntax-payload
https://webassembly.github.io/spec/core/exec/numerics.html#nan-propagation

Refs https://github.com/xtuc/js-webassembly-interpreter/issues/1


Update OHM Inspector to include caption with image date, license, and source info for image

What's your idea for a cool feature that would help you use OHM better.
Here are some thoughts on the current inspector image display (which is awesome):

The caption could be richer, and include source and license info
Side note... unclear how we could / would relate the time slider to the picture display
Start_date and end_date are just kind of hanging out right now & it's unclear if they're related to the image or to the building... it's a bit of a UI conundrum

Maybe something like this:

Whoops... forgot the Wikipedia & Wikidata links.... very important for our Linked Open Data friends (and us!)

Whoops... forgot the Wikipedia & Wikidata links.... very important for our Linked Open Data friends (and us!)

Ack... forgot "Followed by..." 3rd time is the charm! (he hopes... maybe not so charming...)

Ack... forgot "Followed by..." 3rd time is the charm! (he hopes... maybe not so charming...)

@jeffreyameyer note that you said "text__ shruggle" but we had an existing feature that would pull in a description fro Wikipedia. Present behavior is that we try to fetch an excerpt and insert it into the page, with a “[link]” at the end.
your mockup eliminates that and instead links to

Wikipedia | Wikidata

Should we do that instead and ditch the description excerpt?

@jeffreyameyer note that you said "text__ shruggle" but we had an existing feature that would pull in a description fro Wikipedia. Present behavior is that we try to fetch an excerpt and insert it into the page, with a “[link]” at the end.
your mockup eliminates that and instead links to

Wikipedia | Wikidata

Should we do that instead and ditch the description excerpt?

Ah.... if you have that excerpt working, let's use that!

Ah.... if you have that excerpt working, let's use that!

I didn't mean to eliminate that... it's just represented by "Brief descriptive text, if we have a source..." and it appears we do!

I didn't mean to eliminate that... it's just represented by "Brief descriptive text, if we have a source..." and it appears we do!

A screenshot of the new work in progress,

A screenshot of the new work in progress,

To do:

[ ] add Wikilink special bottom link, from wikilink tag

To test:

[ ] Felker House is not showing More Info links, though seems to have more_info:x defined, same as Occidental Hotel does https://staging.openhistoricalmap.org/way/198099635 https://staging.openhistoricalmap.org/way/198291609

To do:

[ ] add Wikilink special bottom link, from wikilink tag

To test:

[ ] Felker House is not showing More Info links, though seems to have more_info:x defined, same as Occidental Hotel does https://staging.openhistoricalmap.org/way/198099635 https://staging.openhistoricalmap.org/way/198291609

I think that's wikidata, not wikilink! : )

I think that's wikidata, not wikilink! : )

I think this is done


Aliases!

About this pull request
This pull request adds a Slash Command aliases argument to the decorators. Decided not to mess with subcommands (what would aliases for subcommands even be useful for?).
In the argument description, it warns the user that it will count up their command limit.
Changes

Added argument to @slash.slash and @cog_ext.cog_slash decorators for command aliases.

Checklist

[X] I've run the pre_push.py script to format and lint code.
[ ] I've checked this pull request runs on Python 3.6.X.
[ ] This fixes something in Issues.

Issue:

[X] This adds something new.
[ ] There is/are breaking change(s).
[ ] (If required) Relevant documentation has been updated/added.
[ ] This is not a code change. (README, docs, etc.)

I don't understand why aliases are needed for Slash commands

I don't understand why aliases are needed for Slash commands

Me neither, but it will definitely satisfy the guys who keep asking for them.
Now they can get a different answer other than "fuk u dumbass API doesn't support", lol.

i dont think that satisfying people that dont understand how slash commands work would bring anything positive, at an extreme it will bring people that have used all 50 commands even though they only have 20 "real" (non alias) commands

i dont think that satisfying people that dont understand how slash commands work would bring anything positive, at an extreme it will bring people that have used all 50 commands even though they only have 20 "real" (non alias) commands

The argument description explains it, so if they don't read it, we can tell them, when they come crying for help, that it clearly says that it counts up to the limits, so they should remove some aliases.

I'm gonna be that guy who will say "API doesn't support." I see many issues with aliases being established in this fashion:

You quickly hit the global/guild command limit
You very quickly hit the interaction creation limit (so now you can't make commands for another 24 hours)
This is a very spammy solution that hacks away at the current codebase
You risk running into double commands

If people want aliases, they're going to need to wait for the API to support them.

yea, literally no point in aliases, you can tab-complete slash commands.

I'm going to be pulling this PR because I do not think it would be a wise decision implementing it at this time when there is a lack of API support for it as well as the problems aforementioned.


Support LINQ when receiving packets.

Brickner[CodePlex] Current support uses ReceiveSomePackets.
This is efficient since all packets currently in the buffer to read are read together but this can cause more packets to be read beyond the requested amount.
This means that while the IEnumerable will receive the expected number of packets, there might be more packets that have been read beyond the packets that the IEnumerable contains.

Brickner[CodePlex] If a different behavior is needed, open another issue.


Error handling for Set Value

We need to decide how the fromProto method should handle request from the client that are partially invalid. i.e. if the client sends a set value request for a struct and one of the struct_value fields given is a field that the client is not authorized to write to, or it does not exist within the param, then how should the error be handled.
Option 1: throw an error
If the request includes an invalid field, then throw an error and cancel the request with bad status. In order to avoid misleading error messages, the bad status response from the service would include json pointer to whatever field caused the error.
Option 2: Ignore invalid fields
If the request includes an invalid field, then fromProto will simply ignore that field and continue to write any valid fields from the incoming value. The client would then see in the update pushed by the connect rpc that the invalid field did not change.

Notes from today's meeting:

In the case of a partially valid request, the valid parts of the request will still be processed. The invalid parts of the request will be skipped, and error info should be logged and passed to the client. The call should end with status::ok.
For functions that need to be able to return both a value and an error status, we will define a result info struct so that both can be returned together.

The implementation of this should include documentation to clarify that this makes use of C++ return value optimization to avoid making unnecessary copies of the return value and the error status
for cases where the error is fatal and there is no param to return, we can use std::optional to return std::nullopt instead of returning null pointers

Important implementation detail to avoid information leaking to attackers:

trying to write to a param that a client DOES have read access for should return an unauthorized error status.
trying to read/write to a param that a client DOES NOT have read access for should return a does not exist error status.

I've been reading the gRPC Error Handling documentation. Currently we are using the standard error model provided gRPC but the documentation also talks about a richer error model provided by Protobuf. I am wondering if this model would be better suited for us because, as the documentation states, "This model enables servers to return and clients to consume additional error details expressed as one or more protobuf messages." This would be useful because set value request can include an arbitrary number of invalid sub-params so it would be better to send the error details as multiple protobuf messages.
There are some drawbacks also explained in the documentation, but this would be worth considering. With the generic gRPC error handling it will be difficult to provide detailed error info to clients.

I think we need to keep it simple and move on to bigger issues.
BTW the guidelines in status.h advise these return codes

UNAUTHENTICATED if access is unauthorized, but the id of the user isn't known
PERMISSION_DENIED if user id is known, but access is not authorized

I'm not particularly concerned about returning live, detailed error info to clients because, as stated, we have bigger issues. However, we should be logging these events so that a log management system can get at them for after the fact failure analysis.
In summary - if any part of the SetValue request succeeds, we return status::OK and stream the values of updated parameters to which the attached client has access, and log the unauthorized accesses locally.


refactor: replace "dax-sh" with native "node:child_process"

Since node:child_process is supported on most popular javascript runtime like: bun, deno, workers ...
Extra:

Remove boxen unused dependency
Moved @types/micromatch to dev dependency

I like what this is doing and I generally agree that support for node: prefixed deps is pretty standard now. Any opinions @nksaraf


Ensure filebeat (re)starts only once on install

The filebeat playbooks were causing a start followed very quickly by a
restart of the filebeat service, which was causing the service to die.
This commit adds a 'flush_handlers' so that the service is (re)started
prior to the task where it is 'enabled' thereby removing the need for a
second restart.  This fixes the issue with the filebeat service
stopping.
Connected https://github.com/rcbops/rpc-openstack/issues/1310
Co-Authored-By: Ian Cordasco<EMAIL_ADDRESS>

RPC-AIO-Liberty-PR: Fail

RPC-AIO-Ceph-Liberty-PR: Fail

recheck_all

👍

👍 Will merge once the tests pass.


Upgrade dependencies

Changes:

Upgrade versions of eslint, eslint-config-airbnb, eslint-config-airbnb-base, stylelint, stylelint-config-standard
Use @babel/eslint-parser instead of deprecated babel-eslint

Note:
Need to be merged after https://github.com/datarockets/style-guide/pull/38

Besides from the question above, other changes looks good to me 👍

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update mdast to remark

Hey! Just wanted ping and request a name change from mdast to remark.
Maybe you’ve already seen it but here’s a list of tips for updating. And here’s a list of reasons why to update.
Let me know if I can help! :smile:

Merged in https://github.com/mapbox/mdast-cross-reference/pull/2


Allow unlisted commodityv3 fields to be ignored

Backend currently hangs whenever it encounters a field not explicitly listed
Currently an issue for Commodity.V3
May be worth adding to all classes, we dont want an upstream change to break our backend. We should strive for concurrency but the defauly when encountering an unexpected field should be to ignore it.

Actually considering whether @JsonIgnore should be placed on all payloads to prevent upstream changes from breaking backend
Also think all primitive data types should be converted to objects to prevent errors if nulle are mapped.

Actually considering whether @JsonIgnore should be placed on all payloads to prevent upstream changes from breaking backend

Agree.

Also think all primitive data types should be converted to objects to prevent errors if nulle are mapped.

Hmm, but there are fields defined as "required", and I don't remember there being any schema validation in place? So, I'd opt to leave required primitive fields as is. What's the point in handling malformed messages?


PoC for separate content files

Huge breaking change.
Some issues with the current PoC (https://discuss.gohugo.io/t/prevent-content-from-being-rendered-added-to-sitemap-single-page-sites/4708/4):
/index/ is rendered empty no 404. Probably due to index.xml being created within this directory.
Same thing for /$language/index/
Leaking of content via index.xml (feed) is reduced with custom template. Not perfect, but a start.
Sidemap is also reduced via custom template to not link to partial index content.
So mostly needs 404 on the *index/ directories and a way to disable RSS on sections.
Disabling globally via DisableRSS = true doesn't seem to work and wouldn't be a solution due to the blog layout on the horizon.
Should run with hugo v0.17 I think.
This currently fixes: #61 #62 #41

Thank you for taking the time to implement and explore the best implementations for this new enhancements!
This pull request is indeed not backwards compatible but offers much more flexibility. I especially like how much simpler the config file become by moving the configuration for each section into their own files.
Since this theme now has i18n support it would be great from a user's perspective to change language on a page if possible. What do you think about a drop-down menu in the main navigation?
I saw that you created sample sites for the legal stuff. Their structure would also be great for a blog. Adding support for tags and categories via their corresponding templates shouldn't be hard. A comment section could be shown based on a frontmatter variable. But it should also be easy to hide on sites like the legal page.

About the dropdown menu for i18n I did a thing like that in my page. Dirty and awful code, but does the trick and maybe shows what you want: jlcs.es

I thought about something in that direction.

Last thing is to consider the way to support the different language versions of the web.
My solution was to generate with 2 different config files the site for mydomain.com/ (Spanish) and for mydomain.com/en (English), runngin hugo twice.
I could not fix all the links in the theme to use a solution like "es.mydomain.com" for Spanish and "en.mydomain.com" for English. I remember something about the way hugo generate links with the domain in the config, and other links in the themes.
I know this is not much info, but maybe helps to give a solution.

Yeah the language switch is still on my ToDo, but I wanted to get the PoC merged so that for other fixes the base is stable. So currently the todo is still:

language switch
blog layout
fix issues with /index/ not returning 404
fix index.xml issues

Concerning the dropdown for language switching, I am open to the suggestions, haven't played around with any solution yet, but for multiple languages a dropdown seems good and for 2 languages maybe just show a switch. I'll have to check with the various devices etc.

For your information: I made the exampleSite folder a standalone Hugo website (see 2be420052851fbb79095363c89a11d82c96e37db). This allows you to preview the theme without setting up an extra environment, i.e. instead of doing
hugo new site foo
cd foo/themes
git clone THEME_URL
# copying all files into the root dir (that might have to be kept in sync)
cd ..
hugo server

you just have to
git clone THEME_URL
hugo server

instead. themesDir = "../.." turns exampleSite into the root directory of a Hugo website. However, you should remove this line once you start a real website that usually is build using the first approach.


should we change str/unicode implementation for PEP 383 ?

when decoding/encoding some str/bytes you can (for example) :
'strict' :  raise an exception
'ignore' : wrong bytes are kicked out
'replace' :  wrong bytes are replaced by the UNICODE_REPLACEMENT_CHAR
'backslashreplace' : Replace with backslashed escape sequences
No problem with current implementation for these ones.

This PEP proposes a means of dealing with [such] irregularities by embedding the bytes in  character strings in such a way that allows recreation of the original byte string.

'surrogateescape' : replace wrong bytes by surrogate

With this PEP, non-decodable bytes >= 128 will be represented as lone surrogate codes U+DC80..U+DCFF.

But the actual RustPython implementation stores str as valid unicode then :
a.push('\u{dcc3}');
help: src/main.rs:25: unicode escape must not be a surrogate

storing surrogate is not allowed.
I tried to do it inside an unsafe block it's not possible either.
I'm note sure  to have a clear idea howto to do  it. I was thinking to a wrapper on a "homemade" unicode and the Rust unicode implementation to store strings,  but actually python is able to call some methods on invalid  utf8 sequence :
a.capitalize()
>>>  '\udcc3\udca9'

I'd be happy to have some opinion about it.

Probably we need another str kind presented by &[u32]


Add testrunner Maker

Add a qxcompiler.makers.Maker for building test runner

I'm not sure if this is the right place, but as this issue is about testrunner I'll try it here;
The karma-qooxdoo adapter (used in travis to run qooxdoo's unit tests) does not work with code compiled with qx compiler.
Basically the adapter needs to access qx.$$libraries and qx.$$loader from the generated boot js.
The old way of getting this information was/is very ugly (regex in combination with eval) and is not possible with the code in boot.js. I guess the best way would be to generate a file with only the information needed, maybe that's what the purpose of this issue is about?

Kind of - the need for a "testrunner Maker" means that the generator had a lot of code (mostly in config files) that was used to detect which modules were needed and compile them, and along the way generate some other artifacts that were required for the test runner to operate.
This does mean that qxcompiler is not able to produce a testrunner right now, which is going to be an issue for you if you are using ES6 and relying on the transpilation in order to have working code.  Having a working qxcompiler-based TestRunner is a blocker, and is getting increasingly important.
I'm not sure whether you would be able to rig together something that worked with qxcompiler doing some bits and generator doing others - I can't look at it right now, but I'll do my best to help you figure it out if I can.  Please can you point me to the code you're talking about and I'll see if I can come up with an alternative?
(BTW I'll be out most of this afternoon)

I added this comment, just as a reminder that the problem must be solved before the qooxdoo project replaces the old generator with the new compiler (because the tests on travis would fail then).
I don't need it personally at this moment. So no reason to hurry ;-)
The code where the karma adapter extracts the information it needs from the loader script is here: https://github.com/qooxdoo/karma-qooxdoo/blob/master/karma-qooxdoo.js#L84-L91 (I know its ungly code).
If qx compiler will support loader templates I quess that should be the way to go: use a special loader template to generate a loader script for the karma adapter. But I am not really familiar with the qx compiler yet, maybe there is another, even better way.

ISWYM; the problem is not that the qx.$$ variables have changed in structure, it's just that the loader data is formatted slightly differently - I think that the libinfo regex at https://github.com/qooxdoo/karma-qooxdoo/blob/master/karma-qooxdoo.js#L84 is failing because the JSON is not on one line; try changing it to:
    // read libinfo
    matches = source.match(/var libinfo = {((.|\n)*)};\n/m);

I think that if the second regex fails, it is because there is only one \n after the data structure, in which case please try tweaking qxcompiler/lib/qxcompiler/app/loader-browser.tmpl.js.
Ultimately the best way may be for the qxcompiler to output the data as a JSON file in the application directory alongside boot.js; it would be a duplicate of whats in boot.js, so should only enabled for the test runner output but would be much easier and more reliable to parse.  (actually the SelfTestTarget does exactly this so that the unit tests can check what qxcompiler calculated)

The next version of qx-cli supports a writeCompileInfo property for each target, that will cause a compile-info.json and resources.json to be output into each application directory, eg:
	/** Targets */
	"targets": [
		{
			"type": "source",
			"outputPath": "source-output",
			"writeCompileInfo": true
		}

Is this still necessary?  If the old testrunner been superceeded by @oetiker 's https://github.com/qooxdoo/qxl.testtapper we can close this

The old testrunner was nice to look at but I guess we don't need any eye candy if all we're interested in is if the tests pass or not (you can tell 1&1 had a team of 6+ developers to spend time on things like the test runner...)


Added version requirement for az upgrade

Added version requirement for az upgrade to clarify that the command does not work with versions prior to 2.11.0.

Docs Build status updates of commit 966a2c4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/includes/az-upgrade.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


add owners aliases

Signed-off-by: brmclaren<EMAIL_ADDRESS>

/test all

/ok-to-test

/retest

/retest

/test all

/close

/reopen

/test all

/test all

100% pass.

/test all

99% pass.

/test all

92% pass.
Seems this is caused by the Jenkins bottleneck with hardware however.

/test all

/close

/reopen

/test all

/test all

/test all

/test all

/test all

/test all

/test all

/test all

/test all

/test all

/verify-owners

/verify-owners