Issue with new tool in toolbox

Hello,
Firstly I would like to thank you for this amazing tools. It really satisfies most of my needs, but currently I am struggling with adding new tool, correctly with adding certain tags.
Scenario:
Adding new tool as simple as it can.
class ContentTools.Tools.Test extends ContentTools.Tools.Heading

    # Convert the current text block to a subheading (e.g <q>foo</q>)

    ContentTools.ToolShelf.stow(@, 'quote')

    @label = 'Quote'
    @icon = 'quote'
    @tagName = 'q'

It all works fine, extending Heading, overriding apply and adding custom css class. When in edit mode i can substitute my q tag with h1 or any predefined tag, as well as reverse. This go bad when i save article (it still have styling), go back in edit mode and my text can't be edited. It got class ce-element--type-static and i guess that is the problem since ti can't get focus. I am assuming that I need to register my new tag somewhere but I have problems with that. If you could help me or provide some info I would be grateful. Code snippet below works fine.
class ContentTools.Tools.Test extends ContentTools.Tools.Heading

    # Convert the current text block to a subheading (e.g <q>foo</q>)

    ContentTools.ToolShelf.stow(@, 'quote')

    @label = 'Quote'
    @icon = 'quote'
    @tagName = 'blockquote'

And one additional question, is it posible to include new font on new element style?
Thank you

Hi @tokuduz,
ContentEdit.TagNames.get().register(ContentEdit.Text, 'q')

Ant


kontena service deploy waits for the service even if default is --no-wait

atleast when the service deploy is not able to start (in a case where initial nodes are down)
help says:
--[no-]wait                   Do not wait for service deployment (default: true)

but deploy with "default: true" hangs:
$ kontena service deploy myservice
    *   Deploying service muesli  .. \

this does not:
$ kontena service deploy --no-wait myservice
   [done] Deploying service mysesrvice

--wait ==> @wait = true
--no-wait==> @wait = false
Either the flag description is wrong or the flag is wrong.
It should be either:
option '--no-wait', :flag, "Do not wait for service deployment"

or
option '--[no-]wait', :flag, "Wait for service deployment to finish", default: true


Google V3 Recapture Not Working on Multiple Forms on page.

Works for the first form doesnt work for the others.

Recaptcha isn't meant to work in multiple instances on a page. Consider using one form per page.


can't get $NVOY_SERVICE Name

Description:

I can't get $(NVOY_SERVICE) name. this is error.

➜  ~ export ENVOY_SERVICE=$(kubectl get svc -n envoy-gateway-system --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg -o jsonpath='{.items[0].metadata.name}')
error: error executing jsonpath "{.items[0].metadata.name}": Error executing template: array index out of bounds: index 0, length 0. Printing more information for debugging the template:
	template was:
		{.items[0].metadata.name}
	object given to jsonpath engine was:
		map[string]interface {}{"apiVersion":"v1", "items":[]interface {}{}, "kind":"List", "metadata":map[string]interface {}{"resourceVersion":""}}

Environment:

k8s: minikube k8s-1.24
version: latest and v0.2

Logs:

Include the access logs and the Envoy logs.

What is the result of kubectl get svc -n envoy-gateway-system?

@misstick86 ^ means that the Envoy service was not created. If you're following the v0.2 quickstart, have you kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v0.2.0/quickstart.yaml? If so, please check the status of the GatewayClass/Gateway resources and EG logs for further analysis.

@danehans get it. but, it's kinda embarrassing.  i reinstall gateway follow document after reinstalled k8s. it's totally ok.

Reinstalling EG and/or k8s should not be required but I'm happy you resolved your issue.


Keep track of client and server versions, and warn client if they're not in sync

Each time the client and server are regenerated, the version number may be bumped.
Versioning format proposal
The version format will be in the format "appid-vx.y" where x and y are numbers from 0 to infinity.

The appid is a randomly generated, 8-character hash when the project is first generated. This ensures you can't try to connect to a server for another app by accident.
The x number is the major version. A client and server must be of the same major version in order to communicate. Otherwise, an error will be shown.
The y number is the minor version. A client and server with different minor versions can still communicate.
When the major version is bumped, the minor version is reset to 0.

Proposal for determining version bumps
Version bumps will be calculated whenever the apps is regenerated from the specification. The following rules will be used to determine version bumps:
Major versions
Major versions involve changes in how the server and client communicate. The following will cause changes in the major version:

Adding a new Transition (either Transition or CmdTransition)
Modifying the data sent with a transition (either Transition or CmdTransition) with origin OriginClientOnly or OriginBothPossible
Modifying the connection list of an existing transition
Renaming a place or transition
Deleting a Transition (either Transition or CmdTransition) with a connection list longer than 0, that is not OriginServerOnly.
Adding a new place
Removing a place

Minor versions
Major versions involve changes local to the client or server. The following will cause changes in the major version:

Adding a new ClientTransition
Modifying the data sent with a transition (either Transition or CmdTransition) with origin OriginServerOnly
Changing the data of an existing place

Heuristic for now
This is probably more complicated than what we need for now, and would require us to save more metadata between version, in addition to the generated code, so for now we will use the following heuristics to determine if a major/minor bump is needed. These should catch most, if not all, of the above criteria.
Major version
Bump the major version on the client and server if any part of the Decode or Encode modules for the client or server are modified.
Minor version
Any time any files (except for the Encode and Decode modules) are regenerated on the client or server, bump the minor version on both the client and server.
@Necried and @dandoh, thoughts?

If a version is wrong, the client will show an error and will not be able to connect to the server.

Seems good, but one problem I see is that during development, someone might update the spec a lot, and when it's finally ready for deployment, the version number might be really big. Shouldn't be really an issue though, if we're not showing these version numbers to end-users?

What if we gave a three-version format, x.y.z, where x gets incremented by a "draft release" type option? The creator can choose it when they want to, which would reset the y and z and just increment the x by one.

I think this versioning strategy is based on the versioning of libraries, where major and minor versions make sense, and is not the best approach for us.  When we can independently publish subnets, they will need this kind of versioning, but for the server<->client versioning, it would be better to just use unix time - 2019, for the time when the code generator runs.  Since the chance of two apps being generated at the same microsecond is 0%, this handles both versions and different apps, and forces the interfaces and transitions to match.  We don't even care if different versions of ghc and libraries are used or different versions of Elm packages, as far as the server<->client connection goes.
If we ever fix a bug and want to force all components to be at that version or greater, we just need to do the generation again.  This requires that the version (unixTime-2019) must overwrite the old one.  This would be easy to do if there is one .elm and one .hs with the version defined which are always overwritten.

@christopheranand Yes that idea sounds like it should be easy and fine for now, but my reasoning to do something smarter was so that if only client transitions were edited for example, you wouldn't need to rebuild or even restart the server to make changes to the client. However, it would be quite complicated so I think for now that is fine.
I suppose we can include a makefile to build both the client and the server, which would reduce the amount of directory changing and commands that need to be written.


Move UserToolchain and Destination

Purpose of this is to make libSwift easier to use for parsing manifests.

@swift-ci please smoke test


Add readme generation to monopod

So here's a PR for monopod readmes. It will need some careful review and socializing, since it will make monopod yell and fail in CI if a readme is not well structured.
First, new commands are:

monopod readme new --image imageName
monopod readme render --image imageName

Respectively, these will:

Create an images/imageName/metadata.hcl file for an existing image
Render an images/imageName/metadata.hcl file into images/imageName/README.md

Changed commands include:

monopod scaffold package-name ...: this does the usual scaffolding, including a README.md with a placeholder set of <!--body:start--><!--body:end--> tokens. It also creates a metadata.hcl file with various fields to fill out. The short_description field is mandatory.
monopod readme --check: this will validate all metadata.hcl and README.md files are structurally sound and fields are populated.
monopod readme: this rerenders all READMEs. It is equivalent to running monopod readme render --image ... in a for loop across all image modules.

I've included a test in readme_test.go to validate that readme rendering works. I also tested in images-private and it doesn't break anything there or behave any differently.
This needs #1888 to be merged first, since monopod readme --check will be very upset without the various metadata.hcl files.

I added a form to collect some information about new images:

It will run on monopod readme new and monopod scaffold invocations.

Also need https://github.com/chainguard-images/images/pull/1921 merged so that the github action for this PR runs successfully.

I added a form to monopod scaffold for template.apko.yaml values. It is pre-populated with default values, so most of the time it will not need any editing.

Preface/disclaimer: I'm not at all happy with this code, it all over the place with lots of duplication. However, in the interest of getting people using the tool itself, would you be able to review and try it out again @imjasonh?
It passes the current presubmit-readme CI check, which is one of the major compatibility issues I wanted to fix here. It means no more playing catch up with images that are missing a metadata.hcl file, or have a partially formed README.md file.
Once this is merged I'd like to add logic for editing existing image templates and metadata, private images, and parse main.tf as an HCL file to generate entries in it that way.
Also, I can remove the form(s), or add a flag to skip them if they create too much friction.

Ok, I got rid of the scaffold form, it was really annoying.
I reworked the main.tf parsing in scaffold.go to use the hclwrite package. It is a more robust way of adding a new module to the list, and should also enable linting the file.

