retainDyeOnSignCopy=false still copy color and glow

The option retainDyeOnSignCopy set to false has no effect (the copied signs still have color and glow texts).

Not sure if this is the reason you are holding on publishing the 1.20.4 version, but that bug is also present in the prior release, so no new harm is done by just putting out the new release.

I’m on vacation so won’t be able to publish until January.

Fixed and pushed a new release


Fix web tests with signed transactions

Holiday times please ignore this PR until after New Year's 🎅🏽🎄

This PR fixes broken web tests by signing transactions with a key (Arweave wallet).
❌ Before

✅ After

That test needs to be fixed, but it is actually supposed to test an externally injected browser wallet, e.g. ArConnect.io, not a jwk as in the previous test.
The unit test name should be updated to external Arweave wallet, instead of Arweave wallet
I'm going to investigate if the web tests can be done using headless Chrome + ArConnect, as they are currently not working out of the box in the current state.

I've opened an issue for this, but i'll be closing this PR. thanks again @hzhu !


feature: Add pluggable components versioning support

In what area(s)?

/area runtime

/area operator

/area placement

/area docs

/area test-and-release

Describe the feature
When registering pluggable components, version is not being used, the full name should be used instead which contains the version on it (i.e $componentName/$version) as it is the expected format for all implemented registries.

state store
pubsub
bindings

Note: When version is not specified the fullname should contain only the component name to fallback to the dapr runtime default behavior.

Release Note

RELEASE NOTE:

/assign

We should not make versioning implicit and break consistency with existing component versioning.

Can you elaborate more? The proposal here is to make versioning working for pluggable components the behavior is the same as we already have
which is:
If specified as $name/$version it should be registered with its version, if not specified with $name/version so the runtime fallback to the "implicit" versioning (as it is today, I didn't mention that):
https://github.com/dapr/dapr/blob/master/pkg/components/bindings/registry.go#L93
https://github.com/dapr/dapr/blob/master/pkg/components/bindings/registry.go#L109
https://github.com/dapr/dapr/blob/master/pkg/components/configuration/registry.go#L66
https://github.com/dapr/dapr/blob/master/pkg/components/middleware/http/registry.go#L79
https://github.com/dapr/dapr/blob/master/pkg/components/nameresolution/registry.go#L76
https://github.com/dapr/dapr/blob/master/pkg/components/pubsub/registry.go#L63
https://github.com/dapr/dapr/blob/master/pkg/components/secretstores/registry.go#L72
https://github.com/dapr/dapr/blob/master/pkg/components/state/registry.go#L63

Anyways, I'm going to close this as it does not apply given that removing of pluggable component crd.


DEMO is broken

All 5 examples fail.
Tested on both Firefox and Chrome.
Demo link: https://node-cors-client.netlify.app/

I've looked over the code related to this issue, both on the server and client side. I've found this to be the problem, and it is related to Heroku removing their free tier.
The HTTP request methods such as GET, HEAD, POST, DELETE are being made with this url https://node-cors-server.herokuapp.com/simple-cors which is now a dead link. When loading the URL, it returns this

In conclusion, this issue should probably be closed, and perhaps a separate issue opened to recreate the HTTP method requests on Netlify.


Why is there no FusedStream implementation for FuturesOrdered?

While FuturesUnordered has a FusedStream implementation, the FuturesOrdered type does not. Is there any reason for this missing implementation or is this just an oversight?

I think this is an oversight. (Basically, any stream that can see that itself is empty can implement FusedStream).

Good to hear that. A FusedStream implementation would make it much easier to work with FuturesOrdered in a select block. (You can't use the fuse() method when you're adding futures to the set later.)
Would a simple check for FuturesOrdered::len() == 0 suffice for a FusedStream implementation? If so, I'll be happy to send in a PR for this.

Would a simple check for FuturesOrdered::len() == 0 suffice for a FusedStream implementation?

I think the correct implementation is self.in_progress_queue.is_terminated() && self.queued_outputs.is_empty().

(Basically, any stream that can see that itself is empty can implement FusedStream).

This (my comment) is not correct (sorry!).
If I understand correctly, it's probably actually something like:

Even if it is empty, if it may return Ready(Some) in the future, it should be considered as "terminated" only after Ready(None) is returned once. (e.g., FuturesUnordered that elements may be added)
(However, FusedStream implementations may be provided that considers is_empty as is_terminated for specific use cases)
If there is no possibility of returning Ready(Some) in the future, it can be considered as "terminated" regardless of whether Ready(None) was returned once. (e.g., stream::once, stream::empty, stream::pending, StreamExt::take)

(cc @cramertj: my understanding is correct?)


Please clarify IP usage versus Required Services

We use Microsoft InTune for mobile device management.  Intune enforces network access policies via a allowed/disallowed list of network addresses (e.g. Web site URLs such as DISALLOW: http://*.youtube.com).  InTune does NOT allow IP addresses for network whitelisting or blocking.  It is not clear from this article if we need to add ONLY the Required Services entries to our devices' allowed/whitelist network addresses OR if we need both the IP Addresses and Required Services entries in that whitelist.  Our PApps use a mixture of MSFT connectors such as SQL Server (Azure and via OnPrem Gateway) and O365 (e.g. OneDrive, SharePointOnline).  Please expand this article to more clearly explain what network targets MUST be accessible from a device running either the PowerApps IOS/Android app or a Web browser using the PowerApps Web Player.

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

ID: d2e8858f-ee37-b1f0-2ad1-a52416f58d0d
Version Independent ID: 23c5799a-0e3a-bd52-8f8c-ce586c93e632
Content: System requirements, limits, and configuration values for canvas apps - PowerApps
Content Source: powerapps-docs/maker/canvas-apps/limits-and-config.md
Service: powerapps
GitHub Login: @gregli-msft
Microsoft Alias: gregli

Thank you for reaching out. IP list and required services are not alternatives. Both are listed separately and required. As documentation states, IP address listing is because we don't publish fully qualified domain names available for Power Apps scenarios. And the required services lists all services to which Power Apps Studio talks and their usages that shouldn't be blocked.


Optimization metric  Duplicate * [Typo]

Existing :
Optimization metric
'micro_f1': minimize 1 - f1_score with average="micro".
'micro_f1': minimize 1 - f1_score with average="micro".
Should be present
Optimization metric
'micro_f1': minimize 1 - f1_score with average="micro".
'macro_f1': minimize 1 - f1_score with average="macro".

Thanks. Would you like to create a PR to fix it?


MAXCDN repository link unstable

We've been having some very spotty performance from the hosted bootstrap links i the last week or two. We are using the ones given here: http://getbootstrap.com/getting-started/
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js
I am getting an error "This site can’t be reached. The connection was reset maxcdn.bootstrapcdn.com unexpectedly closed the connection."
I've tested across half a dozen different ISP's and these files seems to be inaccessible most of the time. I've tested on different platforms and browsers as well. So it doesn't seem like the problem is on my end.
If I change the sub-domain to www they seem to load fine:
https://www.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css
https://www.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css
https://www.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js
I would prefer not having to do this changed on hundreds of sites that are using these files though. Also, I wouldn't want to rely on that moving forward if the maxcdn sub-domain is the 'official' one.

There is also: http://maxcdn.bootstrapcdn.com/bootstrap/latest/css/bootstrap.min.css
Which is listed on the boostrapcdn main page. I would use that instead

@Whirler I can't reproduce this. Could you provide a traceroute for each of the domains?

We are seeing the same issue today.

Changing https to http seem to load fine.

Please file an issue with the BootstrapCDN folks:
https://github.com/MaxCDN/bootstrap-cdn/issues

@Whirler CDNJS also provides hosting for Bootstrap if you're looking for an alternative:
https://cdnjs.com/libraries/twitter-bootstrap/3.3.7
According to CDN Perf it has lower average latency than BootstrapCDN as well.

Closing out for now since issues seem to have resolved themselves.


fix(model/application/command): remove required field from OptionsCommandOptionData

If this set is set to true Discord will respond with an error (as reported in #1018).
Discord has now documented this too:

Using subcommands or subcommand groups will make your base command unusable. You can't send the base /permissions command as a valid command if you also have /permissions add | remove as subcommands or subcommand groups.

I don't know if is_required returning None for SubCommand | SubCommandGroup is better than returning false
Closes #1018

Thanks


Referenced OAuth Flows in 3.71

The list of OAuth flows in Section 3.71 might be problematic, since

the OAuth 2.0 Device Code Grant is missing, which would be my first choice for devices with no direct user interaction (monitors, etc.).
according to OAuth 2.0 the client credential grant type is typically used by "clients to access resources about themselves rather than to access a user's resources".
the implicit Grant Flow is no longer recommended by OAuth for security reasons.

Refactored the section with grant flows options.


Bug/invalid select value

Catch the case where invalid value is passed in and just display empty in this case as the underlying select component requires. An invalid value is one that is not a member of the options.
Closes https://github.com/IPG-Automotive-UK/ngd/issues/238

I've removed the async from the new tests. I've also added an eslint rule to catch such cases in the future. In adding the rule I found some existing code which was violating the rule so I have fixed those as well. This then uncovered some tests which were never going to fail so I fixed those as well.


Intent ?

Is the goal to get the fs system working as Service worker ?
or for web workers to use indexdb as a durable bus ?
Am curious :)

Hey @gedw99! This library is intended to make Web Worker interop easier. Specifically, I'd like to use it to build more useful tools on top. I had difficulty ensuring message passing was working as intended, so this library will likely grow significantly into the message passing arena.
For Hackpad, I'd like to initialize workers with the Go script, execute a Wasm binary, and set up the same file system used Hackpad's main thread. It's complex enough I wanted to yank out the message passing into a separate lib. And here we are 😄

Very cool :)
a mini demo coming one day ?

That's the plan! Finding time is difficult, as always 😄

Hey @JohnStarich
I am porting this bud to also work in web workers …
https://github.com/gedw99/skel
The readme explains it harshly but it should be obvious I think once you try it on desktop and then was wasm
i see synergy with your hackpad.
there is a full golang debugger using delve also written with gioui
i am pondering extending Nats.go to work in process also so it can also work inside PWA and native apps . I might be bitting off mitre than is worthwhile though.
https://github.com/nats-io/nats-server/blob/main/server/client.go#L39
happy to discuss ideas etc . Just should.
FYI @oderwat

@gedw99

https://github.com/nats-io/nats-server/blob/main/server/client.go#L39

Points to the functional type of the connection.
The following point is seemingly more relevant:

https://github.com/nats-io/nats-server/blob/b61e411b44af43a125f89e549d0ac7337c88db89/server/client.go#L544

Even when NATS at its core just has a simple string-based protocol, there is a lot of stuff going on for connection handling (as it has to switch servers / clusters / exchanging data between nodes / raft and so on). I guess that the Websocket implementation could be a "basis" for another types of connections.
If I would "at all" consider using NATS with another transport, I would probably think about emulating TCP on top of some other (event) system. TCP is also just packages in the end.

https://github.com/jordwest/mock-conn
https://github.com/WebAssembly/wasi-sockets

Adding all of 'nats-server', plus all of  'nats.go' (which also implements a lot of the functionality on top) seems quite a bit of overhead for something that is already there between web workers: "events". I really don't see the utility. NATS works with central servers (spreading the nodes and clusters around the world, does not change that),
I may muss the point. I already have a hard time understanding that is in your mind @gedw99. Why just using TCP? Isn't a WebWorker not already using TCP in the first place?

hey - thansk fro writing back.
i agree this is complex and 90% not worthwhile. I just wanted to get a second option...
emulating TCP sounds like a nice option.
the bit about not understanding the why is that web workers communicate with Service workers over message passing inside the browser, not over tcp.
https://developer.mozilla.org/en-US/docs/Web/API/Worker/postMessage
golang sample: https://blog.boot.dev/golang/running-go-in-the-browser-wasm-web-workers/
its a bit old though :)
Please feel free to ask if anything not clear...