Alright, this is in better shape, I added some tests to check that scaffold.go creates and sorts module entries in main.tf.
go test --race -v ./monopod/pkg/commands/*.go
=== RUN   TestMatrix
=== RUN   TestMatrix/affects_single_image
=== RUN   TestMatrix/.github
=== RUN   TestMatrix/.github_and_image
=== RUN   TestMatrix/bypass_disabled
=== RUN   TestMatrix/bypass_withdrawn-repos
--- PASS: TestMatrix (0.00s)
    --- PASS: TestMatrix/affects_single_image (0.00s)
    --- PASS: TestMatrix/.github (0.00s)
    --- PASS: TestMatrix/.github_and_image (0.00s)
    --- PASS: TestMatrix/bypass_disabled (0.00s)
    --- PASS: TestMatrix/bypass_withdrawn-repos (0.00s)
=== RUN   TestReadme
=== RUN   TestReadme/render_readme
--- PASS: TestReadme (0.00s)
    --- PASS: TestReadme/render_readme (0.00s)
=== RUN   TestScaffoldSingleModule
=== RUN   TestScaffoldSingleModule/add_single_module_to_main.tf
--- PASS: TestScaffoldSingleModule (0.00s)
    --- PASS: TestScaffoldSingleModule/add_single_module_to_main.tf (0.00s)
=== RUN   TestScaffoldSortModules
=== RUN   TestScaffoldSortModules/sort_modules_in_main.tf
--- PASS: TestScaffoldSortModules (0.00s)
    --- PASS: TestScaffoldSortModules/sort_modules_in_main.tf (0.00s)
PASS
ok  	command-line-arguments	1.483s


[FR] Link previews

@backme7 could you elaborate a bit more on what you'd looking for from this feature? I'm unsure what link previews might be here 😅


if using_specific_key_list is selected, enable to select whether DML about the vertices connected the specific vertices are generated recursively

https://github.com/kazumatsudo/GraphDB2RDB/pull/118/commits/4603de03dbb2ca46476fb0b40068644da3e0eba0

https://github.com/kazumatsudo/GraphDB2RDB/pull/128


Feature Request: add speed to M3i bike

M3i does not broadcast speed, however does expose total distance and cadence, so should not be too complicate to derive speed and expose this in the CSC profile.

What usage are you hoping to get out of speed data from the Keiser M3?
Apps like Zwift do not use speed sensor information directly. Instead the in-game speed is calculated based on power data, received from the bike. This in-game speed greatly depends on e.g. the gradient of the road within the game. Therefore when you output 200W from your bike, this could translate to a speed of 40 km/h on a flat course, or to just 5 km/h on a course with a 10% gradient.
For bikes like the Schwinn IC4/IC8 or the Flywheel which do show speed information on the display and transmit them over Bluetooth, this speed information usually does not match what you see in-game. The bike effectively assumes an all-flat course. As a result the Internet is littered with questions and complaints about why these numbers don't match.
Therefore while almost trivial to pass the speed information received from Schwinn IC4/IC8 or the Flywheel on via BLE CSC information, the usefulness of that data is questionable.
In the case of the Keiser M3 there is another challenge: As you already wrote, the bike doesn't transmit current speed information. Calculating the current speed based on distance traveled and time elapsed is not possible. This will only give you average speed over the time elapsed. Imagine you bike 20 km, which takes you 60 minutes. While that tells you that your average speed during that ride was 20 km/h, it doesn't mean at all that at the 60 minutes mark you were actually riding at 20 km/h. For BLE CSC we need current speed.
There is a relation between cadence, resistance (in case of the Keiser M3 transmitted as "Gear") and speed, which can e.g. be seen here. As the Keiser M3 is a spin bike and not a regular bike the gears don't match any such tables and instead you would have to create one yourself.
But how? You don't have a speed value displayed on the bike's built-in computer to determine what speed would match 100 rpm @ Gear 1 and therefore what to put into that box.
Instead you would have to bike for e.g. 10 minutes at exactly 100 rpm and Gear 1 and then determine based on the shown distance the average speed for that time interval. That's what would goes into the 100 rpm @ Gear 1 box. Now repeat the same for all Gears and reasonable cadences between 30 and 130 rpm. There a lot of placed to introduce inaccuracies in that process, so the calculated speed would still only be a very rough guess.
That's a lot of work to get a value displayed that has a very questionable meaning.

Hey @chriselsen
i don't use zwift, so it was more a general request. I do understand relationship between gear and speed, and average vs instant speed ;-)
On the keiser, the gear is more a break. One rotation of the pedals, equals to about 8.5 rotations of the flywheel. So there is a 1-1 relationship between cadence and speed actually. Whether it corresponds to something in real life on the other hand is questionable - i fully agree.

For bike types that deliver speed information to Gymnasticon (e.g. IC4 or Flywheel), we should be able to easily pass this through via BLE and ANT+ to receivers.


Service crash when plugging in wheel

First off, thank you for working on this! I have a Thrustmaster 458 Spider and was disappointed it didn't work out of the box with PC games non-xbox.
I had version 1.1.1. I also noticed in your event logs it reports the version <IP_ADDRESS>(I think that can be set in the AssemblyInfo.cs or maybe the app.manifest? or in the properties of the project before publishing)
I had the service running, was watching it in task manager and services. As soon as I plugged in the wheel, it crashed.
I pulled two events relating to it out of the Application Event Log and have attached them in evtx form.
I was able to start the service again in services after it crashed, but I haven't yet tried it in a game to see if it works.
WheelCompatibility Crash Logs.zip

Hey, thanks for the report! Looks like an issue with gamepad input injection. It's hard isolating what exactly the issue is as Xboxgipsynthetic.dll (the library throwing the error) is not documented at all and has no debugging symbols. Do you happen to have any information on how I might be able to replicate it. System specs and OS version would also be useful.
Also, the version mismatch is just me forgetting to update the version in the installer project (as i've switched from vs installer projects to wix v3 for creating the installer)

Ah, I've never used wix.
PCSpecs20221221.zip
I'm attaching another zip with snips of windows info and hardware info.
As far as replicating it, not sure other than I had the service running, then plugged in wheel and saw the service crash.
It's not consistent though. After a restart of the computer I opened services again and saw it start up, and plugged in the wheel again and it didn't crash this time.

Ah, I've never used wix. PCSpecs20221221.zip
I'm attaching another zip with snips of windows info and hardware info. As far as replicating it, not sure other than I had the service running, then plugged in wheel and saw the service crash. It's not consistent though. After a restart of the computer I opened services again and saw it start up, and plugged in the wheel again and it didn't crash this time.

Weird, has it occurred more than once?

I have not gotten it to happen again. May have just been a glitch in my windows environment that worked itself out with a restart. IT 101 I guess

I have not gotten it to happen again. May have just been a glitch in my windows environment that worked itself out with a restart. IT 101 I guess

Yup, heisenbugs are real fun stuff. Everything's working fine now though, correct? Your wheel is working properly with everything?

Mostly, though I've noticed one issue with this wheel so far.

The button circled on the left and the A button are both showing up as 'Joy A' when mapping in Truck Sim.

Mostly, though I've noticed one issue with this wheel so far.  The button circled on the left and the A button are both showing up as 'Joy A' when mapping in Truck Sim.

Yeah, the wheel seems to report those two buttons as the same. (it also does the same for the gear buttons and the buttons on the back of the wheel) There seems to be no way around this at the moment. Thank you very much for reporting these issues, and feel free to let me know if you have any suggestions for features or other bug reports!


Improve RetrieveBlockData

Summary
Current RetrieveBlockData implementation spawns a goroutine per each share in ExtendedDataSquare. In the worst case with the max block 128X128 that is 16384 goroutines. This causes the race detector to stop working in tests, as it has a limit to 8k routines. Furthermore, this a lot of routines for a single operation, and in fact most of the time they are idle.
Why routines are idle. Shares in a block are addressed and committed with multiple Merkle Trees, so when we request a whole block we need to walk through all the trees. The walking step is: request blob of data by its hash(1), unpack block(2), check if we unpacked more hashes or a share(3), and proceed with unpacked hashes onto the next step recursively(3). Those steps are executed until no more hashes left and we have all the shares. From this, we can see that every walking step is a full roundtrip - network request, unpack, request again, and so on. Now, imagine those 16384 goroutines which walk down the same trees. In practice, those routines mostly wait for every single roundtrip to finish and then they compete to initiate the next roundtrip. Competing, in this case, is useless and we need to avoid it.
Instead of spawning goroutine per share, we should spawn a routine per tree we need to walk through, particularly per every DAHeader root. This way, we don't have any competing routines and only one routine initiates all ther roundtrips. In numbers, for the largest block that would be 128 routines per Row DAHeader root and 256 routines if want to fetch and store all the inner nodes of trees.
NOTE: All the shares are addressed and committed twice, with two Row and Column Merkle Trees, thus it is not required to traverse both trees to fetch the shares, but again, if we need to store all inner nodes of both trees(cc @adlerjohn) than both tree should be traversed.
Implementation Details
// TODO
Action Items
// TODO
References
As already mentioned, the original spark of the issue is the race detector complaining about exceeding the limit of 8k routines. The solution for that was to detect if the race detector running and simply skipping the test :grimacing:. Later, after some discussions, https://github.com/celestiaorg/lazyledger-core/issues/357 was created. And the solution for it is being implemented here https://github.com/celestiaorg/lazyledger-core/pull/424.
Also, supersede https://github.com/celestiaorg/lazyledger-core/issues/278
Appendix
There is a plan to remove DAHeader and use only one root hash to address and commit to all the shares. In such a case, we would not need to spawn any routines at all. The routine calling the RetrieveBlockData needs to be blocking anyway and it can then take care of initiating all the round trips.

Todos are self reminders. For now I just elaborately explained the issue and high-level solution. More implementation details are yet to come.

The first thing to point out, is that this is an optimization. While it was likely implied, just to be clear, unless @jclyons52 wants to work on this, we should probably put off doing this until after MVP. That being said, it does seem like there could be some significant benefits to be had.

In the worst case with the max block 128X128 that is 16384 goroutines. This causes the race detector to stop working in tests, as it has a limit to 8k routines.

This is true! It is also true that when running the test in #424, with a limit of 512 goroutines, that we still cause the race detector to complain. That's what led me to believe that the calling dag.Get spun up quite a few goroutines. It could also be that the the semaphore code isn't working the way I think it is, and some goroutines are kept alive.
Having redundant walks sounds bad, and we should avoid those where possible, but are idle goroutines_that_ bad? The standard library opens up a routine per http request, so us doing something similar doesn't strike me as terrible. It would be nice if we had a more efficient system, but I'm not sure it's worth the complexity and effort. Especially considering our near future plans, where very few nodes will be downloading the entire block using IPFS.

Instead of spawning goroutine per share, we should spawn a routine per tree we need to walk through, particularly per every DAHeader root. This way, we don't have any competing routines and only one routine initiates all ther roundtrips.

I might be misunderstanding this. So, we would still retrieve each share concurrently, but leave the concurrency to IPFS? Is competing == blocking?

Having redundant walks sounds bad, and we should avoid those where possible, but are idle goroutines that bad?

Just to note that I am not rushing with implementing this issue.

Competing, in this case, is useless and we need to avoid it.

Yeah, I guess this make sense here. I think we previously just accepted that there will be a lot of overlap for the inner nodes per "leaf-request" and we can certainly make more use of the tree structure. Looking forward to read the filled out Implementation Details.

but leave the concurrency to IPFS

Let's increase the correctness of our statements by mentioning specific IPFS subsystem instead of IPFS as a whole as a black box. In this case, we tell Bitswap and even more precisely IPLDv0 with Bitswap.

So, we would still retrieve each share concurrently, but leave the concurrency to IPFS?

Yep.

Is competing == blocking?

I would say unblocking instead, specifically routines compete to unblock themselves. The code analogy here would be a native Go's chan from which many routines wait/compete for a result to read. The one who gets a chance to read the result unpacks it and sends it to request chan, while others do nothing. After, waiting starts again till a new result value appears.

@Wondertan can we close or move this issue?

@evan-forbes, Can you move it?


custom_vjp: automatically handle float0 cotangents

The main issue here was that when a custom_vjp function took a primal input with integer dtype, we would demand (via an internal assertion) that the user's bwd function would produce a value with float0 dtype (i.e. the tangent type corresponding to an integer primal). But users don't know about float0s, and shouldn't have to learn about them! So instead we just automatically handle producing zeros here (with the right dtype).
Also misc cleanups (I'll mark them below in review comments).

On second thought, I'm going to be more responsible and break this PR up into two.


Incorrect file uri

Hi!
First of all, thanks for the great IDE engine, I believe this will be the future of Haskell IDE tooling.
I have a problem though, my project compiles and works fine, but I get errors coming from /private/var/folders/... folder, for example:
2018-05-0813:56:23.784628[
   ThreadId 5
]- <--2--{
   "jsonrpc":"2.0",
   "method":"textDocument/publishDiagnostics",
   "params":{
      "uri":"file:///private/var/folders/hm/3t_b50tj3ng1fj3g4p9zgcn02hg99c/T/ghc-mod12335/PayslipCalculatorSpec12334-0.hs",
      "diagnostics":[
         {
            "severity":1,
            "range":{
               "start":{
                  "line":4,
                  "character":0
               },
               "end":{
                  "line":4,
                  "character":33
               }
            },
            "source":"ghcmod",
            "message":"Could not find module ‘PayslipArbitrary’\nUse -v to see a list of the files searched for."
         },
         {
            "severity":1,
            "range":{
               "start":{
                  "line":6,
                  "character":0
               },
               "end":{
                  "line":6,
                  "character":42
               }
            },
            "source":"ghcmod",
            "message":"Could not find module ‘PayslipCalculatorFixtures’\nUse -v to see a list of the files searched for."
         },
         {
            "severity":1,
            "range":{
               "start":{
                  "line":7,
                  "character":0
               },
               "end":{
                  "line":7,
                  "character":27
               }
            },
            "source":"ghcmod",
            "message":"Could not find module ‘Test.Hspec’\nUse -v to see a list of the files searched for."
         },
         {
            "severity":1,
            "range":{
               "start":{
                  "line":8,
                  "character":0
               },
               "end":{
                  "line":8,
                  "character":38
               }
            },
            "source":"ghcmod",
            "message":"Could not find module ‘Test.Hspec.QuickCheck’\nUse -v to see a list of the files searched for."
         },
         {
            "severity":1,
            "range":{
               "start":{
                  "line":9,
                  "character":0
               },
               "end":{
                  "line":9,
                  "character":32
               }
            },
            "source":"ghcmod",
            "message":"Could not find module ‘Test.QuickCheck’\nUse -v to see a list of the files searched for."
         }
      ]
   }
}

As you can see the file path is file:///private/var/folders/hm/3t_b50tj3ng1fj3g4p9zgcn02hg99c/T/ghc-mod12335/PayslipCalculatorSpec12334-0.hs
Also when I have real errors in my files the files they are not displayed in files themselves, but rather in those temporary files in /private/var/folders/..
I experience it both in Atom and VSCode, this is a screenshot from Atom

The cloned version is 53cd497168d83759a9cc25cff98a3134be0906c2 and it's installed using:
$ git clone https://github.com/haskell/haskell-ide-engine --recursive
$ cd haskell-ide-engine
$ stack --stack-yaml=stack-8.2.2.yaml install

Let me know if you need more information.
Cheers,
Leonti

What operating system are you using?

I have the same issue on macOS High Sierra 10.13.x, in Visual Studio Code. I think it's solved temporarily by rebooting (I'll try to verify this). I've also ran into cases where clicking any of the error messages in one of those temporary files would open said file and also create a new file but with number at the end incremented by 1.
I am using the same HIE version as the OP and tried recloning and rebuilding.

This might have been introduced by the new URI handling changes to haskell-lsp. Can someone confirm if this issue affects https://github.com/haskell/haskell-ide-engine/commit/afb99e6e57122c67fb91bd493061998e0a0aec23 or prior?
https://github.com/haskell/haskell-ide-engine/pull/545
https://github.com/alanz/haskell-lsp/pull/76

It would be helpful if the full path of the original file could be provided.
Also, is there anyone not on OSX experiencing this issue?

I installed it at home on my Ubuntu 17.10 and I don't have this issue.
Very impressed with the engine - very fast on hover, hlint, docs, jump to definition works perfectly without installing tons of different plugins and packages. Implementing it as a language server was the right choice!
Thanks so much!
Seems like an OSX-specific issue though.
Will try to roll back to an older version tomorrow at work and see if it solves the issue.

@Leonti could you provide the full path of the original file you were facing this issue with?

Here are the paths on my machine. Everytime I open /Users/yuuki/private/haskell/hffp/chapter-exercises/src/Ch12.hs in Visual Studio Code it creates a new tmp file. Right now /private/var/folders/lt/cxg1b3t933x6xkdx12gl5vrr0000gn/T/ghc-mod24952/Ch1224951-4.hs. Close -> Open again and we have /private/var/folders/lt/cxg1b3t933x6xkdx12gl5vrr0000gn/T/ghc-mod24952/Ch1224951-5.hs The old tmp files are deleted whenever a new one is created so that when I now click errors reported for *-4.hs VSC says file not found. Click the current one *-5.hs opens the tmp file, not the actual file **/Ch12.hs