@gedw99 If you are inside the same browser, the message flow seems trivial to me. I thought you needed a connection between different browsers. I actually never considered having the same PWA opened in multiple Tabs in the browser to exchange data between each other. Likewise, I just use IndexedDB when I need to share data between them or go "outside" over web socket to the nats-server and back. This is because we usually need to support the same PWA also working on another browser or "desktop" and some data must be everywhere anyway. Like on different tablets for synchronized time logging at multiple check in / out points for workers in huge storage facilities. For "multiple tab" scenarios, I would just use one browser tab. Why starting many ones, they are resource hogs.

yeah sorry been a long day :)
My use case is exactly the same as yours but with a few twists i think..
Yeah i remember we had a chat ages ago about IndexedDB. Not sure i need it. Not doing offline first as then we get into awful data sync and out of order merges.. Maybe another day... One step at a time.
So as far as i can tell the data flows / connections in totality are:

Within a PWA ( service workers <--> web worker ).

That will sync any tabs on the same computer.

Good old post message. Hence why @JohnStarich 's go-webworker is the way to go..

Between a PAW and a server ( Service worker <--> golang NATS server ). That will sync any tab between computers.

WASM nats.go client and NATS Server
Need Presence my precious ( sorry lord of rings pun ).  Got to look at how to do that in nats ...

On Desktop Between a GUI and spawned gui windows.  ( Desktop main gui <--> desktop spawned  gui windows ).

That will sync a single window  to any spawned windows on the same computer

Golang Bus between windows.  I want to try to make johns go-webworker be agnostic enough to work here.  Just a matter of adapting the current Desktop bus code with John's code. Use go build tags and file names to keep sane.

On Desktop between Service ( launchd, etc ) and many GUI ( Desktop Service <--> desktop gui(s) ).

That will sync all windows on same computer  with NATS Leaf on that same computer.
Each Window will then sync with its swamned windows using 3 ( above )

Lastly On anything ( Golang NAT Server  (s) to Browser or Desk ).

This is NATS Server in HA mode, etc  talking to everything...

I really need a diagram :)

Am going to close this as we got off topic


Dockerhub

Would be great to have a docker image published on to dockerhub. A quick search did not show any images there. Is there a plan to publish to dockerhub ?

I've published an image at ghcr.io/pl4nty/markwhen:latest

Would I be correct in assuming that everything needed to render the calendar / timeline / etc are packaged into this single image ?
I see on the read me that selfhosted versions needs to host the views separately - does this mean calendar, timeline, parser, viewclient, etc needs to be hosted on local ?
Can you pls provide an docker compose example, that can get the calendar / timeline / etc all working via docker ?

@accforgithubtest this repo only includes the timeline, if you want other views you'll need to update [useViewProviders](https://github.com/mark-when/markwhen/blob/main/src/Views/useViewProviders.ts) and build your own image. this is covered in the readme

Seems like views can be added from the UI too, but I can't find that option when running locally

I just added comments to an related issue -
https://github.com/mark-when/markwhen/issues/71#issuecomment-1707355584

hey @pl4nty - can you pls share the dockerfile you used, so I can try something similar for the other views ?

@accforgithubtest https://github.com/mark-when/markwhen/blob/25779d9238477ec76eb988a0c6a0af754fdf624e/Dockerfile

@accforgithubtest I think I just used https://github.com/mark-when/markwhen/blob/25779d9238477ec76eb988a0c6a0af754fdf624e/Dockerfile with default views

thanks for the quick reply @pl4nty !


Manual sleep before HX711 read?

If the read is a busy loop, maybe that's wasting energy and I instead can sleep until it's ready.

It does seem to be a busy loop, the HX711 driver just does "while not ready, delay(0)".
I should instead try to estimate when it will be ready and do some kind of proper low power sleep until then.
I should also consider just hooking up an interrupt to the DOUT pin, which is what "is ready" actually checks: When DOUT goes low, it means data is ready for reading.
And I should do some timing again to see which parts of the program take how much time.
And then consider optimizing the rest of the code.

Subset of #74


Mount error while deploying SWAPP from release pipeline