My path was:
/Users/leonti.bielski/property-testing-demo/payslip-property-testing-haskell/test/PayslipCalculatorSpec.hs
and
/Users/leonti.bielski/property-testing-demo/payslip-property-testing-haskell/test/PayslipArbitrary.hs (for the second issue where errors are detected, but they refer to a temporary file)
My issue matches the one that @cideM describes

Hmm, the paths look fairly straightforward, so there shouldn't be any weird URI decoding/encoding issues. I'll try to make a branch of HIE that logs all of this properly so I can see what's going wrong. Unfortunately I don't have an OSX machine on hand, so you guys would have to test it.

Would be happy to test!
I will also try to see if I can find a commit from which the issue started to appear.

i am also on macos and having probably same issue in a different way. when i check the logs i see things like [Error] Got error while processing diagnostics: <no location info>: error:^@    module ‘seyler-0.0.0:Main’ is defined in multiple files: /var/folders/qx/fdvs1_qd5b7ch8y2j5yj6spw0 000gp/T/ghc-mod4644/Main4643-0.hs^@                                                             /var/folders/qx/fdvs1_qd5b7ch8y2j5yj6spw0000gp/T/ghc-mod4645/Main4643-04643-1.hs
Also when i go to definition of a function i find myself on file with the temp path like above. And this one occurs only if the function on the same file. When going from another file it seems OK.
right now i can't supply detailed logs but i will as soon as possible.

Can somebody use https://github.com/wz1000/haskell-ide-engine/commit/500e74bc0932e28e8aad97dd5ad17b47ddc51368 and provide me debug logs?
Run hie with
hie --lsp -d -l /log/file/here

and upload the log file to gist or pastebin or some such service?

I don't have this problem using macOS High Sierra.
{
	"resource": "/Users/xxxx/Documents/project/haskell/xxxxxxx/src/Sample.hs",
	"owner": "Haskell HIE (xxxxxxx)",
	"code": "undefined",
	"severity": 8,
	"message": "• Couldn't match type ‘Int’ with ‘[Char]’\n  Expected type: String\n    Actual type: Int\n• In the expression: i * 2\n  In an equation for ‘problemFunction’: problemFunction i = i * 2",
	"source": "ghcmod",
	"startLineNumber": 5,
	"startColumn": 21,
	"endLineNumber": 5,
	"endColumn": 26
}

environment as below
OS
ProductName:	Mac OS X
ProductVersion:	10.13.1
BuildVersion:	17B1003

VSCode
VSCode Version: 1.23.0

hie
Version <IP_ADDRESS>, Git revision f526f9761dff62990befaf94ea8a21443d7463a1 (1223 commits) x86_64 ghc-8.2.2

@nrskt Ok, the commit you are using is almost a month old. So we know that the issue is recently introduced.
Can anyone on OSX do a bisect to figure out which commit introduced this?

@wz1000 i checked out the commit you mentioned and here is the log file: https://gist.github.com/zekzekus/a1d9bd37fb592492bf58f314137b6e10
bisecting is taking too much while rebuilding. i could know a working commit it would be much easier. if log's doesn't work i can try to bisect anyway.

We were requested to use makeAbsolute instead of canonicalizePath, for windows users. on HaRe. See https://github.com/RefactoringTools/HaRe/issues/67

@wz1000 i observe same behaviour. here is the log file with the change you mentioned.
https://gist.github.com/zekzekus/5965ce24f9bc448a2cbd9f4318524a5c

Ok, so I need more logs: https://github.com/wz1000/haskell-ide-engine/commit/052e1bc2be00d69070c1e8daedbb69c9f6381be2

I can confirm that f526f9761dff62990befaf94ea8a21443d7463a1 works properly for me
I tried bisecting, but I can't compile some of the commits with this error:
Stack looks for packages in the directories configured in the 'packages' variable defined in your stack.yaml
The current entry points to /Users/leonti.bielski/haskell/haskell-ide-engine/submodules/brittany/ but no .cabal file could be found there.

I did do git submodule update before trying to compile with stack --stack-yaml=stack-8.2.2.yaml install, ./submodules/brittany/ was still empty