Hi,
I've been trying to do a deployment from a release pipeline by using the preview "Build and deploy an Azure Static Web App" Preview task (v.0.187.1). The app is already built using a build pipeline, so I only want to push it to the azure web app.
I already tried a lot of setting, but I always get the following error:
2021-06-06T07:16:02.3098936Z ##[debug]found: '/usr/bin/bash'
2021-06-06T07:16:02.3100454Z ##[debug]which '/usr/bin/bash'
2021-06-06T07:16:02.3101217Z ##[debug]found: '/usr/bin/bash'
2021-06-06T07:16:02.3104325Z ##[debug]testing directory '/home/vsts/work/_tasks/AzureStaticWebApp_18aad896-e191-4720-88d6-8ced4806941a/0.187.1'
2021-06-06T07:16:02.3109454Z ##[debug]/usr/bin/bash arg: /home/vsts/work/_tasks/AzureStaticWebApp_18aad896-e191-4720-88d6-8ced4806941a/0.187.1/launch-docker.sh
2021-06-06T07:16:02.3110679Z ##[debug]args=undefined
2021-06-06T07:16:02.3117260Z ##[debug]app_location=_E-NEXT_Frontend/dist
2021-06-06T07:16:02.3118019Z ##[debug]app_build_command=undefined
2021-06-06T07:16:02.3118655Z ##[debug]output_location=undefined
2021-06-06T07:16:02.3119251Z ##[debug]api_location=undefined
2021-06-06T07:16:02.3119862Z ##[debug]api_build_command=undefined
2021-06-06T07:16:02.3120476Z ##[debug]routes_location=undefined
2021-06-06T07:16:02.3122209Z ##[debug]skip_app_build=true
2021-06-06T07:16:02.3123760Z ##[debug]azure_static_web_apps_api_token=***
2021-06-06T07:16:02.3136217Z ##[debug]exec tool: /usr/bin/bash
2021-06-06T07:16:02.3136939Z ##[debug]arguments:
2021-06-06T07:16:02.3137875Z ##[debug]   /home/vsts/work/_tasks/AzureStaticWebApp_18aad896-e191-4720-88d6-8ced4806941a/0.187.1/launch-docker.sh
2021-06-06T07:16:02.3142124Z [command]/usr/bin/bash /home/vsts/work/_tasks/AzureStaticWebApp_18aad896-e191-4720-88d6-8ced4806941a/0.187.1/launch-docker.sh
2021-06-06T07:16:02.5961816Z Unable to find image 'mcr.microsoft.com/appsvc/staticappsclient:stable' locally
2021-06-06T07:16:02.9296499Z stable: Pulling from appsvc/staticappsclient
2021-06-06T07:16:02.9306253Z 1e987daa2432: Pulling fs layer
--- shortened for brevity ---
2021-06-06T07:17:14.0571118Z 6284ff0d4871: Pull complete
2021-06-06T07:17:14.0611873Z Digest: sha256:57b6be4b785eccc666462f284457b72b0c09f6f5e6d067b965750233a417fd0e
2021-06-06T07:17:14.0629706Z Status: Downloaded newer image for mcr.microsoft.com/appsvc/staticappsclient:stable
2021-06-06T07:17:14.2881573Z docker: Error response from daemon: OCI runtime create failed: invalid mount {Destination::/working_dir Type:bind Source:/var/lib/docker/volumes/8d90060c5907d68a281862c7f31dcb71efe24e52511ac78682a1e5e5dd27b0af/_data Options:[rbind]}: mount destination :/working_dir not absolute: unknown.
2021-06-06T07:17:14.2886252Z time="2021-06-06T07:17:14Z" level=error msg="error waiting for container: context canceled"
```
What am I doing wrong?

Hi, I am trying to do the same and face the exact same issue. Did you find a solution?
What I want to achieve is that the Azure DevOps build pipelines do the build, publishes the artifact (called drop for example), and then in the Releases the Deploy Azure Static Web App (Preview) task is used only for deploying to Azure Static Web App.
In the app_location input I used the drop folder with no luck.

Hi @mud1 ,
Currently we've managed to get it working by using a bash script:
docker run --entrypoint "/bin/staticsites/StaticSitesClient" --volume "$WORKDIR"/"$ARTIFACTNAME"/"$DISTFOLDER":/root/build mcr.microsoft.com/appsvc/staticappsclient:stable upload --skipAppBuild true --app /root/build --apiToken $DEPLOYMENT_TOKEN

you will need the four variables defined (actually you could put all the 3 WORKDIR, ARTIFACTNAME and DISTFOLDER into one single variable).
This works well for me, however doesn't feel right, as any change to the underlying staticsitesclient will lead to a break, that's why I would like to have this issue solved using the dedicated release task.

@mkarmark
Answering your question from the other issue, the only yaml I can pull out of the release pipeline was the one provided.
The release pipeline is triggered by an artifact from our build pipeline that runs on merges. The build pipeline just copies the artifacts over to the staging area.
How much of this would be needed? The artifact is basically the dist folder for the app, so just index.html css and javascript files.

Having same problem.

docker run --entrypoint "/bin/staticsites/StaticSitesClient" --volume "$WORKDIR"/"$ARTIFACTNAME"/"$DISTFOLDER":/root/build mcr.microsoft.com/appsvc/staticappsclient:stable upload --skipAppBuild true --app /root/build --apiToken $DEPLOYMENT_TOKEN

That worked for me. Notice that I had to change:  --volume "$WORKDIR"/"$ARTIFACTNAME"/"$DISTFOLDER" to  --volume "$(WORKDIR)/$ARTIFACTNAME/$(DISTFOLDER)":/root/build the " where between the backslashes were causing me errors I also expand the variables in compile time

This is possibly related to a recent bug in containerd: https://github.com/containerd/containerd/issues/5547
https://developercommunity.visualstudio.com/t/azure-pipeline-fails-with-oci-error/1444539

@dondracek we are currently investigating this issue.  Same YAML works fine in a build pipeline

Same as @MaximBalaganskiy, works fine in build pipeline but mount destination :/working_dir not absolute: unknown when done through release.

Currently having the same issue. Anyone that has found a fix?

See also this workaround that's been shared on the PR that addresses this issue with the task: https://github.com/microsoft/azure-pipelines-tasks/pull/14807#issuecomment-868593099

Hey everyone,
I currently also have a Pipeline that builds a NextJS project and publish the artficat. Here's the relevant YAML:
stages:
- stage: Build
  displayName: Build stage

  jobs:
  - job: Build
    displayName: Build
    pool:
      vmImage: ubuntu-latest

      steps:

      - task: NodeTool@0
        inputs:
          versionSpec: '14.17.1'
        displayName: 'Install Node.js'

      - task: Bash@3
        displayName: Build
        inputs:
          targetType: 'inline'
          script: |
            npm install
            npm run build
        env:
          NEXT_PUBLIC_AZURE_IMAGE_STORAGE_BASE_URL: '$(NEXT_PUBLIC_AZURE_IMAGE_STORAGE_BASE_URL)'
          NEXT_PUBLIC_CLOUDFLARE_DOMAIN: '$(NEXT_PUBLIC_CLOUDFLARE_DOMAIN)'

- stage: Artifact
  displayName: Artifact stage

  jobs:
  - job: Artifact
    displayName: Publish artifact
    pool:
      vmImage: ubuntu-latest

      steps:
      - task: PublishBuildArtifacts@1

      - publish: $(Build.ArtifactStagingDirectory)/WebApp
        artifact: drop
      - download: current
        artifact: drop

And here's the bash script I use in the Release pipeline.
docker run --entrypoint "/bin/staticsites/StaticSitesClient" --volume "$(System.DefaultWorkingDirectory)/WebApp/drop":/root/build mcr.microsoft.com/appsvc/staticappsclient:stable upload --skipAppBuild true --app /root/build --apiToken $DEPLOYMENT_TOKEN

And here's the log from the Release pipeline. I don't think I'm getting the right folder pointed out? Or am I doing something wrong with the publish artifact step on the pipeline?
2021-07-05T16:50:57.4519734Z Status: Downloaded newer image for mcr.microsoft.com/appsvc/staticappsclient:stable
2021-07-05T16:50:57.9565149Z DeploymentId: 5e916cea-d7c7-4a53-b04b-b7444b191d46
2021-07-05T16:50:57.9565831Z
2021-07-05T16:50:58.1025222Z App Directory Location: '/root/build' was found.
2021-07-05T16:50:58.1025825Z No Api directory specified. Azure Functions will not be created.
2021-07-05T16:50:58.8486734Z Skipping step to build /root/build with Oryx
2021-07-05T16:50:58.8511880Z Failed to find a default file in the app artifacts folder (root/build). Valid default files: index.html,Index.html.
2021-07-05T16:50:58.8512752Z If your application contains purely static content, please verify that the variable 'app_location' in your workflow file (located in .github/workflows) points to the root of your application.
2021-07-05T16:50:58.8513591Z If your application requires build steps, please validate that a default file exists in the build output directory.
2021-07-05T16:50:58.8514055Z
2021-07-05T16:50:58.9048672Z
2021-07-05T16:50:58.9049448Z For further information, please visit the Azure Static Web Apps documentation at https://docs.microsoft.com/en-us/azure/static-web-apps/
2021-07-05T16:50:58.9050500Z If you believe this behavior is unexpected, please raise a GitHub issue at https://github.com/azure/static-web-apps/issues/
2021-07-05T16:50:58.9051041Z Exiting
2021-07-05T16:50:59.0458590Z ##[error]Bash exited with code '1'.
2021-07-05T16:50:59.0533234Z ##[section]Finishing: Deploy Static Web App

Thanks all

Same error from the release pipeline:
2021-08-19T16:46:26.3710216Z ==============================================================================
2021-08-19T16:46:26.3710566Z Task         : Deploy Azure Static Web App
2021-08-19T16:46:26.3710862Z Description  : [PREVIEW] Build and deploy an Azure Static Web App
2021-08-19T16:46:26.3711106Z Version      : 0.187.1
2021-08-19T16:46:26.3711311Z Author       : Microsoft Corporation
2021-08-19T16:46:26.3711543Z Help         : https://aka.ms/swadocs
2021-08-19T16:46:26.3711829Z ==============================================================================
2021-08-19T16:46:27.1580955Z [command]"C:\Program Files\Git\bin\bash.exe" D:\a\_tasks\AzureStaticWebApp_18aad896-e191-4720-88d6-8ced4806941a\0.187.1\launch-docker.sh
2021-08-19T16:46:30.8593608Z Unable to find image 'mcr.microsoft.com/appsvc/staticappsclient:stable' locally
2021-08-19T16:46:31.9420526Z stable: Pulling from appsvc/staticappsclient
2021-08-19T16:46:32.1720766Z docker: image operating system "linux" cannot be used on this platform.
2021-08-19T16:46:32.1722143Z See 'docker run --help'.
2021-08-19T16:46:32.1892084Z
2021-08-19T16:46:32.2138290Z ##[section]Finishing: Deploy Static Web App```

Thank you

@Sergey-Nosov-GH Looks like your build agent is running Windows. This task can only be run on Linux agents at this time.

For those of you trying to use the task from a release pipeline, version 0.187.1 should contain a fix that uses the correct default directory. You can also override the working directory using the workingDirectory input.
Keep in mind that app_location and api_location are relative to the working directory. It won't work if you put an absolute path in there.

@anthonychu please explain where do I have an error in my logic?
My source code located in git - Azure DevOps
I have a build pipeline that has the following steps:

Pulumi Azure Pipelines Task (creates Sql server, database, static site)
Azure SQL DacpacTask - which can run only on windows agent
Deploy Azure Static Web App - which, turns out, run only on Linux

I need "Deploy Azure Static Web App" to build my static website. And I need dacpac task - so that azure functions can save data to db.
How I suppose to behave if 2 tasks can only run on opposite platforms? What I'm missing here?


fix validation

Required items, please complete
Change(s):

See guidance below

Reason for Change(s):

See guidance below

Version Updated:

Required only for Detections/Analytic Rule templates
See guidance below

Testing Completed:

See guidance below

Checked that the validations are passing and have addressed any issues that are present:

See guidance below

Guidance <- remove section before submitting

Before submitting this PR please ensure that you have read the following sections and filled out the changes, reason for change and testing complete sections:
Thank you for your contribution to the Microsoft Sentinel Github repo.

Details of the code changes in your submitted PR.  Providing descriptions for pull requests ensures there is context to changes being made and greatly enhances the code review process.  Providing associated Issues that this resolves also easily connects the reason.

Change(s):

Updated syntax for XYZ.yaml

Reason for Change(s):

New schema used for XYZ.yaml
Resolves ISSUE #1234

Version updated:

Yes
Detections/Analytic Rule templates are required to have the version updated

The code should have been tested in a Microsoft Sentinel environment that does not have any custom parsers, functions or tables, so that you validate no incorrect syntax and execution functions properly.  If your submission requires a custom parser or function, it must be submitted with the PR.

Testing Completed:

Yes/No/Need Help

Note: If updating a detection, you must update the version field.

Before the submission has been made, please look at running the KQL and Yaml Validation Checks locally.
https://github.com/Azure/Azure-Sentinel#run-kql-validation-locally

Checked that the validations are passing and have addressed any issues that are present:

Yes/No/Need Help

Note: Let us know if you have tried fixing the validation error and need help.

References:

Guidance for Detection checks
General contribution guidance
PR validation troubleshooting

I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer.

Hello @ling-tx please change the text Azure Sentinel to Microsoft Sentinel in create ui and maintemplate file

And can you please describe what content you have added/modified in this solution. If yes modified/added or removed please commit those changes as well.
And please upload the zip package as well which contains the createui and maintemplate file only.

may I know what these errors mean?
Could not identify json file as a Main Template. Skipping File path: Solutions/IronNet IronDefense/Playbooks/IronNet_UpdateIronDefenseAlerts/azuredeploy.json
Could not identify json file as a Main Template. Skipping File path: Solutions/IronNet IronDefense/Playbooks/IronNet_UpdateIronDefenseAlerts/azuredeploy.json
Could not identify JSON file as mainTemplate.json or createUiDefinition.json. Skipping. File path: Solutions/IronNet IronDefense/Playbooks/IronNet_UpdateIronDefenseAlerts/azuredeploy.json
Could not identify json file as a Main Template. Skipping File path: Solutions/IronNet IronDefense/Playbooks/IronNet_UpdateSentinelIncidents/azuredeploy.json
Could not identify json file as a Main Template. Skipping File path: Solutions/IronNet IronDefense/Playbooks/IronNet_UpdateSentinelIncidents/azuredeploy.json
Could not identify JSON file as mainTemplate.json or createUiDefinition.json. Skipping. File path: Solutions/IronNet IronDefense/Playbooks/IronNet_UpdateSentinelIncidents/azuredeploy.json
Could not identify json file as a Main Template. Skipping File path: Solutions/IronNet IronDefense/Workbooks/IronDefenseAlertDashboard.json
Could not identify json file as a Main Template. Skipping File path: Solutions/IronNet IronDefense/Workbooks/IronDefenseAlertDashboard.json
Could not identify JSON file as mainTemplate.json or createUiDefinition.json. Skipping. File path: Solutions/IronNet IronDefense/Workbooks/IronDefenseAlertDashboard.json

Please Repackage the solution using V2 tool. This solution is not packaged properly i recommend you to repackage the solution using V2 tool.
Please go through this Readme file for proper instructions.
https://github.com/Azure/Azure-Sentinel/blob/master/Tools/Create-Azure-Sentinel-Solution/V2/README.md

Please Repackage the solution using V2 tool. This solution is not packaged properly i recommend you to repackage the solution using V2 tool.
Please go through this Readme file for proper instructions.
https://github.com/Azure/Azure-Sentinel/blob/master/Tools/Create-Azure-Sentinel-Solution/V2/README.md

https://github.com/Azure/Azure-Sentinel/blob/master/Tools/Create-Azure-Sentinel-Solution/V2/README.md

After seeing your comment, I notice there is v2 tools. Originally I use createSolution.ps1.
I tried to use createSolutionV2.ps1 to create solutions but found the generated solution is much different from v1
Is it required to use v2 tool? If using v2 tool, does it mean I need to modify my json files?

https://github.com/Azure/Azure-Sentinel/blob/master/Tools/Create-Azure-Sentinel-Solution/V2/README.md

After seeing your comment, I notice there is v2 tools. Originally I use createSolution.ps1. I tried to use createSolutionV2.ps1 to create solutions but found the generated solution is much different from v1 Is it required to use v2 tool? If using v2 tool, does it mean I need to modify my json files?

No @ling-tx you dont need to modify your json file, just commit the changes which i asked for input file."
After that repackage the solution using v2 tool

@v-prasadboke I tried to verified new solution generated by v2 tool by "Deploy a Custom Template" on the portal, it deployed failed.
compared v1 and v2 generated solutions, they are quite different. that's why I confused.
v1 solution:

v2 solution:

v2 solution lack some necessary parameters. I use the same json file.

Hello @ling-tx let me look into this

https://github.com/Azure/Azure-Sentinel/pull/8328/files/56a05b42156c20b10ed7fdc711a3669e347f7364#r1241890466

Hello @ling-tx as per new guidelines issued by Microsoft Sentinel, please repackage the solution using V3 tool
Please go through this readme file on how to use the V3 tool

Hello @ling-tx any updates on the above

Hello @ling-tx how were you able to repackage the solution with v3 tool, because your branch is not updated with master and i cant see the V3 folder in your branch.

Please repackage the solution With v3 and commit the changes, i wont be able to get what issues you are facing with the deployement

Hello, I upload the solution with v3. if deploy mainTemplate.json, it doesn't create 2 log app as expected

Please add workbookmetadata of workbooks in " Azure-Sentinel\Tools\Create-Azure-Sentinel-Solution\V2\WorkbookMetadata\WorkbooksMetadata.json "

After all the changes done, please repackage the solution again

Hello @ling-tx any updates On the above changes requested

I fix the comments and create new package.
The UI of playbook still lack necessary input parameter

When verify mainTemplate.json, I see warning

Hello @ling-tx,
Thanks for the updates.
Will be investigating the issue you are facing, You can expect an update till 25 Jul 2023.

Hello @ling-tx, While custom deploying the playbook I got this error.

Can you please have a look at this.

And also if possible can we schedule a call regarding this. I work in IST time zone, can you please suggest a time as per your availability. I'm usually available between 2:00 PM to 6:00 PM ( IST time zone ).
Thank you,
Prasad Boke.

Hello, I am in CST timezone. Is it ok we meet at 5:30PM IST timezone?

Thank you @ling-tx, I'll schedule a call for 5:30 PM IST which is 7:00 AM CST and send you the invitation link for the meet.

Hello, my email is<EMAIL_ADDRESS>thanks

Thank you @ling-tx, Will be scheduling a call for 5:30 PM IST 27 Jul 2023

Hello @ling-tx, as discussed in the call. Please go with the changes, Im trying to find the playbook which I was gonna share it with you.
I'll share it ASAP as i find it.
Thank you.

Hello @ling-tx, we are still examining the issue. You can expect an update till 03 Aug 2023.

And please also commit the changes which were requested earlier. Thank you.

Hello @ling-tx, I've scheduled a call for tomorrow. Scheduled the meet for 7:00 AM (CST) 07 Aug 2023 Tuesday.

Hello @ling-tx, Thank you for your time. And as I ensured I'll look at this issue and update you about the same soonest.

@v-prasadboke,
@ling-tx is on PTO until Monday Aug 21.  I can cover for her if you need to schedule a meeting before then.

Hello there, @thao2. Thank you for informing me. I'll contact her once when she returns back.

hello, @v-prasadboke, I am available tomorrow. thanks.

Hello @ling-tx, Sorry for the inconvenience. But due to some other conflicts it was not possible for me to attend the call.
Is it okay if we reschedule this call for tomorrow.

@v-prasadboke tomorrow is fine. please book the meeting. thanks.

Thank you @ling-tx, Scheduling the meet for tomorrow.

Hello @ling-tx, As discussed in the call. Try generating the playbook arm template and continue with commits.
Please reach out to us if anything needed.
Thank you very much.

The Playbook_ARM_Template_Generator.ps1 can't work on mac platform

Hello @ling-tx, Thank you for bringing this upfront. As we have scheduled a call we will have this discussed in it.

Hello @ling-tx, As discussed in the call regarding the issue you are facing we will have someone from the repackaging tool team to look in this.
Thanks,
Prasad.

Hello @ling-tx, We are still discussing the issue you are facing. Will update you till tomorrow about this.
Thanks.

Hello @ling-tx, The Playbook parameters wont get displayed on the custom deploy page while deploying the maintemplate.
As for the parameters, It will be visible after deploying the maintemplate and selecting the playbook. You can add parameters for the playbook, on create playbook page.

Hello @ling-tx, Reason might be Playbook metadata which needs to filled. If all the entities of playbook metadata are empty then the automation blade of azure portal fails to load.
I would recommend to fill all the playbook metadata entities and then repackage the solution.
Try Deploying the maintemplate after this.

Hello @ling-tx, Hope you are doing well. As communicated on the chat, Please continue filling all the metadata details of the playbook and thus with repackaging the solution after filling the details.
Thank you.

Hello @ling-tx, It's been a while I haven't heard from you. Hope you are fine.
Also please provide some updates to the above comment.

Hello @ling-tx, Please respond to the above comments.

Hello @ling-tx, Please respond to the above comments.

Hello @ling-tx, Please respond to the above comments.

Hello @ling-tx, Hope you are good. Just wanted to know if there's any updates on the above discussions.
Thanks.

Hello @ling-tx, It's been a long time we haven't heard anything from you. Hope you are doing well, Just wanted to check if there's any progress on the above requested changes.
Thanks.

Hello @ling-tx, Please respond to the above mentioned comments.
Thanks.

We wanted to check on the status of PR #8328 . PR is pending for more than 30 days. Please let us know if you need any assistance to review this PR. Per our standard operating procedures if no response is received in the next 7 business days, we will close this PR. Thank you for your cooperation.