Here is my debug output with wz1000/haskell-ide-engine@052e1bc:
https://gist.github.com/Leonti/2f8f6af88114554dae0850ca4b08e902
This is the interesting bit:
018-05-09 12:06:08.726898 [ThreadId 5] - <--2--{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///Users/leonti.bielski/myob/property-testing-demo/payslip-property-testing-haskell/test/PayslipArbitrary.hs","diagnostics":[]}}
2018-05-09 12:06:08.727022 [ThreadId 5] - <--2--{"jsonrpc":"2.0","method":"window/logMessage","params":{"type":1,"message":"Got error response:{\"error\":{\"code\":-32601,\"message\":\"Unhandled method client/registerCapability\"},\"jsonrpc\":\"2.0\",\"id\":0}"}}
2018-05-09 12:06:09.319966 [ThreadId 7] - srcSpan2Loc: mapped file is /var/folders/hm/3t_b50tj3ng1fj3g4p9zgcn02hg99c/T/ghc-mod36475/PayslipArbitrary36474-0.hs
2018-05-09 12:06:09.320124 [ThreadId 7] - reverseMapFile: mapped file is /private/var/folders/hm/3t_b50tj3ng1fj3g4p9zgcn02hg99c/T/ghc-mod36475/PayslipArbitrary36474-0.hs
2018-05-09 12:06:09.320171 [ThreadId 7] - reverseMapFile: original is /private/var/folders/hm/3t_b50tj3ng1fj3g4p9zgcn02hg99c/T/ghc-mod36475/PayslipArbitrary36474-0.hs
2018-05-09 12:06:09.320243 [ThreadId 7] - reverseMapFile: Canonicalized original is /private/var/folders/hm/3t_b50tj3ng1fj3g4p9zgcn02hg99c/T/ghc-mod36475/PayslipArbitrary36474-0.hs
2018-05-09 12:06:09.320275 [ThreadId 7] - srcSpan2Loc: Original file is /private/var/folders/hm/3t_b50tj3ng1fj3g4p9zgcn02hg99c/T/ghc-mod36475/PayslipArbitrary36474-0.hs
2018-05-09 12:06:09.359234 [ThreadId 7] - setTypecheckedModule: Didn't get typechecked module for: "/Users/leonti.bielski/myob/property-testing-demo/payslip-property-testing-haskell/test/PayslipArbitrary.hs"

@wz1000 I tried changing to cfn <- liftIO $ canonicalizePath from in haskell-ide-engine/submodules/ghc-mod/core/GhcMod/FileMapping.hs, but it didn't help :(

OK, I seem to have figured out the problem. I added a canonicalizePath in the wrong place in my original fix.
The issue should be fixed by https://github.com/alanz/ghc-mod/pull/9
Thanks for all the help and patience. You can test out the change by
$ cd haskell-ide-engine/submodules/ghc-mod
$ git remote add wz1000 https://github.com/wz1000/ghc-mod
$ git fetch wz1000 ghc-8.4-hie
$ git checkout ghc-8.4-hie

The real issue seems to be that we lost this line https://github.com/alanz/ghc-mod/blob/47e200a728a575f407ee6f9893d9a1e77b1b5325/core/GhcMod/FileMapping.hs#L52 somewhere along the line

@wz1000 Thanks a lot!
I can confirm that latest master(08b90ccbce5925648721f9ec90ce236302f586b9) works properly 👍
Thanks again for the awesome tool!


Static file serving misbehavior

You have to use (await Response.static('filename.ext')).build() instead of Response.static('filename.ext')).build().

Fixed 1.0.1.


SLEIGH: Register Windowing/Register Redirection

Is your feature request related to a problem? Please describe.
The decompiler engine currently chokes on architectures that use a windowed register mechanism or on architectures where register indirection is possible. In such scenarios, getting accurate decompilation through register window shifts is basically impossible.
An example of this issue can be seen in the ESP32's variant of the Xtensa architecture (see: http://0x04.net/~mwk/doc/xtensa.pdf, page 180, and the CALL4, CALL8, and CALL12 instructions), where register window shifts of 4, 8, and 12 are feasible, i.e. on a CALL4 instruction, after ENTRY into the callee function is completed, the previous contents of a4 will now be in a0, a5 in a1, a6 in a2, and so on. In the case of the ESP32, this issue is mitigated a bit by the fact that there are only 3 possible shift sizes, and only 16 registers, so, while non-ideal, something like the following can be used:
# Roll macros
macro rollfwd4(){
	p0 = a0; p1 = a1; p2 = a2; p3 = a3; a0 = a4; a1 = a5; a2 = a6; a3 = a7;
        a4 = a8; a5 = a9; a6 = a10; a7 = a11; a8 = a12; a9 = a13; a10 = a14; a11 = a15;
}

macro rollback4(){
	a4 = a0; a5 = a1; a6 = a2; a7 = a3; a8 = a4; a9 = a5; a10 = a6; a11 = a7;
        a12 = a8; a13 = a9; a14 = a10; a15 = a11; a0 = p0; a1 = p1; a2 = p2; a3 = p3;
}

# Instruction
:call4 callRelativeOffset
is op0=0x5 & val_n=0x1 & callRelativeOffset {
	a4 = inst_next;
	rollfwd4();
	call callRelativeOffset;
	rollback4();
}

By using these macros for a register barrel shift of 4, and defining similar macros for shifts of 8 and 12, and backing up the registers that become unaccessible to the callee by storing into p0-p15, it becomes possible to get basic decompilation results, but even then the results include some really nasty problems. For example, the decompiler produces the following result from the corresponding disassembly:
# disassembly:
        40113c3d a0 ca 20        or         a12,a10,a10
        40113c40 b2 a0 00        movi       a11,0x0
        40113c43 ad 02           mov.n      a10,a2
        40113c45 e5 96 ff        call8      FUN_401135b4

#decompilation:
...
        iVar3 = FUN_401135b4(param_1,0x0,iVar2,in_a13,in_a14,in_a15,0x40113c48);
...