Hello @v-prasadboke,
First, I'd like to say your dedication with the frequent postings you've made with no response by Ling to this issue is extremely commendable.  Second, I wanted to let you know that IronNet furloughed its employees on Sept 2, and ceased operations yesterday, Sept 29th, 2023.  More info here:  https://ir.ironnet.com/financials/all-sec-filings.
I just wanted to make a courtesy post so you don't waste any more time on this, but I don't expect this issue to be picked up again (I don't speak for IronNet).

Hello @v-prasadboke,
First, I'd like to say your dedication with the frequent postings you've made with no response by Ling to this issue is extremely commendable. Second, I wanted to let you know that IronNet furloughed its employees on Sept 2nd, 2023, and ceased operations yesterday, Sept 29th, 2023. I don't speak for IronNet, but wanted to let you know so you don't waste any more time on this as I don't expect this issue to be picked up again
More info here: https://ir.ironnet.com/financials/all-sec-filings.

Hello @thao2, thank you for update, we are sorry to hear this about IronNet.inc. We are closing this PR as per our standard procedure. Thank you for you co-operation.


DRILL-4682: Allow full schema identifier in SELECT clause

changed SqlBracketlessSyntax logic in the DrillCompoundIdentifier;
added checking of using full schema name in column names;
added unit test testColumnNamesWithSchemaName;

@jinfengni Could you please review the changes

I feel it might be better to work on this issue after Drill rebases Calcite. I debugged a bit in SqlValidator, and seem that the code in Drill's forked Calcite is different from what Calcite master has. It's possible that some of patches (star column) in Drill's forked Calcite changes the behavior, and hence run into problem with the subquery cases.  Since star column logic has been merged to Calcite master, it's better to try with this patch after rebasing on top of Calcite master, in stead of coming up with a temporary solution with restrictions.

@jinfengni Agree. It will be better to merge this patch after rebasing to the last version of calcite. Because currently I'm not sure how to decide this task in differ manner than mine. Do we put this PR on hold?

@vdiravka Are you planning to complete this change?


The release of bundler 2.0 breaks travis-ci tests

Affected Puppet, Ruby, OS and module versions/distributions

Puppet: 4
Ruby: 2.1.9
Distribution: ubuntu trusty (as provided by travis-ci)
Module version: master, probably any version

How to reproduce (e.g Puppet code you use)
Run any travis-ci build.
What are you seeing
travis-ci failes with an error, which is different from a normal build failiure.
Output log
https://travis-ci.org/voxpupuli/puppet-python/jobs/474908824
The program 'bundle' is currently not installed. To run 'bundle' please ask your administrator to install the package 'bundler'```

## Workaround
`diff --git a/.travis.yml b/.travis.yml
index 06169e3..e20c74e 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -5,6 +5,8 @@ language: ruby
 cache: bundler
 before_install:
   - rm -f Gemfile.lock
+  - gem install bundler -v '< 2' --conservative
+
 script:
   - 'bundle exec rake $CHECK'
 matrix:
`

## More Information
https://bundler.io/blog/2019/01/04/an-update-on-the-bundler-2-release.html

Hi,
This got already fixed in our modulesync_config repo: https://github.com/voxpupuli/modulesync_config/pull/535
We just have to roll it out to our modules.


Make getting started with SQLite topic more helpful

Helpfulness rating is very low.

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

ID: adb04585-f54b-70c0-e847-b044b388a4d5
Version Independent ID: 5e37f568-0621-a082-c75a-d2adf94dce8d
Content: Getting Started on .NET Core - New database - EF Core
Content Source: entity-framework/core/get-started/netcore/new-db-sqlite.md
Product: entity-framework
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

9.2 KPV last month. Only 3 ratings so not statistically significant. @tdykstra  or myself will do a pass and see if we can get better reviews.

This could be related to the fact SQLite is common for Xamarin o UWP (I don't think many are building .NET Core console apps), and those require additional workarounds (which are covered in other topics).

I went through the tutorial and only found trivial things to fix.  It works flawlessly with .NET Core 2.1, was already updated for that version.  3 reviews isn't enough to draw reliable conclusions, but @divega might be right that people come here wanting Xamarin or UWP info and consider it unhelpful. Could also be some want an ASP.NET version, as this one doesn't tell you how to deal with ASP.NET Core DI.  Also we don't have much guidance on how to deal with SQLite migrations limitations, beyond saying they should delete and re-create the database.

Thanks @tdykstra. I will close for now. If we get more information we can revisit.


Unable to show the images

Hi,
I am trying to use this plugin in IOS. But I am getting file path like this : -
"cdvphotolibrary://photo?photoId=ADB24867-0CCB-4207-923A-DC9D44233434%2FL0%2F001"
I have tried to put that on img src but it is not showing. Some of the files are returning the file url like this : -
filePath: "/var/mobile/Media/DCIM/100APPLE/IMG_0652.JPG"
I am able to show those but not able to show "cdvphotolibrary".
Can anybody tell me how can I show this.

I'm guessing you're using the ionic wkwebview? If you are, I'm having the same issue as you are.
ionic wkwebview has a warning for this.

Note: Core cordova plugins also allow you to reference a file via the cdvfile:// protocol. Unfortunately, we cannot rewrite this path as it is something that gets resolved in native code. We suggest that when ever you reference a file, use the full path for rewrites, not cdvfile://.

I'm still trying to find a workaround.

is there any way to resolve it?

+1
Same issue

+1


Add route to lookup identity by DID

See #583
This is more of a starting point - the functionality works, but I'm pretty certain the API spelling is not what we want.
I was struggling with the best way to provide this functionality - it seems like it must be a query param, because / is a valid char for query params but not for path params. Assuming we do use a query param, it would also be nice to flag it as "required" from the Swagger perspective.
Side note: you can already query the /namespaces/{ns}/identities endpoint with a query param for did, but you have to know the namespace you're looking for in that case.

Codecov Report

Merging #617 (419821d) into main (bdf4b4a) will decrease coverage by 0.03%.
The diff coverage is 41.66%.

:exclamation: Current head 419821d differs from pull request most recent head 803f3e4. Consider uploading reports for the commit 803f3e4 to get more accurate results

@@             Coverage Diff             @@
##              main     #617      +/-   ##
===========================================
- Coverage   100.00%   99.96%   -0.04%
===========================================
  Files          309      306       -3
  Lines        18705    18309     -396
===========================================
- Hits         18705    18302     -403
- Misses           0        7       +7

Impacted Files
Coverage Δ

internal/networkmap/data_query.go
91.02% <0.00%> (-8.98%)
:arrow_down:

internal/networkmap/manager.go
100.00% <ø> (ø)

internal/apiserver/route_get_net_did.go
100.00% <100.00%> (ø)

pkg/fftypes/pin.go
100.00% <0.00%> (ø)

pkg/fftypes/data.go
100.00% <0.00%> (ø)

pkg/fftypes/batch.go
100.00% <0.00%> (ø)

pkg/fftypes/event.go
100.00% <0.00%> (ø)

pkg/fftypes/namespace.go
100.00% <0.00%> (ø)

pkg/fftypes/operation.go
100.00% <0.00%> (ø)

internal/config/config.go
100.00% <0.00%> (ø)

... and 33 more

Continue to review full report at Codecov.

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

Made a couple more enhancements:

The DID resolution API uses the same cached lookup API that other code paths use in the codebase.
Creation of a new identity can also use a name-or-UUID approach


Teltonika FM1120 (Module) resends sent data

Teltonika resends sent data repeatedly with no change in records.
Based on FMXXXX Protocols documentation:
After server receives packet and parses it, server must report to module number of data received as integer (four bytes). If sent data number and reported by server doesn’t match module resends sent data.
How can I solve this problem?

Hi,
can you share that "FMXXXX Protocols documentation" with me, so I could figure out how this issue can be solved ? You're welcome to attach it right here.
Thanks!

Hi
Thanks I solved the issue by adding the following code to teltonika.js:
function parseDataPacket(socket, data) {
....
Line Number: 155
var mb = new Buffer(4);
mb.fill(0);
mb[3] = buf[i-1];
socket.write(mb);


Avoid overplotting in movie? / possible pylab.cla or clf

Hi there,
I'm relatively new to python and was interested in testing out your library for rendering
a random walk process with particle interactions. However I noticed that when plotting, a function like  pylab.cla or clf did not exist. Also the online documentation suggested there was none available.
I am aware that in a previous thread you handled the same topic, however I have been unable to reproduce a significant result using your mentioned workaround. Is there a possible workaround that would work in my case?
The code below is only a snippet of the entire random walk process function where the output, "walk", is the array to be plotted.
 fig = ipv.figure()

 runs = len(walk[0])
 n = #user defined parameter
 size = #user defined parameter
 r = #user defined parameter

 wx = np.zeros([runs,n])
 wy = np.zeros([runs,n])
 wz = np.zeros([runs,n])

   for i in range(runs):
        for j in range(n):

             wx[i,j] = walk[j,i,0]
             wy[i,j] = walk[j,i,1]
             wz[i,j] = walk[j,i,2]

 x = np.vstack(wx)
 y = np.vstack(wy)
 z = np.vstack(wz)

 ani = ipv.scatter(x, y, z, marker='sphere', size=r)
 ipv.xyzlim(-size, size)
 ipv.animation_control(ani, interval=200)
 ipv.show()

 bounds = np.zeros([runs])+r

 def set_view(figure, framenr, fraction):

      ani = ipv.scatter(x[framenr], y[framenr], z[framenr], marker='sphere', size=r)
      ani.size = bounds

 ipv.movie('wave.gif', set_view, fps=1, frames=runs)

Many thanks!

Because ipyvolume is using widgets, you don't need to call scatter again (and best is you don't). If you do:
ani.x = x[framenr]
...

it will update it instead.
Also, you should be able to assign the whole array to it, and just change the sequence_index.

Thank you! Yes, this has drastically simplified my script. You were a great help.

Great, thanks for the reply


Implement Api endpoints

In this PR we implemented following features:
Created API endpoint to list all posts for a user.
Created API endpoint to list all comments for a user's post.
Created API endpoint to add a comment to a post.
Your API endpoints should receive JSON and respond JSON as well.

@DeliceLydia Thank you so much.


Add fixes from rubocop-cask 0.2.2

See caskroom/rubocop-cask#10, caskroom/rubocop-cask#11

I trust in my specs

Shows what I know :stuck_out_tongue_closed_eyes:

LGTM


Namespaces refactor

All tests pass, no errors or warnings.
API namespace renamed to Api.
Data namespace removed.
Entities namespace created.
Services namespace created.
Developer and Verification moved into Services namespace.
Closes #209

i'v pushed a set of small changes to the project and solution files (which i realise have now broken unit tests)
i will fix those tests, it's a bit silly as folder cases can't be changed easily...

i'v pushed a set of small changes to the project and solution files (which i realise have now broken unit tests)
i will fix those tests, it's a bit silly as folder cases can't be changed easily...

yeah - turns out git doesn't do renaming case-wise so i've had to do it manually...

yeah - turns out git doesn't do renaming case-wise so i've had to do it manually...


build: add GH action job for publishing docker image to registry

Fixes #103

Proof of Test: https://github.com/anujsinha3/post-disaster-comms/actions/runs/11186655421/job/31102166947


Electricity Meter

Describe the bug:
Data isn't pulled from my meters
Expected behavior:
Nothing is reported. Only "unknown"
Environment:

Home Assistant version: 0.111
Platform: sensor

Device:

Model: 'io:TotalElectricalEnergyConsumptionIOSystemSensor'
Type: CumulativeElectricPowerConsumptionSensor

Hi, thank you for the report, can you please follow instructions provided here to add device details, namely state definitions and command definitions?

Here you go!
`creationTime":1564688966000,
"lastUpdateTime":1564688966000,
"label":"Compteur",
"deviceURL":"",
"shortcut":false,
"controllableName":"io:TotalElectricalEnergyConsumptionIOSystemSensor",
"definition":{
"commands":[
        ],
        "states":[
           {
              "type":"ContinuousState",
              "qualifiedName":"core:ElectricEnergyConsumptionState"
           },
           {
              "type":"ContinuousState",
              "qualifiedName":"core:RSSILevelState"
           },
           {
              "values":[
                 "dead",
                 "lowBattery",
                 "maintenanceRequired",
                 "noDefect"
              ],
              "type":"DiscreteState",
              "qualifiedName":"core:SensorDefectState"
           },
           {
              "values":[
                 "available",
                 "unavailable"
              ],
              "type":"DiscreteState",
              "qualifiedName":"core:StatusState"
           }
        ],
        "dataProperties":[

        ],
        "widgetName":"CumulativeElectricPowerConsumptionSensor",
        "uiClass":"ElectricitySensor",
        "qualifiedName":"io:TotalElectricalEnergyConsumptionIOSystemSensor",
        "type":"SENSOR"
     },
     "states":[
        {
           "name":"core:StatusState",
           "type":3,
           "value":"available"
        },
        {
           "name":"core:ElectricEnergyConsumptionState",
           "type":1,
           "value":21744148
        }
     ],
     "attributes":[
        {
           "name":"core:MeasurementCategory",
           "type":3,
           "value":"electric/overall"
        },
        {
           "name":"core:PowerSourceType",
           "type":3,
           "value":"mainSupply"
        },
        {
           "name":"core:MeasuredValueType",
           "type":3,
           "value":"core:ElectricalEnergyInWh"
        }
     ],
     "available":true,
     "enabled":true,
     "placeOID":"c9594cac-f5e2-4e26-9688-5926954443d3",
     "widget":"CumulativeElectricPowerConsumptionSensor",
     "measurementCategory":"ELECTRIC_OVERALL",
     "type":2,
     "oid":"4ff9b811-1bd8-4edc-afb6-422ac7b87b45",
     "uiClass":"ElectricitySensor"`

could you checkout this branch instead of your HACS install of the component and try it out?
https://github.com/iMicknl/ha-tahoma/tree/fix_electrical_energy_sensor

Excellent! This works. You can merge it.

thanks!


Proposal for API Docs

Proposal for API Docs
API documentation is important! We need to define the following:

The user experience of viewing documentation.
How the content will be structured.

See existing docs and content: https://docs.microsoft.com/en-us/dotnet/core/api/system.
Requirements

The docs will represent multiple .NET products.
There must be good UX for navigating and filtering across the products.
The content will be open source and be moved to a single location (core-docs).

Assumptions
The APIs are the same across all products, including implemented interfaces and class inheritance. In some cases, this won't be true. If it's an exception, we'll decide that one implementation is the default and any others are correctly described in remarks.
Scope
The docs will document .NET APIs in:
Frameworks:

.NET Core (including for UWP)
.NET Framework
.NET Standard
Mono

Libraries:

ASP.NET / Core
EF
NuGet

UX
The user experience should bias towards seeing all APIs while providing soft-filters and cues to define which APIs are implemented in the various products. This is primarily an issue for the frameworks listed above, as opposed to the libraries.
Representation

One canonical representation per API (e.g. one page for System.String type; not one for Mono and one for .NET Framework).
Remarks will discuss product specific behavior, as appropriate.

URLS
URLs are easy to predict and hack.

https://docs.microsoft.com/en-us/dotnet/api/system
https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.list-1

Hacking means that the following URLs should go somewhere useful:

https://docs.microsoft.com/en-us/dotnet/api
https://docs.microsoft.com/en-us/dotnet/api/system
https://docs.microsoft.com/en-us/dotnet/api/system.collections
https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic

API Version Filtering
The default experience is viewing all .NET APIs, unfiltered by product or release. You can filter your view in terms of a product and version, such as .NET Framework 4.5, .NET Standard 1.5 or Mono 4.4.
Good example of version navigation: https://developer.android.com/reference/packages.html. The Android experience always shows all APIs and greys some of them out. That's a great experience. The "Platform" toggle on this page is not a good experience: https://docs.microsoft.com/en-us/active-directory/adal/microsoft.identitymodel.clients.activedirectory.
Describing Product Membership
The unfiltered view states all .NET products that support a given type/member, independent of filter. For example, when viewing pages in terms of Mono, you see "Introduced in Mono 1.1, .NET Framework 2.0, ...".
Two options for the filtered view:

Same as the unfiltered view.
State the "Introduced in" only for the filtered product (e.g. "Introduced in Mono 1.1" when viewing in terms of Mono 4.4 or Mono latest).

View Source
The "View source" should take you to the product source for a given type or member. It should take you to the specific product in the filtered view and a default product in the unfiltered view.
Product version is not important for this experience, only product.
Examples, for the Filtered case:

.NET Core: use CoreFX repo.
Mono: use Mono repo
.NET Framework: use referencesource repo or http://sourceof.net

For unfiltered, use a precedence algorithm, based on API availability information from reference assemblies:

corefx
referencesource
mono

Improve this Doc
Assumption: All docs are in the core-docs repo.
There are two ways to improve a document, either via updating the .cs file or the sidecar file. The "Improve this doc" button can only go to one place. Both files should contain a fully-qualified GitHub link to the other file (in a comment), so that it's easy to go from one file to the other.
Proposal: The button takes you to the .cs file. It's an open question of whether it should be in "edit" or "view" mode on GitHub.
Format

/// comments in .cs files, one file per type
The .cs files are skeletal versions of types, much like: https://github.com/dotnet/corefx/blob/master/src/System.Collections/ref/System.Collections.cs
Remarks are in a sidecar file, one per type.
These files include APIs for the union of all .NET products, enabling all .NET APIs to be documented.
No decoration of types or members in these files for .NET product membership (e.g. part of .NET Framework 4.5.1). We can query reference assemblies for that.

File structure

Flat structure under: https://github.com/dotnet/core-docs/tree/master/api
Example: https://github.com/dotnet/core-docs/tree/master/api/system.collections.generic

Versioning
The repository does not version, in terms of branching. There will not be branches for given .NET product releases. It's certainly fine to branch as part of a release, but the branch will be temporary. Given that the repository is for multiple products, the branches would not be meaningful / intuitive.
Relationship to Product Source
/// comments will be copied to product source on some cadence. One option is to snapshot /// comments from core-docs into corefx (for example) once per release, at the start of the release. This means that /// comments in product source will always be one release behind, but also won't disrupt product source at an unfortunate time.
Adding new APIs
There needs to be a tool that can take a set of reference assemblies and then add new APIs into the .cs files that are not present as stubs (empty /// comments).
Extra effort: A tool that prints out types and members that are missing /// comments.
Projects that already have /// comments
Projects (basically all the libraries) like ASP.NET Core already have /// comments within the product source. They don't have to change what they are doing.
In those cases, "View Source" and "Improve this Doc" will go to the same place, to the product source.
We need to decide for these projects where the sidecar files will go. Ideally, they'll go in the product repo, beside the files, potentially in a subdirectory. There isn't much value in splitting this content and requiring contributors for that content to clone two repos.
IntelliSense
IntelliSense will need to be generated from these same files. We'll need a similar tool that generates intellisense files from the .cs files plus a set of reference assemblies that defines a given platform.

This versioning model is yet undefined.

I'd love to be a part of this conversation ... as this is an issue that we are looking at in the mono API documentation world at the moment as well. How can I get involved @richlander?

Can view docs in terms of a product version, such as .NET Framework or .NET Standard

🙌🏼 This is precisely what we want to enable for mono/xamarin's API documentation :D

/// comments will be copied to product source on some cadence. One option is to snapshot /// comments from core-docs into corefx (for example) once per release, at the start of the release. This means that /// comments in product source will always be one release behind, but also won't disrupt product source at an unfortunate time.

I want to think about this in relation to the "View source" button on our API docs. It goes to the product source in GitHub (including line number). We should make sure this process doesn't make that link go to the wrong location.

@joelmartinez, @BillWagner - Just made a big update to the proposal, intended to answer your questions. Tell me what you think.

The default experience is viewing all .NET APIs, unfiltered by product or release. You can filter your view in terms of a product and version, such as .NET Framework 4.5, .NET Standard 1.5 or Mono 4.4.

Love the concept of the documentation UX being everything by default. The filtered view lets you change the context that you're viewing the documentation in.
There are a few more nuances though, to this context that probably need to be captured. For example, the System.Web namespace is available only on certain platforms. So how can we indicate that System.Web, is available when you're reading the documentation in the context of ASP.NET 4, but the story is different in the context of asp.net core; and furthermore, it's available in .net 4.5 and mono 4.x, but only when you're on windows and mac, not on ios and android.

ASP.NET Core doesn't use System.Web.

well, sorry ... yes, that was a poor example :P but the rest stands ... how can we indicate platform differences that don't necessarily correlate to version or frameworks?

I'm suggesting remarks.

Projects (basically all the libraries) like ASP.NET Core already have /// comments within the product source. They don't have to change what they are doing.

In those cases, "View Source" and "Improve this Doc" will go to the same place, to the product source.

👍 we do this on the EF project and writing docs is just part of the normal dev/code-review process

@mairaw Yes, there is going to be a lot of challenge to pull of these docs and the various buttons. There is a lot of value in this single uniform experience. We're going to need to some custom implementations to deliver it. The value is high enough that it's worth doing more to achieve it.
Certainly, it's possible to simplify it. I'm starting with the best (IMO) UX. It would be good to get some feedback on that UX, the value they see in it and whether they'd want something different.
I added some more content to accommodate your questions and comments.

I just realized that this discussion was taking place on a github issue, I participated on a Slack discussion yesterday along these lines.
With Mono, we are using an enhanced version of the original XML file format that was used to produce the ECMA API documentation.   The documentation code drop that we got a few years ago from Microsoft also came on a variation of this, which we imported into Mono.
To give you an idea of what this looks like, you can see the MSCorlib documentation in Mono:
https://github.com/mono/mono/tree/master/mcs/class/corlib/Documentation
Or you can look at our documentation for Urho for example:
https://github.com/xamarin/urho/tree/master/Docs
The markup is derived from the C# markup that is used inside the /// comments.
I think that this should be the format that we adapt.   Some of the benefits include:

The XML format is suitable to be easily manipulated by tools.  We have used this capability to use scripts to extensively to document patterns, common idioms, repetitive information, inferred information [1].

The XML format is easy to augment with extra metadata that scripts can manipulate.  We use this to maintain (generate, update, remove) "See Also" links based on actual type uses, member uses to show how a particulate piece of code is used, insert references to Recipes (full sample code available externally), inject samples.   The docs are updated as the sample evolve [2].

There is extensive tooling in Mono to update the XML documentation from one or more reference assemblies [3], and allows us to maintain a single set of docs that can target multiple platforms (MacOS, iOS, tvOS) as well as handling differences between our entire Classic vs Unified APIs (where we had to deal with a very large set of API changes introduced in the 32 to 64 bit upgrade), from the same set of docs.   The tool takes care of merging, annotating, flagging the APIs and the renderers can filter the data on demand.

The tool could be extended to maintain all the shared documentation, given a directory with all the available reference assemblies, it can compute attributes that determine how the documentation should be displayed.

Comprehensive Output We have both static page renderers (see https://developer.xamarin.com/api/namespace/UIKit/), or ASP.NET-based on-demand renders (http://docs.go-mono.com/?link=N%3AUIKit).   Both can be styled, in the links there, you can see Xamarin's styling vs Mono's project styling.

We have a rich editor You do not need to use XML to edit the files, you can use a rich client to edit them.   We currently have a rich Mac client [4].  Building a Winforms based one is easy, as all the shells provide is an HTML surface, the tree view, and the hotkeys/menu items.    We want to build an ASP.NET front-end, to allow anyone to edit docs live [5].

We have written link validators to ensure that links are correct.   Just a minor thing, but it gives you a taste of just how easy it is to do this sort of work.   The F# documentation updater for Urho gives you a good idea

Existing /// documentation can be imported.   Mdoc supports importing /// documentation into the Mondooc format.    If your team is already using /// you can keep using those, and import the results into the larger framework and still get all the benefits above.

We already imported the .NET docs once, they can be imported again.

The XML format already includes many annotations for smaller nuanced details.   And adding more is trivial: you add your xml marker, and you update the renderer source to either display something, trigger some JS to filter things and so on.

Doing the work on a C# file and editing inline comments sounds like a world of pain.   While not impossible to do this (after all, we can put a man on the moon) it is a shortcut that does not address any of the problems that are already addressed and will require additional engineering to think about solutions, while still providing a poor editing experience.
XML is just a very convenient format to use to maintain these docs.
The above covers some of the good things about using the XML format.   The C# format has merits, but compared to the above, they are measured in sub-atomic units.
[1] iOS doc population:
https://github.com/xamarin/maccore/blob/master/tools/docfixer-ios/populate.cs
iOS doc updates based on rich metadata:
https://github.com/xamarin/maccore/blob/master/tools/docfixer/document-generated-code.cs
See also [6]
[2] https://github.com/xamarin/maccore/blob/master/tools/doc-relcontent/doc-relcontent-merger.cs
[3] http://www.mono-project.com/docs/tools+libraries/tools/monodoc/generating-documentation/
[4] http://screencast.com/t/hB9LfwJD which alters an existing documentation set like this: https://gist.github.com/migueldeicaza/733164b0b19b107e941f2648e080cc68
[5] Caveat: because on the internet "anyone" can be a troll, we think that we should have some protective measures against vandalism.   That is, turn anonymous editing into a git branch.   A human would review, and merge those docs if they are good.   Trusted accounts could just commit directly to the repository.
[6] Urho documentation for common idioms, a simple F# script showing what we do with it:
https://github.com/xamarin/urho/blob/master/Docs/fill.fs

My perspective, as a writer, is that we absolutely do not want developers writing API documentation. Ditto for Random J. Webuser. Drafts or notes, maybe, but I've never seen documentation written by a developer that would pass muster as the global face of Xamarin or Microsoft to developers. And I don't expect that developers will accept the level of training required to write localizable documentation, nor that level of training that is required to produce documentation for ESL speakers. Whatever technical solution is settled upon, it needs to take into consideration globalization and localization, and the concomitant requirement of professional writers and, even, professional editorial support.
This, to me, is one of the stronger reasons for removing support for triple-whack comments as a matter of policy. My fluids professor used to say that no layperson thinks that they have an intuitive understanding of brain surgery, but they're convinced they have an intuitive understanding of fluid dynamics, which is at least as complicated. There is a possibly weaker corollary for technical documentation.

@MichaelNorman That's a good perspective, however (IMO), I don't think it has to be a case of starkly defined roles. In fact, we've found in our work that hard-lines in roles leads to lots of problems. We prefer significant overlap, which we find increases collaboration and shared accountability. It also increases the respect that folks have of people in other roles.
Couple thoughts to consider:

Here's some API content (first file I picked at random) from one of the libraries that I referred to above, where (to my knowledge) the engineering team manages the API docs: https://github.com/aspnet/EntityFramework/blob/dev/src/Microsoft.EntityFrameworkCore/DbContext.cs. Maybe those docs can be improved, but I would suggest that they are pretty decent.
We can certainly agree that writers have a better mastery over natural language. The developers will always have better mastery over the product, particular at the level of APIs (E2E is a different topic). The best solution (IMO) is one where we can take advantage of those separate skills.

The best combination is when writers, devs and PMs collaborate on docs. A joke, but what I'd like to see in terms of collaboration:

Writer: "That content is poorly written."
Dev: "It's inaccurate!"
PM: "Stop arguing. Pick something. This API has <1% usage. I'll show you the APIs you should be arguing about!"

That's obviously written from a PM perspective.
For .NET, the development team doesn't participate much in the API docs. That's for a set of reasons, none of them good. My hope is that we can make the API doc content and tooling much more accessible to those developers so that they can participate in the process. Once they do, I know that they will find technical inaccuracies in the well-written English that they read. With each of those fixed issues, the docs will become more accurate and the writers will learn a greater appreciation for the product, which will help generally.
On the /// comments as the source of truth, I'm very interested in the system that your team has been using. I just watch the screencast shared by @migueldeicaza  above. That looks really good. We were using an XML editor before. A custom app like that makes a ton of sense to me, since API docs are a narrow content domain.

@richlander, with all due respect, I think you are missing the point. Software development is a profession, a specialization. Writing technical documentation is a profession, a specialization. To say, "We don't want developers writing documentation," is no more unreasonable than saying, "We don't want writers introducing regressions into our software." It's not about turf. It's about why we don't want heart surgeons doing brain surgery, and vice versa.
We can talk about how "pretty good" the EF docs are. They do look good. How localizable are they? How well do they conform to the style guide for the organization? How well does the documentation fit in with the larger product documentation? How consistent is the voice between different docs in the same product, as well as between the documentation for the product and for other MS products? In short, how much of how good they look is due to seeing them with the undiscriminating eye of the reader, as opposed to the experienced eye of the writer?
Far from engendering respect for writers, conflating the roles and assuming that developers can match the quality and efficiency of the writing staff in their spare time denigrates the writing profession and the contribution of the writers. Now, you are not the first to be so accused! Writing has always been viewed as a cost center inside software organizations. Developers make the thing we sell, and writers just support the user. This is still true in an organization like Xamarin, no matter how supportive Xamarin has been with regard to the value of documentation. (And, boy, have they been supportive!) But this is a trend that needs especially pointed out now, because it is so pernicious, and because it always affects the toolchain.
As far as your PM comment about logistical focus and emphasis, that is already performed by the writing team at Xamarin, and always was while I was writing for Microsoft. Sure, there was dev and PM input, and it was always eagerly solicited. But to suppose that this is some novel value-add of the PM role that is routinely disregarded by the writers,... Well, suffice it to say we don't see eye to eye on that at the moment.
To address your point about what developers know and what writers know, that too misses the point in a subtle way. It's more useful to talk about what developers do and what writers do. For example, writers do writing and interviewing. Developers do software development. An oft unappreciated part of the practice of technical writing is soliciting not just correct information from the subject matter experts (SMEs), but teasing out the organizational structure of the product from the developer, and relating that to the (manifoldly diverse) customer (embedded within their cultural frameworks and our legal framework), not just more articulately than the developer can afford to do with the time allotted to her in her job, but systematically with a sensitivity to the issues to which I've alluded (And you have not addressed, tellingly!) about ESL, localization, style, homogeneity of voice, and so on.
For my money, the "lots of problems" that organizations face in regard to interdisciplinary squabbles are not solved by softening role lines or by conflating roles, but rather by changing procedural habits and educating all parties in better ways to collaborate.
I have been, in this post, direct, shall we say? I hope it is received in a firm but respectful way.

Thanks for sharing your insight. I've not done your job before, so I'll take what you say at face value, and of course, respectfully, as you hope.
We've now traveled a ways away from the topic of this issue, so I think I'll not go any farther into this topic, as much as I do think it is an interesting one to discuss further. Given that we now work for the same company, I think we'll indeed have the option available to us.

IMO I view the technical issue as one of modularity: the XML format has an advantage in that everything's in one place but, since it's hierarchical, there's an impedance mismatch when it comes to, e.g., platforms. We aren't going to solve that (or, rather, we ought not to hare off after one of the bazillion overly-complex attempts to hide/mitigate XML's hierarchical nature).
Since I was raised in the relational age, I tend to prefer my data orthogonal. So personally, remarks in one place, summaries in another, platform info in a 3rd would probably appeal to me if this were a green field effort. (Which, of course, is the furthest thing from the truth.)
Even given my predilection, I worry that the idea of "summary-only" .cs triple-whack files may be problematic from a synchronization standpoint. That is, as the implementation and types change, we know that maintaining the map between implementation and docs is something more than trivial. It seems to me that you want the storage for that map to be the easiest-to-work-with format. For me that would be XML rather than triple-whacked-.cs (System.Xml.Linq FTW). (On the other hand, the synchronization code is essentially about types and signatures and .cs has the advantage of giving us actual type-safety: if the synchronization is wrong, we get a compile-time error. Hooray!)
At Xamarin, we have a more semi-monolithic approach: 1 XML file per type, a directory per namespace. That approach has served us very well, IMO. Without going into details, we have a lot of flexibility re. tooling: we have a visual editor, but on the other hand, scripting and automating against XML is trivial.
If I had my druthers, I'd stay with the Xamarin approach. But is it true that the sidecar-file, at least for remarks, is a necessary pre-requisite for localization?

For the .NET Framework API docs, we also use XML in our CMS, however the file structure is not visible to us and we can only edit one API at a time. Then the platform info is a different input from another set of XML files. We have the option of editing by hand or by using XMetal which understands our schema, etc.
I wouldn't say that the sidecar-file is a prerequisite for localization since today our CMS exports the localizable segments in the XML format already. I can find some folks from our Loc team to comment on that aspect with more property than I can.

URLs are easy to predict and hack.

Just wanted to add a bit of my experience with the Xamarin developer portal URLs. After I switched the url format for API docs to move the information from the query string, to being a part of the path itself, I came across a few limitations. For a very small subset of APIs, which had a large number of parameters, we encountered some errors due to the path being too long. After some fiddling with parameters (maxUrlLength, etc), I decided to break up the URL into multiple segments. So for an API that might have looked like this:
/api/Some.Long.Namespace.TypeName(OneParameter,TwoParameter,ThreeParameter)

It now looks like:
/api/Some.Long.Namespace.TypeName/p/OneParameter/TwoParameter/ThreeParameter/

I'm only bringing this up as something that should be tested ... I don't know if any APIs in the BCL would trigger this error, but it might be good to verify with the longest URLs in the set before going live :)

@MichaelNorman We use Roslyn to read/mutate .cs files. It's a purpose-built API for that purpose.

At Xamarin, we have a more semi-monolithic approach: 1 XML file per type, a directory per namespace. That approach has served us very well, IMO.

That's mostly the same as the proposal, in terms of the granlarity.

@joelmartinez good point. We haven't gotten to that level of detail. I think we were largely hoping to skip that (one page per overload). We'll see.

For the URLs, we are already live, so I don't think we ran into problems with the length.

I think we've addressed these in our current API docs work.
I propose we close this.  @richlander @mairaw Can you vote on this proposal?

I'll just close this.  We've addressed what is discussed here, and the vision has basically been executed.


e2e: serial: revamp the runner script

reorganize the e2e serial runner script and make sure
it can be shipped in the tests container image.
This means fixing the paths.
Signed-off-by: Francesco Romani<EMAIL_ADDRESS>

depends on https://github.com/openshift-kni/numaresources-operator/pull/165

/hold
because https://github.com/openshift-kni/numaresources-operator/pull/166#issuecomment-1046178640

/hold cancel

/cherry-pick release-4.10

/hold
Please address my comments

/hold cancel
lgtm is gone anyway :)

/lgtm
/approve
Thank you for the changes


Incorporate Gale/ECCO MARC records for import and zotero metadata #389 #379

We were given MARC records in binary format for ECCO1 and ECCO2, but retrieving a particular MARC record for an item by Gale ID was far too slow (~30 seconds on the first one I tried in ECCO2, which is smaller than ECCO1).
My solution is to split those MARC records into a local pairtree datastore keyed on Gale item id, and serialize it as JSON (in my tests, JSON was smaller on the filesystem and faster to parse when loading records). This makes it possible to quickly retrieve the MARC records we need on demand, for import or for metadata harvesting (zotero), based on Gale item id.
Changes included in this PR:

a new script to split out the marc records and a method to access marc record by id
split out hathitrust bibdata and marc metadata so the marc portion could be reused for Gale content (code change here is almost entirely cut & paste; only change is publication date handling, to extract from marc for Gale)
use marc records for metadata in gale import script
serve out marc record for Gale items (for zotero harvest)

Might need more error handling? But I'm not sure yet what kind of errors are likely & important enough to require code handling.

Codecov Report

Merging #390 (b690313) into develop (f120c44) will decrease coverage by 0.70%.
The diff coverage is 69.84%.

:exclamation: Current head b690313 differs from pull request most recent head 6dcb1d2. Consider uploading reports for the commit 6dcb1d2 to get more accurate results

@@             Coverage Diff             @@
##           develop     #390      +/-   ##
===========================================
- Coverage    98.91%   98.21%   -0.71%
===========================================
  Files          107      108       +1
  Lines         5166     5261      +95
  Branches         6        6
===========================================
+ Hits          5110     5167      +57
- Misses          56       94      +38

I thought since we were already using pairtree for the project it seemed like a reasonable and efficient solution.

...  i might've tried something with json-lines files so that many records could still live in one file

The ECCO2 marc file is 91MB and ECCO1a and b are 176M and 189M; ECCO2 alone splits out to 48212 files.  Would json lines work at this scale?
It occurred to me after I stopped working on this that binary marc is probably even smaller than json marc, and likely similar or faster to load and parse.  It's not any more difficult to work with, since we're already using pymarc. I'm going to do a little bit of testing to confirm, and may switch it — but I think the way I've written it not too much will have to change.

The ECCO2 marc file is 91MB and ECCO1a and b are 176M and 189M; ECCO2 alone splits out to 48212 files. Would json lines work at this scale?

I think it's supposed to — one of the ideas is that if you compress the resulting file (e.g. with bzip) there's a ton of redundancy because the JSON structure of each object is repeated, so it plays very well with most compression algorithms. So the size on disk might be considerably smaller than ~150M. Never tried with a file that big though, would be curious to see how it works!


Notebook "show more" has poor formatting with many small text outputs

I have a notebook which will produce a new "text/plain" output for each console.log in a program. This works well enough in-notebook:

but as soon as I click "show more", I get this formatting, which is much harder to work with:

IMO if they're all plaintext outputs, they should be fomatted exactly as they are in-notebook.

@JacksonKearl I just verified with latest Insiders and this issue is gone. Please reopen if you are still seeing it.

Still not in love with the rendering of large outputs. Couple issue cases:
for (var i = 0; i < 1000; i++) {
  await new Promise(c => setTimeout(c, 10))
  console.log(`this is my ${i}, there are many like it, but this one is mine`)
}

After the 500'th output, all outputs stop being rendered, but there's no message saying as much:

What's interesting is if I change the promise delay to 1 ms, I do get the message:

However when I click into it, the rendering is still in an undesirable format:

IMO it'd be much nicer to collapse all the text/plain outputs into a single block of raw text.

On the other hand, if I don't use async at all, forcing as much text into one output line as possible:
for (var i = 0; i < 10000; i++) {
  // await new Promise(c => setTimeout(c, 1))
  console.log(`this is my ${i}, there are many like it, but this one is mine`)
}

I get a bunch of segments of truncated text:

Where each "Open the full output data in a text editor` link takes me to about 100 lines of text:

This is better than the above JSON, but still it'd be ideal if there was some way to view all of the text output of a command in one buffer. I often will log a bunch of lines of stats/runtime progress/whatever in a cell and would like to have a single buffer I can use to look through them all, just as I would if I were using a terminal.

I still repro this problem? The output format of the text seems good, but it doesn't show all the outputs if the sleep happens.


Correctly serialize lists of URLs for nested relationships

When reading the guides, I understood that related fields represented using nested URLs are understood by the drf serializer & the relationships were resolved automatically.

Ember Django Adapter has support for Django REST Framework's HyperlinkedRelatedField.
URLs in a json hash for hasMany and belongsTo relationship fields will
automatically be retrieved and added to the store.

However, this does not seem to be the case.
My API is structured as such:
GET /api/charginganalyses/
[
    {
        "id": 1,
        "date":<PHONE_NUMBER>,
        "notes": "Some Notes",
        "billings": [
            2,
            3,
            4
        ],
        "extra_info": "Extra Info"
    },
...
]

On the Ember side, my charginganalysis model:
export default DS.Model.extend({

  date: DS.attr('string'),
  notes: DS.attr('string'),
  billings: DS.hasMany('servicebilling'),
  extra_info: DS.attr('string'),

});

When I am using the ModelSerializer and my billings are ids, I can correctly access the billings property on my charginganalysis instance (after using getEach on every charginganalysis in my route).
However, if I change my API to use the HyperlinkedModelSerializer as such:
GET /api/charginganalyses/
[
    {
        "id": 1,
        "date":<PHONE_NUMBER>,
        "notes": "Some Notes",
        "billings": [
            "http://localhost:8000/api/servicebillings/2/",
            "http://localhost:8000/api/servicebillings/3/",
            "http://localhost:8000/api/servicebillings/4/"
        ],
        "extra_info": "Extra Info"
    },
]

the relationships cannot be identified. I took a look in the code and I feel that this should be the stanza responsible for handling this case.
When I stopped the execution there using a debugger, I found out that if payloadRel is anything else than a string the code does nothing and passes the instance on to the parent element. In this case, payloadRel is indeed not a string but an array.
This probably happens in the first case too, where I am using ids instead of URLs but I am guessing that somehow Ember Data is able to realize that those are IDs and make the association.
I know that the proposed approach is using a single URL for such relations and defining custom views in the back end using HyperlinkedIdentityFields, but this does not allow editing your models without defining extra API endpoints, so since my relationships are not that huge I feel like the performance loss would be minor.
Either way, I believe that since the documentation mentions that lists of nested URLs are supported this is an issue.
I could perhaps try to provide a PR fixing this, if this is something you are interested on.

Sorry for the late reply. I'm ok with supporting HyperlinkedModelSerializer out of the box but I would want to keep the current behavior as well. The documentation would need to be updated as well to mention both options with a short explanation of the pros & cons.
@dustinfarris What do you think?

I feel that, at least for now, the documentation should be updated to state that the only supported implementation is the HyperlinkedIdentityField one and that nested URLs are not supported and afterwards we could discuss how to implement this. It is quite misleading at the moment.

Sounds like a good plan. It would be much appreciated if you could make a pull request to improve the documentation about this. Thanks.


Update LICENSE.md

Motivation

Proposed changes

Test

Code:
Result:

test comment 4/13

test 4/18/2022

test 4/18/2022

test

test

test 4/19/2022
__
  Summary: :trophy: This code is awesome  |  Tags: Readable

test 4/19/2022
__
  Summary: :trophy: This code is awesome

test 4/19/2022 1

111

1111
__
  Summary: :trophy: This code is awesome  |  Tags: Fault-tolerant

123

test

123

1235355352
__
  Tags: Elegant, Reusable

232313331
__
  Summary: :trophy: This code is awesome

1221

test 555

sfsff

ыкыаы
__
  Summary: :trophy: This code is awesome

test 5/19/2022

test
__
  Tags: Efficient

test
__
  Tags: Efficient

test 66666

test 6/29/2022
__
  Summary: :trophy: This code is awesome  |  Tags: Fault-tolerant

test 6/29/2022 personal

test 6/29/2022 org
__
  Summary: :hammer_and_wrench: This code needs a fix  |  Tags: Fault-tolerant

test
__
  Tags: Efficient

this is new comment
If you want upcoming developers to follow certain standards or inform about certain things then include them in the beginning of your class as a comment. E.g. suppose if you are writing a serializable class in java then it's good to put a serializable alert stating that any new fields added in this class must implement a Serializable interface in java or make it transient etc.

Sema Reaction: :trophy: This code is awesome | Sema Tags: Not secure, Elegant, Brittle

__
  Summary: :trophy: This code is awesome

readable org__
__
  Summary: :hammer_and_wrench: This code needs a fix  |  Tags: Readable

test 8/8/2022

tets 8/11/2022
__
  Summary: :trophy: This code is awesome  |  Tags: Reusable, Fault-tolerant

test 8/24/2022 readable fix
__
  Tags: Readable


build for android

wo need a lib for android uws_android_arm64_108.node

You have misunderstood what this project is.

my nodejs run on android  .
Error: This version of µWS is not compatible with your Node.js build:
Error: Cannot find module './uws_android_arm64_108.node'

What kind of thing are you building?

I bind arm64, but not useful on android nodejs v18 - v19  . I install a arm64 package nodejs on android it work now


[typescript] [13.basic-bot] Bad configuration on tsconfig.json

Sample Information

Sample type: samples
Sample language: typescript
Sample name: basic-bot

Describe the Bug
Building the sample gives a bad configuration (structure) of the files in lib directory.
To Reproduce
Steps to reproduce the behavior:

Follow the README instructions.
Execute npm build command.
Look the lib directory created.
Execute npm start.
See error.

Expected Behavior
Build the solution and start the bot.
Screenshots

Additional Context
The issue is that the tsconfig.json is setted to transpile the "src" and the "resources" folders, but the resources folder has nothing to transpile. The result of this configuration is the creation of the "src" subfolder inside the "lib" folder. This breaks the node run command and some of the objects references inside the project that points to the "lib" root folder instead of the "src" subfolder.
Proposed Solution
Replace in tsconfig.json:
"rootDirs": ["./src", "./resources"]  ----> rootDir": "./src",
The solution would be just to compile only the "src" folder.

Hi! Could you please add a markdown link to the readme file in the To Reproduce steps?


Is it still working ?

Please can anyone confirm me it is working ? I don't want to get banned instantly....:(

Please read all the words before asking questions.

It is working