This is the same for almost any function call the decompiler emits, since all the registers in the window were written to by the macros that perform the barrel shift just before the call occurred. This problem becomes even worse on architectures where there are more registers, or where shifts are not restricted in how big they can be, such as AMD29k, where there are 128 registers in the windowed range, and the compiler can specify any roll size from 0-127.
Describe the solution you'd like
Some mechanism for changing what version of the register memory space is referred to by a specific register is, in my opinion, absolutely necessary for supporting windowed architectures, and would also solve the problem that SLEIGH cannot currently handle register indirection. In my mind, this looks something like the following (although I imagine that this syntax is almost certainly not ideal, it's just provided as an example):
define register offset=0x00 size=4 [a0 a1 a2 a3 ....]

define shift shift_a_registers(shift_size) {
        a0 -> [register]:4 (shift_size << 2);
        a1 -> [register]:4 ((shift_size + 1) << 2);
        a2 -> [register]:4 ((shift_size + 2) << 2);
        a3 -> [register]:4 ((shift_size + 3) << 2):
        ...
}

:call4 callRelativeOffset
is op0=0x5 & val_n=0x1 & callRelativeOffset {
	a4 = inst_next;
	shift_a_registers(+4);
	call callRelativeOffset;
	shift_a_registers(-4);
}

Additional context
Just wanted to say that I fully understand that implementing this particular feature would be a heck of an undertaking (potentially complicated enough as to be infeasible) and that I'm sorry for posting so many weird SLEIGH feature requests. If any of the devs have alternative ideas on how to achieve something that is less of an endeavor to implement but would also enable this behavior, I'd be interested in hearing it.

@hedgeberg you should show the call8 implementation too. The side effect of its implementation is that all call8 are seen as an indirect function call when they actually are not.

@astrelsky I think you're confusing call8 and callx8, where callx8 is the indirect call, which esp32 makes extensive use of. The issue arises from the fact that, due to the barrel shift, the branch target needs to be saved before the barrel shift, then register a8 is usually overwritten, then the barrel shift is performed, and then the call is made. This makes the varnode tree pretty nasty.
Either way, for safety's sake, the implementation for both call8 and calllx8 are below. rollfwd8 and rollback8 are effectively the same macro as in the prior message, just modified to accomodate a register shift size of 8 instead of 4.
:call8 callRel
is op0=0x5 & val_n=0x2 & callRel{
	a8 = inst_next;
	rollfwd8();
	call callRel;
	rollback8();
}

:callx8 reg_s
is op0=0 & op1=0 & op2=0 & val_m=0x3 & val_n=0x2 & r=0 & reg_s{
	local dst:4 = reg_s;
	a8 = inst_next;
	rollfwd8();
	call [dst];
	rollback8();
}

I did indeed mean callx8.


Warning problems with default argument in match statement

Godot version:
3.1 & 80f91c9
Issue description:
Following the code snippet:
var test = 0
match test:
	0:
		pass
	_:
		return

#warning-ignore:unused_variable
var other_test

The warning system will state that anything after the return is unreachable. But not just that, will also fail to acknowledge the warning-ignore, still warning about an unused variable.
May be related to #26850.

Nevermind, I could swear that it still happened in master, but it seems that it was fixed.


Issues compiling on Mac

I am currently running MacOS Monterey version 12.6.7, with an Apple M1 chip. When running cmake . I get an error
fish
fish: Job 1, 'cmake .' terminated by signal SIGKILL (Forced quit)

bash
Killed: 9

These error messages confuse me...

The issue seems to be at a greater scope then Bongocat-Plus, but rather something with my system. After some digging I found
https://forums.developer.apple.com/forums/thread/701242
Which details some people who are also having this issue, seemingly out of nowhere. I am now finding out that my terminal iTerm2 is no longer working either. Cmake does work when trying to run things like --help
Trying to do a restart only made things worse, now many programs suffer from this issue...

I purged enough space from the system data to install XCode. But even after reinstalling the bug is still present. Unless I can fix this Mac support for Bongocat-Plus may go to a stand still.

After installing a system update, and trying plenty of more things in desperation... no luck. I may just create a g++ compile command and use that for testing Bongcat-Plus on mac.

The solution for me is just to add Meson build support, CMake will be kept though. Keep track of my progress in the meson branch!

I have reopened this issue. CMake still does not work on my Mac, so I'm again trying to port the build system to Meson. It may be a quick and dirty hack (honestly, I prefer CMake), but anything that compiles Bongocat would make me happy.


Homebridge restarting FritzBox for no reason

Hi there,
is there any known problem/feature that allows the Homebridge Plugin to restart my Fritzbox 7580?
This happens sometimes for no reason.

Are you sure that the reboot is caused by Homebridge?

Yes. Before the FRITZ!Box restarts it sends me the latest logs which shows that the user „Homebridge“ initiated a restart:

Hmm, can u send me the log pls?
Normally the plugin CAN NOT restart the fritzbox by itself without an user interaction..
Are you sure u dont clicked on the switch? Maybe via an automation?

This is what the log says at the exact time:
2021-07-08 00:20:04 [7/8/2021, 2:20:04 AM] [FritzBridge][AVM Homebridge: Polling state (router)...
I'm using HomeBridge inside of a Docker container running on my Synology NAS.

This is what the log says at the exact time:
2021-07-08 00:20:04 [7/8/2021, 2:20:04 AM] [FritzBridge][AVM Homebridge: Polling state (router)...
I'm using HomeBridge inside of a Docker container running on my Synology NAS.

But this has nothing to do with the restart. It only says that the FritzBox is queried (polling) to set the status correctly in HomeKit. This has nothing to do with the restart.

This is the only log I can see. In Homebridge itself I can't see any logs further that 11 AM this day...

This is the only log I can see. In Homebridge itself I can't see any logs further that 11 AM this day...

As i said, it has nothing to do with homebridge and the log also confirms that the restart DOES NOT executed from homebridge
maybe check the fritzbox events

The log says that the restart was initiated by the FritzBox user "homebridge" which I especially created for the homebridge plugin. I also changed the password to make sure it's not compromised. Further the user "homebridge" is not allowed to login from internet, only the local network.
Unfortunately I can only check the event log provided per email and it says what I mentioned in https://github.com/SeydX/homebridge-fritz-platform/issues/214#issuecomment-876175233

Can u post your config pls

{     "bridge": {         "name": "Homebridge 0850",         "username": "censored",         "port": 53406,         "pin": "censored"     },     "accessories": [         {             "name": "censored",             "ip": "<IP_ADDRESS>",             "pingInterval": 2,             "pingsToChange": 5,             "pingTimeout": 1,             "pingCommandTimeout": 0,             "mac": "censored",             "broadcastAddress": "<IP_ADDRESS>",             "startCommandTimeout": 0,             "wakeGraceTime": 45,             "wakeCommandTimeout": 0,             "shutdownGraceTime": 15,             "shutdownCommandTimeout": 0,             "log": true,             "logPinger": false,             "debugLog": false,             "returnEarly": false,             "accessory": "NetworkDevice",             "_bridge": {                 "username": "censored",                 "port": 33772             }         }     ],     "platforms": [         {             "name": "Config",             "port": 8581,             "auth": "form",             "theme": "dark-mode",             "tempUnits": "c",             "lang": "auto",             "platform": "config"         },         {             "name": "FritzBridge",             "debug": true,             "devices": [                 {                     "name": "AVM Homebridge",                     "host": "<IP_ADDRESS>",                     "username": "homebridge",                     "password": "censored",                     "ssl": true,                     "tr064": true,                     "igd": false,                     "manufacturer": "AVM",                     "model": "FRITZ!Box 7580",                     "master": true,                     "connection": "dsl",                     "options": {                         "wifi_guest": "switch",                         "led": "switch"                     }                 }             ],             "presence": [                 {                     "ping": false                 }             ],             "smarthome": [                 {                     "name": "Wohnzimmerfenster",                     "ain": "censored",                     "group": false,                     "accType": "lightbulb"                 },                 {                     "name": "Sideboard",                     "ain": "censored",                     "accType": "lightbulb"                 },                 {                     "name": "Kugel",                     "ain": "censored",                     "accType": "lightbulb"                 },                 {                     "name": "Zaun",                     "ain": "censored",                     "accType": "lightbulb"                 },                 {                     "name": "Ventilator",                     "ain": "censored",                     "accType": "switch"                 }             ],             "callmonitor": {                 "active": false,                 "port": 1012             },             "extras": {                 "alarm": {                     "active": false                 },                 "wakeup": {                     "active": false                 },                 "ringlock": {                     "active": false                 },                 "phoneBook": {                     "active": false                 }             },             "options": {                 "polling": {                     "timer": 10                 }             },             "telegram": {                 "active": true,                 "token": "censored",                 "chatID": "censored"             },             "platform": "FritzPlatform"         }     ] }
OR NOT AS CODE
{
"bridge": {
"name": "Homebridge 0850",
"username": "censored",
"port": 53406,
"pin": "censored"
},
"accessories": [
{
"name": "censored",
"ip": "<IP_ADDRESS>",
"pingInterval": 2,
"pingsToChange": 5,
"pingTimeout": 1,
"pingCommandTimeout": 0,
"mac": "censored",
"broadcastAddress": "<IP_ADDRESS>",
"startCommandTimeout": 0,
"wakeGraceTime": 45,
"wakeCommandTimeout": 0,
"shutdownGraceTime": 15,
"shutdownCommandTimeout": 0,
"log": true,
"logPinger": false,
"debugLog": false,
"returnEarly": false,
"accessory": "NetworkDevice",
"_bridge": {
"username": "censored",
"port": 33772
}
}
],
"platforms": [
{
"name": "Config",
"port": 8581,
"auth": "form",
"theme": "dark-mode",
"tempUnits": "c",
"lang": "auto",
"platform": "config"
},
{
"name": "FritzBridge",
"debug": true,
"devices": [
{
"name": "AVM Homebridge",
"host": "<IP_ADDRESS>",
"username": "homebridge",
"password": "censored",
"ssl": true,
"tr064": true,
"igd": false,
"manufacturer": "AVM",
"model": "FRITZ!Box 7580",
"master": true,
"connection": "dsl",
"options": {
"wifi_guest": "switch",
"led": "switch"
}
}
],
"presence": [
{
"ping": false
}
],
"smarthome": [
{
"name": "Wohnzimmerfenster",
"ain": "censored",
"group": false,
"accType": "lightbulb"
},
{
"name": "Sideboard",
"ain": "censored",
"accType": "lightbulb"
},
{
"name": "Kugel",
"ain": "censored",
"accType": "lightbulb"
},
{
"name": "Zaun",
"ain": "censored",
"accType": "lightbulb"
},
{
"name": "Ventilator",
"ain": "censored",
"accType": "switch"
}
],
"callmonitor": {
"active": false,
"port": 1012
},
"extras": {
"alarm": {
"active": false
},
"wakeup": {
"active": false
},
"ringlock": {
"active": false
},
"phoneBook": {
"active": false
}
},
"options": {
"polling": {
"timer": 10
}
},
"telegram": {
"active": true,
"token": "censored",
"chatID": "censored"
},
"platform": "FritzPlatform"
}
]
}

I had the same issue, there is a switch provided to HomeKit which is the FritzBox itself, then either a reboot of the Box or a reset of the connection happening. In the end, it killed my internet connection for a couple of minutes.
I changed the config to make the Switch not visible to HomeKit, so I can't accidentally press it. Maybe it's the same for you

Thanks @EpsilonAlpha! This solved my problem. I just hid the Bridge which probably caused the restart.


Update benchmark results

Codecov Report

Merging #83 (cc09af6) into master (44e16f4) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master       #83   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            3         3
  Lines          488       488
  Branches        93        93
=========================================
  Hits           488       488

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 44e16f4...cc09af6. Read the comment docs.


Broken configs

at first everything was ok unlit i restarted server
pastebin link to error: https://pastebin.com/kaFHQsnV
Crates.zip

Post all of your files. (/plugins/CrazyCrates/)


Custom Redirects

Manage custom 301 and 302 redirects to map old URLs to new locations when your content structure has changed.

Hi @ChiquitaV2 let me know if you are still working on this item. Thanks a lot.


Convert View to Mid Fi (Systems )

Definition of Ready

[x] Does this meet the INVEST criteria?
[x] Does this have a clearly defined user?
[x] Does this have an estimate?
[x] Does this have acceptance criteria?
[x] Does this have sufficient context (wireframes, business rules, etc.)?
[x] Is this traceable to a feature, epic, or PI?

User Story
As a user
I want to view MP systems using the mid fidelity design
So that I have a better experience
Acceptance Criteria
Given a user has accessed MP Systems
When it is viewed
Then it is displayed according to the wireframes
Context
https://xd.adobe.com/view/dccab567-3abe-484a-bff7-844d701cd4eb-8999/
Testing
Test Case: TC237
Tester: @mosesdeeCVP
Definition of Done

[x] Have all Acceptance Criteria been agreed to and validated by the scrum team?
[x] Has the code been unit tested and peer reviewed?
[x] Have the functional tests been executed?
[x] Have all defects been reviewed and dispositioned, resolved, or deferred?
[x] Has the user story been accepted by the Product Owner?
[x] Is the user story ready to be deployed to the test/staging environments?

Test Passed


Section 3 (Geometry) of specs should mention GeometryInstances

Currently, the Geometry section of the specification doesn't list GeometryInstances as one type of geometries. This is misleading as someone that doesn't read the whole document might be confused about what has to be done in order to support all possible geometry types.
I think just a simple warning in section 3 that references section 6 as an exception would solve the issue.

I think moving it to section 3 would be even better.

fixed for v1.01:
https://github.com/tudelft3d/cityjson/commit/57645735bb97901e0391d46e29ba4a655f955fb6


refactor: Support the move to having build files located in ./files/ in all modules

This would be the changes required for supporting https://github.com/blue-build/cli/issues/138.

Modules requiring refactor:

files
gschema-overrides
script
systemd

General refactor plan:
With the setup in config/, we require that each module use a specific subdirectory of config/ for its files. In my view, with a files/ directory in the root of the repository, it should be possible for any module to read from any subdirectory of files/.  Each module should check for the existence of /tmp/files/. If that directory exists, /tmp/config/ should be entirely ignored.
(Note: examples below use un-implemented files module syntax from #203)
Without such a refactor, a repo might look like this:
files/
   files/
      usr/
         ...
   gschema-overrides/
      ...
recipes/
   recipe.yml

With the following recipe:
# recipe.yml
...
modules:
  - type: files
    files:
      - source: usr/
        destination: /usr
  - type: gschema-overrides
    include:
      - zz1-myoverride.gschema.override

With such a refactor, a repo might look like this:
files/
   system/
      usr/
         ...
   gschema/
      ...
recipes/
   recipe.yml

With the following recipe:
# recipe.yml
...
modules:
  - type: files
    files:
      - source: system/
        destination: /
  - type: gschema-overrides
    include:
      - gschema/zz1-myoverride.gschema.override

Specific refactor details
systemd
The systemd module currently doesn't take in configuration for specifying the units to copy, rather it always copies them from config/systemd/system/ and config/systemd/user/. I am unsure how to refactor this module. It also does something easily doable with the files module.

@xynydev I think that we should keep gschema-overrides name of the folder, to reflect the name of the module.
Everything else looks good.

The systemd module currently doesn't take in configuration for specifying the units to copy, rather it always copies them from config/systemd/system/ and config/systemd/user/. I am unsure how to refactor this module. It also does something easily doable with the files module.

Well we can copy systemd units from files/systemd/system/ & files/systemd/user/ if files/systemd/ exists.
If not, use legacy location to copy files

@xynydev I think that we should keep gschema-overrides name of the folder, to reflect the name of the module.
files module is the exception here with files/system/, but not a rule, because files/files/ can be confusing to the users.

My point was that those folder names shouldn't be hardcoded IMO. So it could be files/gschema-overrides/and files/files/ if a user wants that.

My point was that those folder names shouldn't be hardcoded IMO. So it could be files/gschema-overrides/and files/files/ if a user wants that.

In that case, I agree.

So this idea I had might be too much to implement in the scope of this issue. However, I'm working on the Stages feature at the moment and ran into a particular issue of needing to copy between stages. I created the copy module that is pretty much a 1-1 translation of a COPY instruction. It looks something like this:
type: copy
from: ghcr.io/blue-build/cli:latest-installer
src: /out/bluebuild
dest: /usr/bin/

It would end up creating the instruction:
COPY --from=ghcr.io/blue-build/cli:latest-installer /out/bluebuild /usr/bin/

So I essentially re-implemented the "built-in" files module. However, I chose to make a new module cause I though of a potential extension of the files module. How about making the files module a way to perform regular file operations like mv, rm, chmod, chown, etc. Obviously we can adjust the scope to what we feel is appropriate. Just wanted to drop this idea here while you were in the process of refactoring.

IMV some of those file operations might be possible to commit into git, while most would be more straightforward to do with shell snippets. I wouldn't complicate the files module with them.
Your copy module also looks pretty good, but it has one crucial difference; the bash files module is one layer, but can perform multiple copy operations, while the copy module has to be repeated, and creates a layer for each copy operation. This usecase is something that the containerfile snippets already adequately fills, though, so creating a wrapper for it is really more of a convenience thing.

the bash files module is one layer, but can perform multiple copy operations, while the copy module has to be repeated, and creates a layer for each copy operation.

That's a good distinction. Alright fair enough

Being able to use a container image as a file source is something I had to resort to using the containerfile module for. You can see that Containerfile here. It would be convenient if the files module supported a from: argument which templated arbitrary --mount=type=bind,from= arguments.
I have a Github action which builds .srpms and .specs into RPMs and needed to get those RPMs into my overlay (that build container is here).
Thanks @gmpinder for mentioning that stage feature because it could potentially simplify things as long as caching works out. One of the spec files is Mesa and I don't want to be rebuilding that if I don't have to.

I think that we should keep gschema-overrides name of the folder, to reflect the name of the module.
(@fiftydinar)

Upon further reflection, this might actually be the way.
Many modules currently hardcode a folder name in their code to be copied in to the build, like systemd and gschema-overrides. Refactoring everything would be tedious, and require us to rethink many such features in current modules. Not to mention the pain users would have refactoring into this format. All for what? Less standardization in folder names?
If someone wants a system of 1-1 mapping with a folder in their repo corresponding exactly to the layout in their image, that will be possible with the files module. The module should probably be able to copy files from any directory in files/, to facilitate a user grouping their files in the directory however they want to.
I believe modules that process files in some way before copying them over from their corresponding directory might also be able to support such a structure, by processing the files in the destination folder.
It might be a good thing that I didn't rush to implementing the initial refactor, eventhough it didn't receive much of any pushback from y'all. Maybe some would have been warranted, too.
With that, here's my example from above updated to match my current thoughts.
Filesystem structure:
files/
   system/
      usr/
      etc/
         ...
   gschema-overrides/
      ...
recipes/
   recipe.yml

Recipe:
# recipe.yml
...
modules:
  - type: files # source path is relative to files/
    files:
      - source: system # this feels like it makes sense, and is very similar to the system_files structure used by ublue
        destination: /
  - type: gschema-overrides # copies from files/gschema-overrides/
    include:
      - zz1-myoverride.gschema.override

@xynydev This looks great to me, I find no issues with it. I am ready to start work on this.

Great! The only changes needed are is the files module. It should detect if there's /tmp/config or /tmp/files (I think), and change the relative path if the user has switched to the files directory.
I can handle the announcements and stuff, code-wise this should be a small change.

@xynydev I think that we should strictly switch all modules to use "${CONFIG_DIRECTORY}" instead of current hardcoded values in some of the modules.
Is it better to handle the logic of "${CONFIG_DIRECTORY}" in cli, rather then write that for all affected modules?
like, I'm not sure if this is enough:
if [[ -d "/tmp/config/" ]]; then
  CONFIG_DIRECTORY="${CONFIG_DIRECTORY:-/tmp/config}"
elif [[ -d "/tmp/files/" ]]; then
  CONFIG_DIRECTORY="${CONFIG_DIRECTORY:-/tmp/files}"
fi

Oh right, this logic is already handled in CLI.
Nvm, the PR above can get merged.


Update conditional-rendering.md

Indicating the element variable used in the example code of element variable.

@alexkrolick Kindly have a look and merge this PR, if you find the changes helpful. 😊


DatabaseWriter support for results coming from MissingValuesCalculator and UnseenValuesCalculator

Closes #313
Adds DatabaseWriter support for results coming from MissingValuesCalculator and UnseenValuesCalculator.

Hi @nnansters and @nikml 😄
For the moment I tested this code with pytest tests/io/test_writers.py, where I added fixtures for this. All tests passed there.
I can run the tests with poetry run tox as recommended in CONTRIBUTING at a later time. I only haven't run them that way because it would take some time for me to set it up on my machine within the conda environment.
In any case, looking forward to your feedback 🙂

Hey @bgalvao , sorry for taking so long on this. Let me blame it on the holiday period :sweat_smile:
I've added some tests to check the actual database writing and I found a bug in your newly added mappers. This caused them to not return any records so the database remained empty. Very quick fix, all is well now.
Just shows that I should've added those tests a long time ago!
Thanks a bunch for your contribution! Going to release this today or tomorrow!

Thanks!
I wished I had the time to add the tests myself hahaha
Cheers 🤙🏼


Improve the Testing experience

Creating this as a master issue for improving the testing experience and assigning to May for initial PMy tasks. For dev items we will most likely look into it from June.

[ ] Write testing docs @isidorn
[ ] Promote testing API so we get more extensions @isidorn
[ ] Convert mocha extension to fully use the new Testing API @connor4312
[ ] Add testing framework detection with decent recommendations @connor4312 @isidorn
[ ] Make viewlet visible by default with welcome text @connor4312 @isidorn
[ ] Make VS Code team selfhost more on Testing so we get more bugs and feedback @isidorn

fyi @hediet @MarcusFelling

Provide an option to not focus on the error peek view and change users' selection when the test failed. Otherwise, the watch mode is annoying if the related test files are opened.

This is configured via the testing.automaticallyOpenPeekView setting 🙂

@connor4312 Great! thanks

https://github.com/microsoft/vscode/issues/153879

This issue is outdated, and Connor is nicely driving the improvements to the Testing experience.
Thus closing this one. Thanks


WIN64 variadic calls

The changes so far make int vararg calls work.
To make fp args work they have to be duplicated into corresponding int regs. But that also would require patch up the call proto, adding those int regs?

Thank you for the patches.
I don't know WIN64 ABI.  So I can not check all your patches.
I am just curious what environment do you use to compile MIR on Win64 (native, mingw, cygwin; what compilers)?  I am curious because at the end I would like to have continuous testing on Windows too.

For Windows stuff I've got Windows 10 with MSYS2 MinGW-w64 gcc
I had to modify the make file a bit and cherry picked some of the changes from @warvstar fork from issue https://github.com/vnmakarov/mir/issues/15 to get c2m to build.
To finish varargs support I have to be able to copy from XMM to GP registers, which would be MOVD/MOVQ instructions I think. I don't see them in the patterns. How much work would it be to add them?

Thank you for the info.
As for mov gpr,xmminsn the pattern for this can be added easily.  The problem is that MIR does not support such moves when one register is a floating point operand and another is an integer operand.  Supporting this would require a medium size of work in MIR-generator.
Could you instead use memory as intermediate memory for this.  I guess you can use -8(sp) slot for this as I remember according to x86_64 ABI, it is permissible to use small number of stack slots below sp.


Bhavneet singh

Adding name

Hi, please add your name in alphabetical order.

Can you please attach a photo of where my name is? I attached in alphabetical order but don't know how it changed.


https://courses/80573/pages/1-dot-1-analisis-de-riesgos-financieros-descripcion-general?module_item_id=3665529

Checklist

[ ] I'm reporting a new site support request
[ ] I've verified that I'm running youtube-dl version 2021.12.17
[ ] I've checked that all provided URLs are alive and playable in a browser
[ ] I've checked that none of provided URLs violate any copyrights
[ ] I've searched the bugtracker for similar site support requests including closed ones

Example URLs

Single video: https://www.youtube.com/watch?v=BaW_jenozKc
Single video: https://youtu.be/BaW_jenozKc
Playlist: https://www.youtube.com/playlist?list=PL4lCao7KL_QFVb7Iudeipvc2BCavECqzc

Description

WRITE DESCRIPTION HERE

Use the template. Write a description of what support you are asking for.


Send monitoring information to Helge

[x] Add pull request to repo
[x] Add user that helge have requested

Infomration from the lecture notes:
Add a link to your monitoring dashboard via a pull request to the file misc_urls.py in https://github.com/itu-devops/lecture_notes. (Replace the URL "http(s):///" below the comment # Monitoring URL: with your respective URL. Link either a read-only dashboard or add a user with name and credentials that Helge provides you via the Teams chat channel, so that we can see what you are monitoring and can provide feedback on it in the start of the next session.

Add a link to your monitoring dashboard via a pull request to the file misc_urls.py in https://github.com/itu-devops/lecture_notes. (Replace the URL "http(s):///" below the comment # Monitoring URL: with your respective URL. Link either a read-only dashboard or add a user with name and credentials that Helge provides you via the Teams chat channel, so that we can see what you are monitoring and can provide feedback on it in the start of the next session.

Pull request sent
https://github.com/itu-devops/lecture_notes/pull/228

I have created  the user and given it "view" rights


Consider adding revision or timestamp attributes to in-blueprint resources

The idea here is for in-blueprint resources (resource pool allocations, VRFs, VNIs...) to output a value which can be used to trigger re-creation of the deploy (blueprint commit) resource.

Deploy is probably going to get baked into the provider code (not a standalone resource)


Debug locally example is incomplete

I cannot find a almost entire,runnable example of local debug.
[Debug locally] part shows part of the code, I consider that it's not handy for user to use it. Can we provide a complete demo and let user change the config he want?
I think local debug is very important, and it's the best tool to debug without ACI or AKS

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

ID: 3a077225-4fb9-57c8-6bf7-f6e22eef0870
Version Independent ID: bf5ce9ce-51a8-43e2-7362-e3de0e2ac63e
Content: Docker deployment troubleshooting - Azure Machine Learning
Content Source: articles/machine-learning/how-to-troubleshoot-deployment.md
Service: machine-learning
Sub-service: core
GitHub Login: @clauren42
Microsoft Alias: clauren

@mjaow Thanks for the feedback. We are investigating the issue and will update you shortly.

@mjaow You can refer the this notebook for detailed steps of a working environment to deploy a web service locally and use it for debugging.

@RohitMungi-MSFT yeah, that's the demo. But people cannot see the notebook in offical documents when they want to debug locally. I think that's the point

@mjaow We've added a reference to the notebook. @clauren42 Could you please review and approve the PR 122758?

awesome, thanks for help.


Starlight Tailwind injects incorrect colors in development

What version of starlight are you using?
0.9.0
What version of astro are you using?
3.0.6
What package manager are you using?
pnpm
What operating system are you using?
Windows
What browser are you using?
Brave 1.57.57
Describe the Bug
When starting a new project without Tailwind, the splash page looks the same in development and production, kinda like this:

Repro: https://stackblitz.com/edit/github-pluqrm?on=stackblitz

When adding Starlight Tailwind @ 2.0.0, development changes colors:

Repro: https://stackblitz.com/edit/github-pluqrm-zqmxmh?on=stackblitz

The colors are back to normal in production, however:

Repro: same link, just run npm run build && npm run preview in console
Link to Minimal Reproducible Example
https://stackblitz.com/edit/github-pluqrm-zqmxmh?on=stackblitz
Participation

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

It seems like the colors are injected here: https://github.com/withastro/starlight/blob/%40astrojs/starlight-tailwind%402.0.0/packages/tailwind/index.ts#L63
Is this intentional?

Starlight theme is defined here: https://github.com/withastro/starlight/blob/%40astrojs/starlight-tailwind%402.0.0/packages/starlight/style/props.css#L1

Hi @KubaJastrz it looks like this reproduction is missing steps 3-5 in our guide to setting up Tailwind here: https://starlight.astro.build/guides/css-and-tailwind/#add-tailwind-to-an-existing-project
Could you try following those steps and seeing if it works as expected?

Creating custom tailwind.css file and disabling the default one helped (both dev&prod use colors from starlight-tailwind).
Although I'm not sure why starlight-tailwind provides custom colors to begin with.
Anyway, thanks for help. I'll close this issue for now.


Project Import Error with VS2013 Update 4 and Cordova Tooling 0.3.1

Got an error when loading the project related to not finding an import for Microsoft.MDA.targets.
Took the following two lines out:
  <Import Project="$(AppData)\npm\node_modules\vs-mda-targets\Microsoft.MDA.targets" />
  <Import Project="$(AppData)\npm\node_modules\vs-mda-targets\Microsoft.TypeScript.MDA.targets" />

Replaced with their equivalents from a blank cordova project and all seemed to work well.
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CordovaTools\vs-mda-targets\Microsoft.MDA.targets" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CordovaTools\vs-mda-targets\Microsoft.TypeScript.MDA.targets" />

Happy to put in a pull request with changes if you'd like?

I tested this on a refresh VM running Windows 10 Technical Preview (Build 10049) with a brand new install of VS2013 Community Edition Update 4 and Cordova CTP 0.3.1. I was able to reproduce the issue and after putting your change into place everything seemed to work fine.
I think I wasn't encountering this issue on my primary development machine because I had a previous version of the CTP installed, so the files were still located in the old location.
I will commit these changes shortly. Thanks for the feedback!


cesium1.36 Model transparency

cesium1.36

cesium1.35
Find a problem, cesium1.36 The model becomes transparent,cesium1.35 Display normal

Would you be able to send over the model? That will help for debugging this.

I'm also observing this issue. When globe is on, depth test appears to be disabled for translucent geometry only. If you have our OfficeBuilding data set, that one exhibits it - or I can send a simpler test case.

Translucent.zip
Globe off (translucent red cylinder behind opaque green cylinder):

Globe on:

Thanks @pmconne for uploading the model, I'll start looking into this and #5734.

@pmconne It seems like this is caused by the recent architectural changes that allowed classification primitives to work on 3D Tiles - see https://github.com/AnalyticalGraphicsInc/cesium/issues/5676 for more context.
Now the globe and opaque 3D Tiles are rendered together into the same depth buffer, and their depth is cleared after classification primitives are rendered. This causes the red cylinder, which is in the translucent pass, to not depth test against anything.
For the time being our recommendation is to set scene.globe.depthTestAgainstTerrain to true, but we hope to have a better solution before the next release.

scene.globe.depthTestAgainstTerrain=true   Display normal，Thanks@lilleyse

Thanks @lilleyse , scene.globe.depthTestAgainstTerrain=true Display normal

@lilleyse  vector layer Will the next release increase?

@lilleyse vector layer Will the next release increase?

It's unlikely that vector tiles will be ready by the next release. Or do you mean something else?

Thanks @lilleyse  We refer to mapbox vector label and vector line , I wonder if it will increase  next release？

@lilleyse please close if you confirmed this is fixed in #5770.

Reopening to investigate @pmconne's use case when the globe is off.

I'm going to close this.  I got the same results @bagnell did


BUG - move after spawn & Spawn parent

If move after spawn is off but instantiate under spawn parent is on, the object does not spawn under the parent because spawn moves outside of the parent to stop moving. There might not be a fix for this in code in which case, I can create a simple workaround.

Spawns inside parents will have to inherit speed and direction of parent. This is going to be difficult to work around via code as this is a core behavior on Unity transforms.

@wadek2 Use of spawner parent transform for spawns can now only be enabled if movement after spawn is disabled.


Fix probe response

This PR resolve partially issue #1002. Also reported in the discussion #1033 .

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 85.21%. Comparing base (f8a8494) to head (4d3ad1e).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1037   +/-   ##
=======================================
  Coverage   85.21%   85.21%
=======================================
  Files          35       35
  Lines        7583     7583
=======================================
  Hits         6462     6462
  Misses       1121     1121

Files
Coverage Δ

ross/defects/abs_defect.py
95.65% <100.00%> (ø)

ross/results.py
87.70% <100.00%> (ø)

ross/stochastic/st_results.py
85.71% <100.00%> (ø)

Continue to review full report in Codecov by Sentry.

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


tendermint.private_peers should be only list of node IDs

Based on tendermint documentation and code , the tendermint.private_peers flag should only contain the private node ids (not id@address as we do now).
Some fixes needed:

in e2e tests we should only set IDs https://github.com/oasislabs/oasis-core/blob/e14f636dd4017e7cb6b48fc03e960265f0b7ca71/go/oasis-test-runner/oasis/args.go#L312
flag description should be updated
https://github.com/oasislabs/oasis-core/blob/e14f636dd4017e7cb6b48fc03e960265f0b7ca71/go/consensus/tendermint/tendermint.go#L1169
we might need to also lowercase the IDs (as we do for other IDs) since tendermint
https://github.com/oasislabs/oasis-core/blob/e14f636dd4017e7cb6b48fc03e960265f0b7ca71/go/consensus/tendermint/tendermint.go#L778
do some validation on the tendermint.private_peers parameter, to ensure it's indeed a list of IDs

in e2e tests we should only set IDs
flag description should be updated
we might need to also lowercase the IDs (as we do for other IDs) since tendermint

The first 3 are implemented by #2388.

do some validation on the tendermint.private_peers parameter, to ensure it's indeed a list of IDs

I would defer this one to a separate issue that would systematically validate all tendermint flags (or even broader?) where strings need to correspond to a prescribed form.


Update to paimon-0.8-SNAPSHOT And presto-0.287

更新pom中presto版本为0.287,paimon为0.8,已测试presto-0.287可用

@JingsongLi
Please integrate support for the new version and verify the release. Thank you.
The https://paimon.apache.org/docs/master/project/download/ is not availabled now.

+1


Create Secure Design & Coding Practices Doc

Draft a Secure Design & Coding Practices doc using the template.
Definition of done:

[ ] doc drafted
[ ] peer reviewed by PO and devs

It was already done 💀


Update GetStarted.md

Docs Build status updates of commit 491cbe3:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

windows-iotcore/GetStarted.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[Feature] add new numeric asymmetric matchers

Summary

Add new asymmetric matcher options, so we can have something similar to the stringMatching , and stringContaining matchers, but for numbers. This request was requested on the issue #12020
This PR adds the following matchers:

numberGreaterThan
numberGreaterThanOrEqualTo
numberLessThan
numberLessThanOrEqualTo

  test('number is greater than or equal 20', () => {
    const example = { number: 32 };
    expect(example).toEqual({
      number: expect.numberGreaterThanOrEqualTo(20),
  });

Hm.. The build is failing for me. Something is wrong with typings. Could you check:

Hm.. The build is failing for me. Something is wrong with typings. Could you check:

I forgot to add the  matchers to the expect object. It should be working now.

Thanks for sending a PR! However, like https://github.com/facebook/jest/pull/13675#issuecomment-1369433292, I don't think we wanna add more matchers to core. I'd be happy to land it in jest-extended though 👍


Fixed #3520 Validate accepted status codes type

⚠⚠⚠ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma
Tick the checkbox if you understand [x]:

[x] I have read and understand the pull request rules.

Description
Check type of status code range to ensure it is a string before we start running string operations on it.
Fixes #3520
Type of change
Please delete any options that are not relevant.

Bug fix (non-breaking change which fixes an issue)

Checklist

[x] My code follows the style guidelines of this project
[x] I ran ESLint and other linters for modified files
[x] I have performed a self-review of my own code and tested it
[x] I have commented my code, particularly in hard-to-understand areas
(including JSDoc for methods)
[x] My changes generate no new warnings

The real problem is that checkStatusCode should not be throwing errors. Since it is running inside axios, any error would crash the server. We should just default to returning false instead.

The real problem is that checkStatusCode should not be throwing errors. Since it is running inside axios, any error would crash the server. We should just default to returning false instead.

That does kinda make sense, but we should make sure that we say something in the log while we do it.

The behaviour of checkStatusCode has been modified slightly, now when it encounters an invalid status code range, the error will be logged and the function will continue for all the other accepted status codes.


Search Results page clickable fields

On the search_results page after clicking 'See all results for 'search term' a user can only click on 'See all' for Records of Vessels or Captains & Crew or Boardings. Users should also be able to click on the vessel or person or boarding record shown on the page and go directly to that record - as if they had clicked through to the 'See all' page and then clicked that record. It will save 2 clicks and is what the users expect.

Blocked waiting design.


More tests for multiple dispatch

A few more tests for multiple dispatch. The namespace_for_new test implements a new signature for a function in the namespace, and Morpho does run that implementation. Not sure what the intended behavior is here. I feel like this should be allowed as it will allow users to re-use code nicely.
Not sure about the namespace_for_overwrite, which tries to redefine an already existing implementation from the namespace. I think this should just result in a standard multiple dispatch error of matching signatures.
duplicate_no_types_two_arguments is same as the duplicate test, but the signature doesn’t contain types. This works correctly. The duplicate_no_types however has duplicate functions with a single untyped argument, and this fails due to a segfault. So does the namespace_for_overwrite test.
The segfault is due to a compiler infinite loop (see block comments in the files for a backtrace).
Edit: Upon adding another duplicate test with a single typed argument that also fails, the problem seems to be for functions with one argument, and less to do with Type annotations.

Great news, these were all from the same issue—mfcompile_set was failing to check whether the parameter had already been checked for single parameter functions. The same fix seems to repair all these failing examples. Thanks for these @joshichaitanya3!


Validate resources that share the same flavors in a ClusterQueue

This is a spinoff from https://github.com/kubernetes-sigs/kueue/issues/167#issuecomment-1180786466, and a pre-requisite for #296
We need to validate that, in a ClusterQueue two resources either have completely different flavors or they must share all flavors, in the same order

/kind feature

in a ClusterQueue two resources either have completely different flavors

Why? This is too strict. I think this is similar to cluster autoscaler, when scaling up, we may have some kinds of nodes as the first choice, but we may still have fallback choices in case of insufficient of the preference ones. They maybe general nodes(compared to high-performance nodes), pay-as-you-go ones or preemptible instances. This kind of nodes can be shared by different node pools.
In terms of flavors, it's same, we may have some kinds of nodes for general usage which referenced by a special flavor and meets the requirements of different resources.
Some immature ideas, is it possible to add quota to resourceFlavor instead of clusterQueue, the resourceFlavor refers to special type of resources, quota can also be part of the resource properties. Currently, resourceFlavor only plays a role as nodeAffinity, which can also achieved by other ways like pod's selector. It seems we haven't leverage it totally.

I think the idea wasn't clear. With the proposal, this should be possible (removing the quotas just to show the point):
  resources:
  - name: "cpu"
    flavors: ["spot", "ondemand"]
  - name: "memory"
    flavors: ["spot", "ondemand"]
  - name: "example.com/gpu"
    flavors: ["a100", "t4", "k80"]

In this case, CPU and memory are coupled together. When a workload is assigned to this ClusterQueue, it would be given the same flavor for CPU and memory. The next workload could get a different flavor, but it needs to be the same for CPU and memory as well.
Achieving this coupling would be difficult if we allowed something like this:
  - name: "cpu"
    flavors: ["spot", "ondemand"]
  - name: "memory"
    flavors: ["spot", "default"]

Note that the limitation is within one ClusterQueue. If there is another ClusterQueue in which CPU and memory don't need to be coupled, they can use different flavors.

Some immature ideas, is it possible to add quota to resourceFlavor instead of clusterQueue, the resourceFlavor refers to special type of resources, quota can also be part of the resource properties. Currently, resourceFlavor only plays a role as nodeAffinity, which can also achieved by other ways like pod's selector. It seems we haven't leverage it totally.

See the motivation for ResourceFlavor here: https://github.com/kubernetes-sigs/kueue/issues/59
Basically putting the node labels in a separate object prevents multiple ClusterQueues from definining the same flavor but with different labels.

Still think we should allow this configurations.
  - name: "cpu"
    flavors: ["spot", "on-demand"]
  - name: "memory"
    flavors: ["spot", "default", "on-demand"]

This is actually a fallback strategy, common in use.
pseudo-code below:
loop:
for podSet in TotalRequests {
    qualifiedFlavors, ok := findFlavorsMeetThePodSetResourceRequirements()
    if !ok {
        return error
    }

    for flavor in qualifiedFlavors {
            if meetResourceQuotaRequirements {
                assignFlavors()
                break loop
            } else {
                continue
            }
    }

    if haveCohort {
        for flavor in qualifiedFlavors {
              ok = borrowFlavorSpecifiedResources()
              if ok {
                  assignFlavors()
                      break loop
                  }
               return error
        }
    }
}

That particular example doesn't make sense to me: "spot" and "on-demand" are the opposite, and thus they cover all the possibilities. Also, why wouldn't "cpu": ["spot", "default", "on-demand"] not make sense?
In which case you could assign "cpu": "spot", "memory": "default"?

/assign

/priority important-soon


Add reference to Wire Data 2.0

Added a reference to Wire Data 2.0 as the replacement to 1.0.

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

@MikeBazMSFT : Thanks for your contribution to the Azure documentation! The author, @bandersmsft, has been notified to review your proposed change.

@MikeBazMSFT : Thanks for your contribution to the Azure documentation! The author, @bandersmsft, has been notified to review your proposed change.

@MikeBazMSFT : Thanks for your contribution to the Azure documentation! The author, @bandersmsft, has been notified to review your proposed change.

#sign-off


Unexpected result in insn_div when dividing by 0 when not using RISCV_FORMAL_ALTOPS

When I run the insn_div test (without defining RISCV_FORMAL_ALTOPS) it always stops with an error after retiring any division by 0 instruction. After examining the counter trace I noticed that the signal rvfi_testbench.checker_inst.insn_spec.spec_rd_wdata is equal to 1 instead of -1.
I believe the problem is this line:
https://github.com/SymbioticEDA/riscv-formal/blob/61d8b16751bd18d9810711eefbfb2ade87a5081c/insns/insn_div.v#L49
I have already read the description of RISCV_FORMAL_ALTOPS here but I think this define should also be listed in the Configuration Macros doc.
By the way, thanks for this great project. I have already caught some bugs in my implementation since I started using this framework.

After examining the counter trace I noticed that the signal rvfi_testbench.checker_inst.insn_spec.spec_rd_wdata is equal to 1 instead of -1.

That's interesting. What solver did you use? Because SMT-based solvers, like the ones used by default in SymbiYosys, should interpret x/0 as -1. But of course other engines might have different definitions. I've now added explicit handling of x/0 and INT_MIN/-1 to the instruction models.

I'm using Boolector Version 3.0.1-pre master.


Add premium & level to Play TTS and improve TalkPayload

This PR adds the level and premium fields to the StartTalk endpoint, whilst also refactoring the request object to use the builder pattern. Also adds test for the DownloadRecording endpoint to improve coverage.

Codecov Report

Merging #442 (c667ef4) into main (54f303e) will increase coverage by 0.18%.
The diff coverage is 91.83%.

@@             Coverage Diff              @@
##               main     #442      +/-   ##
============================================
+ Coverage     91.53%   91.71%   +0.18%
- Complexity     1796     1806      +10
============================================
  Files           305      305
  Lines          4865     4866       +1
  Branches        222      226       +4
============================================
+ Hits           4453     4463      +10
+ Misses          321      312       -9
  Partials         91       91

Impacted Files
Coverage Δ

...main/java/com/vonage/client/voice/CallsFilter.java
100.00% <ø> (ø)

...in/java/com/vonage/client/voice/EmbeddedCalls.java
100.00% <ø> (ø)

...c/main/java/com/vonage/client/voice/Recording.java
62.50% <ø> (+62.50%)
:arrow_up:

...ain/java/com/vonage/client/voice/TalkResponse.java
71.42% <0.00%> (ø)

...main/java/com/vonage/client/voice/TalkPayload.java
94.59% <93.75%> (+4.59%)
:arrow_up:

src/main/java/com/vonage/client/voice/Call.java
96.72% <100.00%> (ø)

...ava/com/vonage/client/voice/StartTalkEndpoint.java
100.00% <100.00%> (ø)

...main/java/com/vonage/client/voice/TalkRequest.java
100.00% <100.00%> (+8.69%)
:arrow_up:

...main/java/com/vonage/client/voice/VoiceClient.java
97.14% <100.00%> (+0.36%)
:arrow_up:

... and 1 file with indirect coverage changes


RFE: touch a file to make it easy to tell we're containerized

/kind feature
Description
AFAICT, there isn't a file like /.dockerenv to make it easy to tell we're in a container. Can we add something like /run/podman-container?

This seems like an easy enough thing to do

That sounds OK too. I find /run nicer to indicate the ephemeral nature of it though that's mostly personal preference. :)

/run/.containerenv would be fine by me too.  My main thing was to not include the d-word....

Is there anything we should look into including in the that would be helpful, besides its existence? Podman version, potentially?

Hmm, how about we just leave it empty for now? Adding things later on if we really want would be a mostly backwards compatible change.

Will this work with readonly containers?  Should the file be read-only, should we make sure the file does not end up in an image?  Putting the file in /run, would be my preferred mechanism to.  Adding the version of the tool that created the file inside buildah-1.13 or podman-0.3.3

If we add a file, like dockerd does, but give it a different name, then we're not reducing the amount of work required for anyone.  systemd suggests setting container in the environment to a short value that identifies the implementation.  Would that work for the use case?

Yes systemd like container=podman or container=buildah to be set.

Fixed in #533


Added xSPVisioServiceApp

Initial commit for xSPVisioServiceApp

Hi @NikCharlebois, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

@NikCharlebois Thanks for the PR, a couple of things I'll need before I can merge this one:

Need to fix the text formatting (look at the failing test, it sees tabs in MSFT_xSPVisioServiceApp.psm1 and MSFT_xSPVisioServiceApp.schema.mof)
Need a unit test set to cover this resource. Have a look at one of the simple service apps we have like the BCS one and pretty much copy that one

Let me know if you need any help with those so we can get this one merged in. Thanks Bud


block_users_controller.rb

module Api::V1
  class P2pTrades::BlockUsersController < Api::BaseController
    include ::P2pTrades::BlockUserHelper

    def index
      render json: get_blocked_users
    end

    def create
      response = P2pApi::Requests::BlockUser::CreateService.new(
        profile_id: current_user.profile.external_id,
        trade_id: @trade.external_id,
        params: block_user_params
      ).call

      if [200, 201].include? response[:status]
        render json: response
      else
        render json: response, status: response[:status]
      end
    end

    def update
      response = P2pApi::Requests::BlockUser::UpdateService.new(
        id: params[:id],
        params: block_user_params
      ).call

      if [200, 201].include? response[:status]
        render json: response
      else
        render json: response, status: response[:status]
      end
    end

    def destroy
      response = P2pApi::Requests::BlockUser::DeleteService.new(id: params[:id]).call

      if [200, 201].include? response[:status]
        render json: response
      else
        render json: response, status: response[:status]
      end
    end
  end
end

Here’s a breakdown of the Api::V1::P2pTrades::BlockUsersController class:
Overview
This controller is responsible for managing blocked users within a peer-to-peer (p2p) trading system. It provides endpoints for listing, creating, updating, and deleting blocked users.
Actions

index

Purpose: Retrieves and returns a list of blocked users.
Implementation: Calls the get_blocked_users method (likely defined in the P2pTrades::BlockUserHelper module) to fetch and return the list of blocked users as JSON.

create

Purpose: Creates a new block user record.
Implementation:

Initializes P2pApi::Requests::BlockUser::CreateService with the current user's profile ID, trade ID, and block user parameters.
Calls the service to create the block user record.
Returns the response from the service, including appropriate HTTP status codes.

update

Purpose: Updates an existing block user record.
Implementation:

Initializes P2pApi::Requests::BlockUser::UpdateService with the ID of the block user to update and the updated parameters.
Calls the service to perform the update.
Returns the response from the service with the appropriate HTTP status codes.

destroy

Purpose: Deletes a block user record by ID.
Implementation:

Initializes P2pApi::Requests::BlockUser::DeleteService with the ID of the block user to delete.
Calls the service to perform the deletion.
Returns the response from the service with the appropriate HTTP status codes.

Helpers

include ::P2pTrades::BlockUserHelper

This module likely contains helper methods used within the controller, such as get_blocked_users.

Key Points

Error Handling: Each action checks the HTTP status codes of the service responses and responds with the appropriate status and data.
Authorization and Validation: Ensure that the methods used within the controller, such as block_user_params, are properly validated and authorized.

Possible Improvements

Parameter Validation: Ensure that block_user_params contains the necessary validation to prevent invalid data from being processed.
Error Handling: Add more detailed error handling and logging to capture issues that may occur during interactions with external services.
Testing: Write comprehensive tests for each action to verify behavior and handle edge cases.

This controller should effectively manage the operations related to blocked users in your API. If you need any more details or have specific questions, let me know!


no overshields on target of target

There is no overshields information for the "target of target" element in Dragonflight.

Gonna look into this now. Sorry for late response.