Prevent screen termination on back press during detail transition

Issue

close #661

Overview (Required)

Updated navigation-compose from 2.8.0-alpha08 to 2.8.0-alpha09.
The new version, 2.8.0-alpha09, is based on Jetpack Navigation 2.8.0-beta05, which includes important fixes introduced in 2.8.0-beta04.

https://developer.android.com/jetpack/androidx/releases/navigation#2.8.0-beta04

Fixed an issue in Navigation Compose where after canceling the Predictive Back Gesture, the NavBackStackEntry that the user returns to never returns back to the RESUMED Lifecycle State. This also ensures the returning destination correctly animates back in instead of snapping into place after a fling. (I97a0c, b/346608857)

(This is likely the relevant fix.)

Fixed an issue where the iOS build was failing due to the Skiko dependency being updated from 0.8.9 to 0.8.11.

Request
I'm not entirely sure if the changes made in this commit are correct: https://github.com/DroidKaigi/conference-app-2024/pull/740/commits/2ad5b97e31c3649ba53431d9846c80f6aba44aed. I have tested building the iOS app and confirmed that the Contribution screen remains unchanged. If you notice anything unusual or have any feedback, I would greatly appreciate your comments.
Links

https://github.com/JetBrains/compose-multiplatform/releases/tag/v1.7.0-alpha03

Navigation libraries org.jetbrains.androidx.navigation:navigation-*:2.8.0-alpha09. Based on Jetpack Navigation 2.8.0-beta05

Screenshot (Optional if screenshot test is present or unrelated to UI)

Before
After

Movie (Optional)

Before
After

I will fix it so that the iOS test will pass.

I'm not sure, but compose-navigation 0.9 might fix the problem with screenshots as well. 👍

About the font, I'm not sure either. So let's merge this! Thank you for finding the solution for this.


[AVM Module Issue]: Log analytics workspace created even if default value is null

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Issue Type?
Bug
(Optional) Module Version
No response
(Optional) Correlation Id
No response
Description
Hello,
log analytics workspace can be null (https://github.com/Azure/terraform-azurerm-avm-ptn-aks-production/blob/main/variables.tf#L86-L90) but the module is creating one.
  # module.dev_cluster.azurerm_log_analytics_workspace.this will be created
  + resource "azurerm_log_analytics_workspace" "this" {
      + allow_resource_only_permissions = true
      + daily_quota_gb                  = -1
      + id                              = (known after apply)
      + internet_ingestion_enabled      = true
      + internet_query_enabled          = true
      + local_authentication_disabled   = false
      + location                        = "westeurope"
      + name                            = "log-aks-dev-001-aks"
      + primary_shared_key              = (sensitive value)
      + resource_group_name             = "rg-aks-dev-001"
      + retention_in_days               = (known after apply)
      + secondary_shared_key            = (sensitive value)
      + sku                             = "PerGB2018"
      + workspace_id                    = (known after apply)
    }

main.tf
resource "azurerm_resource_group" "this" {
  location = var.location
  name     = var.rg_name
}

resource "azurerm_user_assigned_identity" "this" {
  location            = azurerm_resource_group.this.location
  name                = "umi-${var.kubernetes_cluster_name}"
  resource_group_name = azurerm_resource_group.this.name
}

module "dev_cluster" {
  source = "Azure/avm-ptn-aks-production/azurerm"
  version = "0.1.0"

  kubernetes_version  = "1.28"
  enable_telemetry    = false
  name                = var.kubernetes_cluster_name
  resource_group_name = azurerm_resource_group.this.name
  managed_identities = {
    user_assigned_resource_ids = [
      azurerm_user_assigned_identity.this.id
    ]
  }
  agents_tags = {
    type = "compute"
  }
  location = var.location
  node_pools = {
    workload = {
      name                 = "workload"
      vm_size              = "Standard_D2d_v5"
      orchestrator_version = "1.28"
      max_count            = 20
      min_count            = 2
      os_sku               = "Ubuntu"
      mode                 = "User"
    }
  }
}

Hello,
this is according to our design, we force the use of Log Analytics to force the collection of logs.
If you need to disable Log Analytics completely you can use the module:
https://github.com/Azure/terraform-azurerm-aks

@gevraud thank you. Testing this I actually spotted an unused variable in our code that made everything more confusing. I am fixing this in PR #59


Fixing bug on stuck content-type header in Feature Testing

Supersedes #7079
When I use FeatureTestTrait if I use withBodyFormat('json') function on one request all subsequent requests are sent with content-type: application/json even if their body format is not 'json'.
This bug started when I upgraded CI from 4.0.x to 4.2.11. After long investigation I think I found the source of the problem. On line 289 initialization of request has been changed to Services::request($config, true) so for each subsequent test request same instance is used. That's why if content-type on one request is set then all other requests are sent with this header.

Description
Explain what you have changed, and why.
Checklist:

[x] Securely signed commits
[ ] Component(s) with PHPDoc blocks, only if necessary or adds value
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[x] Conforms to style guide

@baycik Thank you for sending PR!
This seems good.
Can you squash the commits? It is only one line change.

Yes it contains unnecesarry changes becase initially I thought to comment return statement to reset content-type header before every request;
Unfortunately I can't find how to do the squishing on github. So if this PR is not suitable to you make the change your self to fix the bug.

Unfortunately I can't find how to do the squishing on github.

Just squash the commits on your local PC, and force push to GitHub.
But if you can't do it, no problem.

@baycik Thank you!


Toolbox error - spaces in filename

This issue was imported from CodePlex
bogusman wrote 2011-04-12 at 01:46
Hope this is the right place for this. Have been working with the example in the Getting Started Guide and have received the following error:
System.Xml.XmlException was unhandled by user code
Message=An error occurred while parsing EntityName. Line 6, position 70.
Source=System.Xml
LineNumber=6
LinePosition=70
SourceUri=file:///C:/Users/seank/AppData/Local/SantaRosaUtilities/ToolManagerSettings.xml
StackTrace:
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.Throw(String res, Int32 lineNo, Int32 linePos)
   at System.Xml.XmlTextReaderImpl.HandleEntityReference(Boolean isInAttributeValue, EntityExpandType expandType, Int32& charRefEndPos)
   at System.Xml.XmlTextReaderImpl.ParseAttributeValueSlow(Int32 curPos, Char quoteChar, NodeData attr)
   at System.Xml.XmlTextReaderImpl.ParseAttributes()
   at System.Xml.XmlTextReaderImpl.ParseElement()
   at System.Xml.XmlTextReaderImpl.ParseElementContent()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.XmlLoader.LoadNode(Boolean skipOverWhitespace)
   at System.Xml.XmlLoader.LoadDocSequence(XmlDocument parentDoc)
   at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
   at System.Xml.XmlDocument.Load(XmlReader reader)
   at System.Xml.XmlDocument.Load(String filename)
   at DotSpatial.Controls.ToolManager.LoadSettings() in c:\Dev\DotSpatial\DotSpatial.Controls\DotSpatial.Controls\ToolManager.cs:line 193
   at DotSpatial.Controls.ToolManager.RefreshTree() in c:\Dev\DotSpatial\DotSpatial.Controls\DotSpatial.Controls\ToolManager.cs:line 290
   at DotSpatial.Controls.ToolManager.OnCreateControl() in c:\Dev\DotSpatial\DotSpatial.Controls\DotSpatial.Controls\ToolManager.cs:line 79
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl()
   at System.Windows.Forms.Control.SetVisibleCore(Boolean value)
InnerException:
The error is being caused by the spaces in the ToolManagerSettings.xml file:

Deleting the settings file and rerunning the project from a folder w/o spaces, it works as expected.
Bo

Not actual


Breadcrumbs

As a user/teacher/admin, I want to have breadcrumbs in the interface,
so that I can navigate between pages more easily and track where I am within the application.
Acceptance Criteria

Breadcrumbs dynamically display the current page hierarchy and updates appropriately as the user navigates.
Component follows the style guide for size, font, colors, and spacing.
Added to all multi-level navigational pages.

Tasks

Add on every page except the Landing page as "Home / Results / Add Results" or "Home > Results > Add Results"

Remove the blue clock icon on the mobile version (just below the navigation bar)

Text color: Medium Gray (#757575) with primary color on the current page

Font: Roboto

Size: 16px

Position: Below navigation bar on the left side

The breadcrumbs should be added to the style guide under "Links/Breadcrumbs"

[x] mobile

[x] computer

Added breadcrumbs to all multi-level pages, with font Roboto, a font-size of 16px, gap of 24px for desktop and 16px for mobile, in the color medium gray (#f5f5f5).
Changed H1s on "results" and "change user" to match the navigation.
Added the breadcrumbs to the style-guide under typography.
Removed the blue clock icon on mobile.

Sure! I will check it out now!

Thank you :-) Amazing! The figma file is starting to look really good now!

Review complete! :-)


Function profiling

Adds a couple tests that merely wrap functions, which may be useful for the profiling being undertaken in #208 .
Might not actually merge this, if we can find an alternative way to do it that doesn't add these tests that aren't really testing much.
cc: @cheelee

I'm not sure myself, but they are nice in that they isolate the calls so we can drill down into how much time each subsequent function down the call tree costs.
I'm trying to find out if cProfile will do call-path profiling as opposed to producing a flat profile. Characterizing how a piece of code performs gets a lot easier with a callpath profile over a flat one. Of course call-path profiles are more expensive to collect.


Issue #504

Sorry this took a while

Code looks awesome! I'll test it out before merging ✅
I hope to finally get back to VHA development this or next month 🤞 -- have been busy with house stuff 😅

Awesome, congrats on the house stuff! 👍

🙇 Thank you very much @23mwest for your contribution 🎉
I might add a line or two to catch a possible weird edge case (though I'm unsure if it ever would happen -- the showWizard property might be true when a user exits - just don't want the app to get stuck in a weird state -- so I'll test a thing or two, even though I already merged it).
One minor addition I'll add is to add the wizard property to the SavedObject interface ✅


Optimizer for weights in custom layer can not be assigned

Hi,
I've implemented a custom layer with four weigths/bias-variables. Build the layer works fine, but when it comes to training there are no optimizers assigned for the weights. I'm using sgd as optimizer.
I debugged into keras.training and keras.optimizers and found that there must be some kind of bug.
In the get_updates method of keras.optimizers module should the optimizers be loaded:
 def get_updates(self, loss, params):
        grads = self.get_gradients(loss, params)
        ...

This loads the optimizers for every weight from the other layers, but None for the weights of my custom layer.
So i went a little deeper until i got to tf.gradients (which is located in gradients_impl.py):
def gradients(loss, variables):
    ...
    return tf.gradients(loss, variables, colocate_gradients_with_ops=True)

There happens a lot of stuff I don't get... but it seems like a grads dict is build which stores a lot of gradients/optimizers and at the end it extracts the gradients for the weigths from this dict:
return [_GetGrad(grads, x) for x in xs]
def _GetGrad(grads, t):
  """Gets gradient for tensor "t"."""
  op = t.op
  op_grads = grads.get(op)  #<---- This is allways None for custom-layer weights
  if not op_grads:
    return None
  t_grad = op_grads[t.value_index]
  assert not isinstance(t_grad, list), (
      "gradients list should have been aggregated by now.")
  return t_grad

Has anyone an idea why this happens?
In call-method i'm using methods from keras.backend, tensorflow, activation-funtions from keras (softmax, sigmoid), keras-layers (Lambda, TimeDistributed) applied to tensors and standard for loops. Am I just allowed to use keras.backend-methods? If so is there an equivalent for tf.TensorArray? Is it allowed to use other layers on e.g. the input-tensor in the call-method? Is there an keras/tf iterator to handle list elements?
I would appreciate any help or hints
Thanks in advance

Figured it out on my own and will share this if someone else has the same problem. Generally you have to watch out to only use Keras or tensorflow (or other backend) functions in the call-method. You got to do this because all the operations applied to your input and weights are stored in a chain-like data-structure which at the end connects your output tensor to the input and weights. In training this data-structured will be extracted to get the weight-tensors. It seems to me that if you don't use keras/tf functions that the chain gets broken and so the weights can't be extracted.
No guarantee on this, just what I explored during fixing this bug.
Problem in my case was the for-loop which I replaced by tf.map_fn. I also got rid of other keras layers but I don't know if this has any effect or not.


⚠ Bofrost.lu has degraded performance

In 0a8a238, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1314 ms

Resolved: Bofrost.lu performance has improved in e2fb97c.


initialCountry method triggers unsavedChangesAlerts without actual changes

Hello Ysfkaya,
I'm encountering an issue with the PhoneInput component when used in conjunction with Filament's unsavedChangesAlerts() feature. Specifically, the PhoneInput component appears to trigger an unsaved changes alert even if no modifications have been made to the input field, provided that the initialCountry method is used.
Steps to Reproduce:

Add the unsavedChangesAlerts() method in a panel configuration file.
Include a PhoneInput field in the form and initialize it with a country code using PhoneInput::make('phone')->initialCountry('us')
Navigate to the form in the Filament admin panel and observe that the unsaved changes alert is triggered even without any user interaction with the PhoneInput field.

Thank you for your assistance and for maintaining this useful component.

Hey @abournavaud
I will try to deal with this problem as soon as possible.

Hey @abournavaud
Now I have applied the steps you specified and I could not encounter a problem as you said. Are you sure that there is no other component in the form elements that triggers the unsaved changes alert event?
https://github.com/ysfkaya/filament-phone-input/assets/16710972/7e94dae9-0fea-4ed8-935f-55cd265b0311

Hey @ysfkaya,
I've just done some more research and the anomaly occurs in several cases.
I'm using ->initialCountry('FR'). When my phone number is saved in the format "+33606060606" or "+33 6 06 06 06 06" the  unsaved changes alert event is not triggered.
However, if the recorded format is "0606060606" or "06 06 06 06 06", the unsaved changes alert event will be triggered.
When I add ->inputNumberFormat(PhoneInputNumberType::NATIONAL), the unsaved changes alert event is triggered regardless of the format.

Ok I have released a new version for this. You can check it by updating to version 2.3.5

It works, thank you.


canvas: check return value of calloc

Pointers returned from calloc were not checked for NULL before being dereferenced (CWE-690). This patch adds the missing checks.

This is great. Thank you.


fix material use in android not work

This line of code appears to affect Android phones on Qualcomm's platform，This line of code will not work without it

@googlebot

@googlebot

@googlebot

@googlebot

@googlebot I fixed it.

@googlebot I fixed it.

@googlebot I fixed it.

@googlebot I fixed it.


clean Ember.merge deprecation and fix jshintrc

Since 2.5 Ember.merge raises a deprecation. This PR fixes that and makes sure the addon would still work with versions Ember that still don't implement assign and in browser environments that have Object.assign.
Fix .jshintrc deprecated opts.

Thanks!


Support for Buffered Audio Data

This pull request adds the CLI flag --buffered, which allows the audio data to be loaded on-demand through an I/O buffer instead of all at once at the beginning. This provides an alternative resolution to the problem addressed in #2256. The default memory limit is dictated here, but shouldn't matter much since it's not a bottleneck.
Support for buffered input also paves the way towards real-time tasks (#2): the changes were directly adapted from kentslaney/realtime-whisper, which already supports live PCM data. In order to keep the PR from being any larger than it already is, changes were limited to the minimum motivating feature. I'm making a PR instead of keeping it as a wrapper because it reuses/refactors large chunks of transcribe, which the current scoping makes inaccessible for patching.
The buffered version will perform almost exactly the same set of operations, with a small (vanishing) difference in the preprocessing output. The log mel spectogram is clamped below to have a maximum range of 8. The original transcribe method computes the upper bound from the entire file's spectogram, while the buffered version clamps the values relative to the maximum in the chunks processed so far. I have done some regression testing to confirm that the refactored (non-buffered) solution will make the same calls as the existing one.
I realize this is a rather large PR. Please let me know if these changes are outside the scope of the repo or if there's anything I can do to make it easier to review.

Uploading Screenrecorder-2024-07-22-02-17-04-378.mp4…

Vv


⚠ Bofrost.be has degraded performance

In 693fb1f, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1119 ms

Resolved: Bofrost.be performance has improved in da40b4e.


RFC: Move to atsamd-rs organization

I think there are enough folks contributing to enough boards that this makes sense to do, and it should streamline progress.  We recently went through a similar process for the nrf-rs family of boards.
Here's what I'm proposing:

I'll create the organization and move this repo into it, so that it ends up being named something like atsamd-rs/atsamd  (I've omitted the 21 because I have an atsamd51 that I think we can support with basically the same HAL).
I'll create a github team for the purpose of owning the crates on crates.io, with members comprising the folks that contributed the boards and published to crates.io
We each add that team as an owner of the various crates which we have access, so that any of us are now able to push to the repo (but see below!) and publish to crates.io
Members of the team will need to enable 2FAC for their github account; this will be enforced through githubs existing controls such that github will automatically remove you from the team if 2FAC is disabled.

While we'll all have the ability to push, I'd like to encourage the use of pull requests to solicit input and feedback before unilaterally pushing.   I'm generally in favor of making forward progress, so if you do have push access and haven't had feedback within a reasonable time, or if in your best judgement the change you want to push is non-controversial and/or low risk, then I think it's fine to push.   As a reviewer, if you'd like to have a chance to weigh in but don't currently have time then communicating that and a rough ETA on the pull request is a good idea.
Thoughts?  Concerns?
@zklapow @djmcgill @BenBergman @sajattack @bfritz

Would it be good to split the board crates out into different repos in the org?

Would it be good to split the board crates out into different repos in the org?

No, and yes :)  I'm a proponent of the monorepo concept, where the related projects live in the same repo rather than being separate repos.  There are some nice benefits from doing this:

It is possible to atomically refactor across all of the related projects in a single commit, and more importantly, to atomically roll back a change in a single commit
Github has no support for dependent, cross-repo pull requests, making it difficult to compose, review, run CI and ship a change that touches multiple areas, so having a single repo means that we sidestep this issue; pull requests that make changes to the hal need to be accompanied by the corresponding changes to the board support crates in order for the CI to pass which reduces the chances of accidentally breaking a board crate that you haven't directly changed.

A potential downside of this is that updating a lot of board support crates becomes burdensome.  I think we're still in a reasonable place given the current set of board crates, especially since they are all very similar.  I am prepared to spill things out of the main repo should it start to feel painful, but will likely keep a couple of boards in the repo because of point 2 above.

I'm generally against mono-repos, but I think it makes sense in this instance where everything needs to update together or it might not make sense. Semver definitely helps the split repos work better, but I don't think it is needed just yet.
As for encouraging PRs, make sure contribution guidelines are written down somewhere and at least referenced in the main readme. It might be possible for GitHub to require code changes come in through PRs (I've done this in other Git servers but haven't needed to in GitHub yet). Even if it is one of those simple changes that shouldn't affect anyone, having that easily navigable history showing which commits were part of a change might be nice to have.

👍 I am very much a fan of the organization move, I think it makes a lot of sense as the number of contributors grows.
Also agree re: monorepo. The BSP crates are suvh thin facades at this point that I really dont think they deserve their own repos, and having the ability to do a full refactor across them is well worth it.

Sounds good to me

OK, I've moved the repo and sent invites.  I'll come back and look at the permissions/access stuff a bit later.

I see you kept the project named atsamd21-rs. Are you planning to separate out the 51 now or just haven't renamed yet? I have a Metro M4 coming and I'd like to know the appropriate place to add support.
Also, do you want me to bring over uf2conv-rs? It's more of an Adafruit/Microsoft-specific thing than an atsamd thing.

@wez I see you kept the project named atsamd21-rs. Are you planning to separate out the 51 now or just haven't renamed yet? I have a Metro M4 coming and I'd like to know the appropriate place to add support.

Thanks for noticing; yeah, I hadn't gotten around to it.  I just renamed it.   We can figure out the specifics for the 51 in a separate thread/issue.

Also, do you want me to bring over uf2conv-rs? It's more of an Adafruit/Microsoft-specific thing than an atsamd thing.

In the long run it's probably better off elsewhere, but I'm not opposed to it living in the same GH org for the time being, especially if we end up having something nicely integrated for flashing the code from cargo.
I know that @tannewt is interested in seeing M4, UF2 and Rust all come together.

We did this a while back so I'mma close this issue.


Custom delay command

This solved a specific problem I was having, and since there was discussion in #9 about delays, I figured this might be generally useful.
Specifically, this adds $delay as a command (taking one argument, the delay length in milliseconds), e.g.
"macros": {
  "addSemicolon": [
    "cursorEnd",
    {"command": "$delay", "args": {"milliseconds": 1000}},
    {"command": "type", "args": {"text": ";"}}
  ]
}

I also fixed #5, incidentally solved the same problem as in PR #11, and removed the dependency on promise-series (I was having a harder time following the code with it in there and it didn't seem necessary).

Looks pretty good! Have you tested to be sure it runs them in the right order then?

It worked in practice in my specific circumstance and the reduce operation should chain them correctly in general, but I didn't specifically validate the ordering. I could potentially write some unit tests for it, but I'd have to familiarize myself with the VSCode tooling first (I've not written code for an extension before).
To be clear, I didn't try to figure out why the vscode.commands.executeCommand function seemed to resolve its promise before the underlying action was fully complete (in my instance, a Setting Cycler action followed by a save action) so this might be an underlying problem better solved with something other than a delay.

is this going in? can't wait to have it! i have a few issues with commands running to fast, and i think a delay option will sort it out.

@geddski Was there anything more you needed from me or other concerns before merging? I've been using my own custom build, but it might help some other people (and be more convenient for me) if it were published.

@geddski Bump.
I'd love to see this merged in. I've been using a custom build as well, but others have been asking for this

https://marketplace.visualstudio.com/items?itemName=l7ssha.macrosRe

https://marketplace.visualstudio.com/items?itemName=l7ssha.macrosRe

Installed this and it fixed my issues without even needing to insert a delay, so it seems to be fixing some other issues as well - the macro below did not work with the main macros extension but did with the fork.
		"selectAndCopyCursorToNextMatch": [ 			"editor.action.smartSelect.grow", 			"editor.action.addSelectionToNextFindMatch" 		]

bump,
still not merged?

bump

bump
this is awesome, it solved my problem


Mouse over packet layer name

It's not immediately obvious from the shape of the mouse cursor that you can click on the name of a packet layer to expand it. It should switch to a hand or whatever the usual shape for buttons is.
Said otherwise, there needs to be a visual clue that leads a user to click on that name.

This is an artifact of the bootstrap.ui angularjs library. We'll need to investigate how to actually turn this on, or change the underlying behavior. My guess is that its probably some default styling that the component is overriding.

Initial behavior: expand ethernet field editor view
Mouse icon should change when hovering entire header

Accordians changing open state when fields in packet editors were updated.


Add repository map link to README.md

Adding a link to the high-level diagrams including module, library dependency and others (https://sourcespy.com/github/awsneptuneexport/). Built directly from source and updated on schedule. Intended to simplify developer's introduction to the project.
In the spirit of transparency - I am the author of the diagrams. Hope contributors find it useful.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks for sharing these diagrams with us. It looks like a pretty cool tool, I especially like how it is able to map out the various CLI commands and arguments (although there are many missing arguments from our repo. Many of our CLI commands have additional arguments which are in separate modules and injected in).
I think you have a really cool tool there and I wish you the best with it but unfortunately at this time I'm not able to link to an external site outside of our control.

@Cole-Greer  Thank you Cole, your feedback is greatly appreciated!!


Translate concepts/overview/working-with-objects/annotations/ in Japanese

This is a...*

[x]  Feature Request
[ ]  Bug Report

Problem:
No /docs/concepts/overview/working-with-objects/annotations/ in Japanese.
Proposed Solution:
Translate /docs/concepts/overview/working-with-objects/annotations/ in Japanese.
Copy from en content and Update /contents/en/docs/concepts/overview/working-with-objects/annotations.md.
Page to Update:
https://kubernetes.io/ja/docs/concepts/overview/working-with-objects/annotations/

/language ja

/close


Probably not correctly analyzing hCaptcha's accessibility cookie

Describe the bug

The log showed a strange response when requesting the hCaptcha accessibility cookie. If the response doesn't actually contain the cookie and I'm making some false interpretations of the response, please close the issue.
Screenshots or Logs

[2022-06-24 21:16:34.701 +0800] DEBUG: Error from hCaptcha get_cookie request, continuing without hCaptcha accessibility cookies
status: 401
errorBody: {
"csrf_token": "REDACTED**"
}
Additional context

I don't actually know whether the csrf_token field contains the cookie. If it doesn't and I'm just overthinking, please inform me of the problem, and I'll close the issue.

This is a known issue. See the comment about this on the main page and the bug report for this issue.

This is a known issue. See the acknowledgement from the dev about this on the main page and the bug report for this issue.

Thanks for responding, but the response is different from what is normally seen when hCaptcha rejects the request.
For further investigation, I'd paste the original log down below:

[2022-06-24 21:16:34.701 +0800] DEBUG: Error from hCaptcha get_cookie request, continuing without hCaptcha accessibility cookies
    status: 401
    errorBody: {
      "csrf_token": "IjljOTZlNTNkODA5MDg2NGIwOTlkN2JjODcxYmQ1NGI0MGY3NjFjYmYi.YrW5Mg.yFNZigrgNyMLS2YCC_K1EresJtA"
    }

There is a 401 code over here, but I can't tell what the csrf_token is.

I see what you mean. I was only focused on the error 401 part. I wonder the difference stems from you having a different log level than the other poster. Not sure what that token is.


chore: minor cleanup for "get best icon variant" code

Depends on #548. Not ready for review.

Abandoning this because I don't think it's relevant.


preprocessing time

The preprocessing time is like:
Feed dict time:
Min:  0.12029
Max:  0.24133
Mean:  0.14371
Median:  0.14227
much larger than 0.02s reported ?

Preprocessing time includes the data preprocessing steps on the CPU, such as BEV and anchor generation, and will depend on your particular CPU. Data (images and velodyne points) loading time from the disk drive is not included and will also vary based on computer setup (CPU, with HDD or SSD). Normally, this data is provided directly from a ROS node when deployed. The feed_dict time that you are seeing includes both the data loading and preprocessing time.


koka: 2.4.2 -> 3.0.1

Description of changes

Updated koka version
Changelog: https://github.com/koka-lang/koka/blob/dev/whatsnew.md
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I've successfully built and run this on NixOS x86_64-linux :+1:

Works for me, but I just run into an annoying stuck issue https://github.com/koka-lang/koka/issues/437. I guess there might be a new release soon.

Heads up, there will be a new Koka release in the next couple of hours to fix a bug that was causing infinite loops in typechecking.


Use array_has() instead of hack.

If we already have a method, why not use that?

This is not correct. It doesn't actually do the same thing.

Please explain.

The current way we're still checking it's not the same as microtime(true) even if it is set.

Yeah, but that's just a hack, abusing the fact that it's highly unlikely a config value will return that value.

@GrahamCampbell Can you reopen this? I don't understand your argument. =)

This is as correct as it gets.


[Cloud] Added cloud init command for open in vscode

Summary
Added a devbox cloud init command similar to devbox cloud shell but it can be called in to create a cloud vm (if it's not created already) and sets up ssh configs without dropping user in an interactive cloud shell.
This will be used in the extension so that the extension can ensure:

the remote vm exists
get its ssh address (vm ID)
the client (vscode) can connect to it via ssh

Also, added devbox generate ssh-config command that only sets ssh-config without creating cloud VMs.

For open-in-vscode, the Gateway.VMInfo() will ensure a VM that is in "Started" state, and return back the VM's address and public-private keys to access that VM. We then need the Extension to generate the ssh config via the devbox CLI binary.
I'd suggest a hidden command like devbox generate ssh-config which calls openssh.SetupDevbox.
Since the Gateway.VMInfo() API isn't yet ready, if you would like a hidden command that starts a cloud VM for testing purposes, then how about devbox cloud init that has a similar implementation as this PR, and prints the VM's address out?

that makes sense. I'll change the name for this command and make it hidden. And add a hidden devbox generate ssh-config as well and update this PR.

Since the Gateway.VMInfo() API isn't yet ready, if you would like a hidden command that starts a cloud VM for testing purposes, then how about devbox cloud init that has a similar implementation as this PR, and prints the VM's address out?

I'm not sure why we need devbox cloud init? We can just manually start a VM on fly.io to test right?


Rethink "Recieve Amount" Modal on Receive Screen

In Receive Screen, when we request for sats - The modal seems confusing to the user, making one think that are we sending sats or Bitcoin as in whole? one gets clarified that its sats once he sees the amount on address.

Here are two possible suggestions for the receive amount modal/flow @ben-kaufman
https://www.figma.com/design/m5eMFTKD391AiJAXaEzgxB/Bitcoin-Keeper?node-id=3599-4932&t=wir1oEooAhOJMQK7-1

#5339

Have designed the UI for the new Receive Amount Modal, adding  some additional functionalities. User now will be able to select the type of currency he wants to receive payment in whether its fiat, sats or btc. He can set the currency with ease now
Figma section link:
https://www.figma.com/design/m5eMFTKD391AiJAXaEzgxB/Bitcoin-Keeper?node-id=3599-4932&t=8GxaT1R7pl9O2xoa-1
S.S

Verified this in keeper app v 1.2.19(417)


java file won't open

everytime i try to open the java file, it pops up with that

you're not supposed to run the JS file, follow the video


JPEGs can’t be in RGBA mode

Pillow fails at saving thumbnails; maybe this worked earlier because RGBA was ignored for JPEGs, don’t know.

Thanks! This probably worked by chance / luck only.


Proposal: Executor - Scheduler interop

Right now RxJava has support for creating a Scheduler from an Executor, but not the other way around. This could be useful for allowing shared use of a scheduler's thread pool for APIs that don't necessarily speak RxJava.

Executor is a SAM so you can set it to Scheduler::scheduleDirect

Good point. What do you think about the more expanded ones like ExecutorService or ScheduledExecutorService? I noticed the internal ExecutorScheduler has some understanding of these

Do you have something specific you need an ExecutorService for?

Most of the use case unfortunately is just to share threadpools when bridging to non-rx code. We have a few SDKs embedded in our apps that speak Executor (+ friends), and since we're a mobile environment we're trying to keep threadcount down rather than provide each with their own unique thread pool

we're a mobile environment

You'd probably want a separate standalone library for this then as you may not need all the extensions of this library just to get the interop.

that's fair, though we're already including this library and fairly happy to rely on proguard for unused APIs. I wasn't actually sure where to ask, and also maybe looking for a bit of guidance on implementing such a thing if you have any :)

You have to implement interfaces and delegate to the relevant schedule calls. You will likely need some CountDownLatches for the invokeAll/invokeAny.


Bump slack conversation find limit

First: Thank you for sharing this code, it's a great time saver!
We've got a lot of Slack channels, so SlackBot isn't finding our configured channel name in the first page.
This is a quick fix to bump the size of page that conversations.list() will return, there doesn't appear to be an endpoint to return just a single channel by name.
Would you consider removing the name mapping, and require the slack ID directly in the config to save the API lookup altogether?

 We should solve this through the channel id. This is much more robust than the search by name.
slackChannelId -> new Parameter
slackChannel(name) -> deprecated
Do you want to try?

Closing this in favour of #17


lurk: add aarch64-linux support

From a previous release https://github.com/JakWai01/lurk/releases/tag/v0.3.7:

Lurk now has Aarch64 support 🚀

I have not added darwin as most likely it still doesn't work and I can't test it.
Things done

Built on platform(s)

[ ] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg build lurk


Improving ApplicationInsights section.

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

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

#sign-off
@brettsam it would be great in the future to have this in the private repo.

#reassign:kraigb

@ggailey777, since you signed off, we'd normally merge this. But I see you reassigned it. Do you want @kraigb to approve it also? Thanks.


Azure Activity- Analytic Rule changes

Required items, please complete
Change(s):

Summary of changes:

description changes

Parse_Json issues

Filter changes

Added AssignmentCount logic

Updated Entity Mapping

Use of old function- makelist
Reason for Change(s):

rule enhancements

Version Updated:

Various version

Testing Completed:

Syntactical validation done. Output testing done where data was available.

Hi @devikamehra, are we good to merge above? Also checks not passing since your approval its keep running.

Hi @vakohl, can you please look into these checks. Thanks


RNG Seeding

We need to clarify the documentation and remove any deprecated code (global variable g_tw_rng_seed and the 3rd argument it tw_define_lps).
@JohnPJenkins remembered this quote from @carothersc while discussing 45665b48a649b136f173a47916ab231c6cd92a07:

I think we stopped using that parameter since we did not want users picking
their own seeds as some seeds are better than others and some are just bad.
So, a little primer here on RNGs. RNGs in fact have only one (hopefully) very, very
long stream of random numbers. CLCG4 uses 4, 32bit values or 128 bits.
This generator has a period of 2^121 implying that ~2^7 values are missing
from the generator.This is fine.
So, you can image a circle with 2^121 tiny point going around the circumference
where each point would represent a random value. Eventually, if you called
the generator 2^121 times, you would have made it around the circle.
A very nice property of CLCG4 is that you can jump (or virtually teleport) ahead
in that single stream of random numbers. We call it "seed jumping". ROSS
starts from the default seed and jumps 2^70 calls ahead in the stream for each
LP. That is, each LP's starting point in the random stream circle is 2^72 calls
apart.  So, in theory, we could support simulation with unto 2^49 LPs and each
LP have it's on part of the random stream, uncorrelated from other parts.
Now, to change seed sets, what you really want to do is change where each LP
starts on the random stream circle.
You can do this by increasing g_tw_nRNGs_per_lp. So, suppose you use 4.
That will give each LP 4 distinct RNG seed sets that start again 2^72 calls
apart.
In your model code, you just change which seed set you wish to us -- 0, 1, 2, 3
e.g., lp->rng[0] or lp->rng[1], lp->rng[2] or lp->rng[3].
By default in ROSS, when you use lp->rng your really saying &(lp->rng[0]).
The downside of this approach is you're potentially wasting some memory by
have these 4 seed sets around and the cost to compute them but it's a very
low cost all around unless you have a model with billions of LPs.
If that is the case, you would have to directly jump or shift seeds an LP uses
by directly invoking the seed jumping routine w/i the RNG with the LPs
init event.
e.g., call, tw_rand_initial_seed(&lp->rng[i], lp->gid + offset);
where offset would be the number of 2^70 jumps you want to make beyond the
LP's global id.

OK, so I think ad0118e0b638d6bfa9cb5827c1b41e5d628d85f3 closes this issue...  Also see 8b7b3951a7a831e4781a5468ee62af5d9eb5ce7e for more details on re-seeding RNGs.


elisa example

I have tried to complete the exercises for class 3 (I still have some doubts on the last question)

Great job! Closing.


[rfc] gb build/test automatically download missing dependencies

This rather blandly titled issue is a placeholder to discuss the changes to gb for the 0.4 series, which the roadmap hints "improve gb vendor".
Backstory
gb cares about reliable builds, a lot. Giving Go developers the tools they need to achieve repeatable builds was the motivation for developing gb, and the main way gb does this is via the $PROJECT/vendor/src directory. A bit later gb-vendor came along when it was clear that users wanted tooling to help them manage their vendor'd code.
But it also clear that not everyone is comfortable with actually having copies of the source in their tree; they would rather have a manifest file that explains where to get those dependencies on request. This catalyzed around the gb vendor restore command which I now regret accepting as it confused the message that gb's reliable build story is based on vendoring. See #498.
To be very clear, the answer for how to get the most reliable builds with gb is always to copy your dependencies into $PROJECT/vendor/src. But sometimes there is an argument for trading reliability for convenience, this is the motivation for this proposal.
Proposal
I propose that during package resolution (which happens for build and test, but may happen at other stages in the future) once the standard search locations have been exhausted (see below), a per user cache of source code is consulted, and if the package is not found in the cache, we attempt to fetch it using the standard gb vendor fetch lookup rules.
Importantly, this is not a proposal to automatically invoke gb vendor fetch, but a separate mechanism that is invoked once all the per project source locations have been exhausted.
TODO:

[ ] decide if this is opt in or opt out; should there be a flag to disable / enable this behaviour, and if so, what its default state will be?

Updating
Maintaining a cache means establishing rules for when the cache is updated. My proposal for this is updating the cache, ie fetching from upstream if the entry is present in the cache, should be off by default.
This means adding a new flag, probably -u which effectively marks anything in the cache as stale and forces the upstream to be consulted. This could be a potentially very time consuming operation.
TODO:

[ ] decide if a partial update is something that should be supported. The UI for this sounds complicated, so it might be simpler to give the user a command to clear a particular cached entry, which accomplishes the same thing.

Package cache
The package cache, or more correctly a cache of source code, is a location where dependencies can be stored and referenced for gb projects. This cache is per user not per project.
TODO:

[ ] figure out the appropriate location for the package cache, some operating systems have a notion of a per user cache, others don't.

Search order
The search order for packages is currently:

$GOROOT/src
$PROJECT/src
$PROJECT/vendor/src

With this change, rather than terminating if a package could not be found, the cache will be searched, and if the package is not found, an attempt to fetch it from it's upstream (as defined by gb vendor fetch, which itself is defined by go get's rules) is made, and the cache searched again.
The proposed search order could be considered to be roughly:

$GOROOT/src
$PROJECT/src
$PROJECT/vendor/src
$HOME/$CACHE/src
$REMOTE_URL

The key take away is that source code higher up the search order takes precedent. If you need a specific revision of a dependency, you should vendor it to $PROJECT/vendor/src.
One more thing
With this change, I've just reinvented go get, golf clap.
Well, yes, and no. It is correct to say that in the first implementations of this design fetching from upstream would have the same problems as go get has currently. But I believe that gb has all the pieces to improve on this.
In golang/go#12302 I made a proposal for a simple release mechanism for Go packages; use semver tags for package releases.
I propose that gb can use this information to let project owners specify the version (as defined in proposal/design/12302-release-proposal.md) or a version range for a dependent package.
Arrgh, Dave, you've introduced a manifest file; twice!
True, to avoid pulling from head, you'd need to use a manifest file, but just like gb vendor, it's totally optional, if you don't want gb to fetch upstream, make sure the source you need is in $PROJECT/vendor/src.
TODO:

[ ] decide on where and how to store version information in the gb project; I propose a file in the root of the project that lists the import path prefixes and a semver like range expression.

I like the convince of downloading missing packages but bit confused about repeatability for the team.
Explicitly downloading dependency to vendor/src, in my mind, is the single most valuable feature that helped us to share dependencies reliably with the team for a large project. The thing i'm concerned about is how do you communicate when a dependency is in cached locally and not vendored.

@gosuri yup, that's a good point. It sounds like as a prerequisite to this work I need to add a command to gb that print out detailed information of where each package in a project is resolved from.
Additionally this sounds like, as an existing user, you would prefer this feature to default to off.

@gosuri but don't think of this as "a missing depednency is going to fall back to an unknown pull from upstream's head", the goal is to drive people towards the design in golang/go#12302. If you could specify in some kind of manifest file the version (see 12302) of a dependency, rather than vendor a specific hash, would that be good enoughtm ?

Since you asked for comments explicitly, I'll add my vote for this fetch/cache to be explicitly opt-in if it's added; I'd be very surprised if I did a "gb build" and it started downloading instead of throwing an error (maybe with suggestions about how to get the dep I'm after).
I can't see myself using the feature described here, and honestly see it as contrary to gb's main value proposition. :innocent:

@tianon yup, i get that. IMO I think everyone, myself included, is shell shocked by the belief that pulling from upstream would bring us right back to square one with go get.
But imagine if there was a way to pull a specific release version of a dependency from upstream if it was not already present in the project.
How about this middle ground. For the initial iterations, while there is no manifest file, and no real support for fetching a version of a dependency, this feature defaults to off. When support for fetching a missing dependency version is implemented, then the default could be changed.

@tianon

I can't see myself using the feature described here, and honestly see it as contrary to gb's main value proposition. :innocent:

That's a fair comment, and this is on me for not being clear enough with the message. gb cares about reliable builds, and that's by vendoring into $PROJECT/vendor/src, but I recognise that there is a set of users who object to vendoring for various reasons - and to be honest, after working with gb for six months I count myself among them.
Vendoring is a effective, but crude hammer. You get repeatable builds, you get independence from upstream foibles, but, well, hammer.
This proposal doesn't take away that method of working, $PROJECT/vendor/src will always be supported in gb. This proposal is an attempt to ease people into the gb project model, without the biggest hurdle, which is setting up their vendor/src directory.

@davecheney We prefer reliability over convenience. Although use semver very religiously for public projects, there are countless instances where version numbers would be stale internal projects. We resorted to injecting commit hashes in version commands to be explicit. Example:
$ walker version
walker 0.0.3 (8d5f2f4a65e871e8156fb7617f7c8c282f32f544+CHANGES)

@gosuri i understand that completely. The gb party line is, if you don't trust the upstream, then you should vendor the dependency.

@davecheney yeah.. you'd be surprised how many very "prominent" projects don't really understand the <breaking>.<feature>.<fix> model.

@gosuri I understand the reservation about semver, however this really isn't about semver, this is about trusting your upstream to do a good job. If you don't trust them -- vendor; but really you're forking them because, well, you don't trust them.

@davecheney Exactly my point. We use semver religious once the project reaches publishable state, working towards getting better at early stages as well.
Very unfortunate to see several prominent (don't want to single out) projects ship breaking APIs as "feature" releases. I learned not to  trust upstreams by default. My current upgrade flow right now is something like:
$ git checkout -b upgrade-foo
$ gb vendor delete foo
$ gb vendor fetch foo -tag ...
$ ... # test
$ git checkout master
$ git merge upgrade-foo # if checks out
$ git branch -D update-foo

@davecheney

but I recognise that there is a set of users who object to vendoring for various reasons - and to be honest, after working with gb for six months I count myself among them.

I am interested to hear about this evolution in your thinking.

I am also interested in hearing how vendoring came to feel as a hammer for you.
I echo most of the objections but with off by default it might work.
Maybe have it as an "experimental" feature?
Is most of the motivation coming from wanting to promote a standard versioning scheme?
I have previously been very much in favor of it before but have warmed to vendoring. I get nostalgic. It reminds me of sending code as patches and tar balls over email.
Can this help with #49? It relates to versions of dependencies at least in part right? Then why not try it? Or make it more focused and make a special manifest file that specifies this.
Please by all that is holy make it simpler than poms...

I mean there is no need for auto download as a selling point if what is really tested is versioning.

@ChrisHines

I am interested to hear about this evolution in your thinking.

I've always believed that vendoring code is the least worst option. I think I used those words in April last year when I introduced gb. Vendoring does have some nice properties, which can be divided into two categories
Upstream issues; github going bust, upstream closing the source of their code, internet breaks when you're trying to build the release.
Go get issues: no way to fetch a specific release version, no way to fetch a specific vcs revision, no way to release a specific revision, no way to say one package depends on a version/revision of another. No way to make sure your coworkers update their local copy when you push a bug fix, ...
gb is a reaction to both of these sets of issues, but focuses on the second set, because we've had all those and more working on Juju at Canonical. It's nice that vendoring also solves the first set of issues, and I want to recognise that the core group of users who were attracted to gb because it gave them a workable methods to vendor dependencies a year ago. I want to make it clear that $PROJECT/vendor/src/ is not going away.
With that as a background, and with a window seat on the GOVENDOREXPIERMENT debate, and the various debates around vendor-specs, I'm concerned that vendoring is being used as excuse to not address dependency management problems in the Go package ecosystem.
Without rehashing the extremely long debate on proposal 12302, Go packages have no notion of version, only vcs revision, and whether you download your dependency from the origin, from a central repo, or vendor them into your source tree, I believe that the properties that a release process give to Go packages are valuable.
Lastly, I've also been told by people who work in more regulated environments that vendoring code constitutes forking and raises the spectre of open source licence fights. I am not a lawyer so I cannot comment on these details, but suffice to say if they say they cannot vendor code because $LAYWERS, I believe them.

@dahankzter thanks for taking this discussion off twitter. I'll try to respond to each of your points in order.

I am also interested in hearing how vendoring came to feel as a hammer for you.

Please see my response to @ChrisHines

I echo most of the objections but with off by default it might work.

Thank you. This is a just a proposal at this point, and I value your feedback and will integrate it into this proposal.

Maybe have it as an "experimental" feature?

Nope, sorry. I'm even more militant than the Go team on options, we either do it or not. In the context of your previous point, this is really a debate about if the package is missing from the project, we fall back to downloading or not.

Is most of the motivation coming from wanting to promote a standard versioning scheme?

Please see my response to @ChrisHines

I have previously been very much in favor of it before but have warmed to vendoring. I get nostalgic. It reminds me of sending code as patches and tar balls over email.

I'm not really sure how to respond to this, could you please clarify for me.

Can this help with #49? It relates to versions of dependencies at least in part right? Then why not try it?

Not directly. I know that there are people who want to use gb to write libraries, not projects, but this proposal is not aimed at addressing that. Maybe it'll help, but that would only be a side effect.

Or make it more focused and make a special manifest file that specifies this.

Could you please clarify what you mean.

Please by all that is holy make it simpler than poms...

I've used maven in the past, and have some experience with poms, but I would really appreciate it if you could be very clear about what you do not want to see; ie the bad things about poms, as I'm sure you will not be the only person to mention maven.
Thanks
Dave

I mean there is no need for auto download as a selling point if what is really tested is versioning.

Could you please expand on this, it sounds like a very important point and I would like to respond to you properly.

@davecheney Thanks for the detailed explanation. Like you, I believe in the value of a release process for Go packages. I also believe that different projects legitimately have different requirements for managing dependencies.
My feedback:

Definitely opt-in to start, and keep it that way until it feels like most people would want it on nearly all the time.
To prevent the package cache from feeling too magical I would want tools to list what's in the cache and gb build should be able to report the location and version of each package included in the build.
I can see myself using this so that I don't have to vendor my own internal libraries into each of my internal projects. The churn when a library is co-evolving with the project is the one aspect of vendoring that I find most annoying.
How do we make builds 100% repeatable when not vendoring all dependencies?

@davecheney yeah, I suppose that makes sense -- looking at it from the perspective of something akin to requirements.txt or Gemfile seems totally logical (and helps me swallow a bit and realize this really does make a lot of sense), and I suppose if we had a reasonable way to fetch specific versions from upstream on the fly, I'd be fine (especially if the solution became popular enough that upstreams didn't play games like renaming/removing tags, changing tags, or swapping repos around willy-nilly because it'd break the usage); you're definitely dead-on that the reason I like the crude hammer that is vendoring is because upstreams are typically unreliable and fetching methods are crude :smile:

Sounds good to me. I'm not personally that interested in the package cache as it pertains to unversioned dependencies (current go get style), but like it as a way to implement 12302/semver "on the side" with the hope of it becoming the defacto standard in the community.
I'm tagging my Go packages in anticipation. :)

We need gb to be able to fetch a specific revision from a VCS. Today gb assumes that the desired revision is the tip or head revision, so we have in implicit label for it, but suppose that we could specify the desired revision instead.
Even without semvers available for most projects, I expect that such semvers will be non-surjective (and possibly non-injective) mappings to VCS revision IDs (in Git, commit hashes). If we have a dependency pinned by semver, we need a mapping from semver to VCS revision. Treatment of semvers is a layer on top of treatment of VCS revision IDs—a layer of indirection—just as Git treats tags as an alias layer on top of commit hashes.
I'd like to see gb record a manifest of vendored dependencies, in increasing order of specificity:

With no version (implicitly requesting the tip revision)
With a VCS revision alias (in Git, a tag)
With a semver
With a specific VCS revision (in Git, a commit hash)

Whether the semver or the alias is more specific is hard to say; some VCS aliases float over time, whereas I expect that a semver will not. But it's possible that a semver could point at an indelible VCS alias (a "release tag").
With that in place, running gb vendor fetch  would fetch the code available for the tip VCS revision and record that fetched revision in a manifest. At that point, deleting the fetched (cached) code but retaining the manifest would allow one to later fetch that same code again on demand—assuming that the server and resources remain available. We wouldn't need to check the fetched code into our own source code repository unless we didn't trust the upstream server. We'd only be checking in the most precise specification possible (apart from the code itself) of what code to use when needed.
I would also then expect an interface to be able to widen or narrow the desired version of such a vendored dependency:

Perhaps I unpin the version entirely (or specify "HEAD") to follow an evolving project closely.
Perhaps I pin it instead to a VCS alias (the tag "1.0-rc").
Perhaps I pin it to a semver.

How gb would map from semver to a VCS revision remains unspecified. However, I think that's fine, because you'd need to build the stuff underneath first before you could even use such a semver mapping.

So, I've been thinking for a long time now, one of the biggest issues I have with the way go handles dependenices is the lack of a mechanism to define and "pin" a library to a version of a dependent library.
I do not believe vendoring solves for this adequately, although it is a start. What if your service X depends on Library Y and Library Z. Library Y also depends on Z, but has a stricter requirement around what version of Y it uses - but, and this is important, not an incompatible restriction ("Diamond" dependency management is still a problem, but one that can be solved by individuals, and not one holistic tool that makes magic happen - imo).
You'd need something to reason about: "Ok, I need ~> 1.5 of Library Z, but the sum of my dependencies need ~> 1.5.6. Therefore, I ultimately depend on ~> 1.5.6"
As I was unfortunately unable to make it to the consulate in brussels to have a conversation, per our accord on Twitter, I instead spent a few hours mocking up this approach:
https://github.com/StabbyCutyou/a_conversation_with_dave/pull/1
I'll note the above is A: not complete and B: not fully thought through, but as I've been thinking about this for a while now, I wanted to at-least spend some time trying to implement a partial solution, to try and better understand the intricacies of a full solution. As I noted in the Readme, my opinion on how to handle version management would be as follows:
Each library or service would define a "pin" package in it's own executable that would interact with something like pinner (the package from my PR link). You would register the dependencies by their regular value (so, the github urls for example), and the version + constraint (~>1.0, <3.0, etc).
The current implementation simply goes and fetches them, trying to find the right version that meets the constraint, but a proper implementation would need to do the following:

Resolve all dependencies, break on any errors
For each of those dependencies, check for a "pin" package, resolve those
2a. Continue doing this until you run out of "pin" packages, or until you hit a breaking issue
Build a tree of dependencies, such that you know both what each library depends on all the way down
From this tree, coalesce a list of unique dependencies with their version constraints
4a. If an incompatibility is found, break and report the error
Now, feed this list to the current process, where it will actually retrieve all dependencies, and resolve to find the version-tag that best fulfils that constraint.

The files would initially be checked out to a "staging" area, before being actually checked out in the projects go-path.
I believe this approach would work well with the gb approach of "Each project has it's own private GOPATH", but not as well with the vanilla way GOPATH works. I have some notes in the code itself around some ideas to fix that, but they're wholly out of scope for this discussion.

@ChrisHines

My feedback:
Definitely opt-in to start, and keep it that way until it feels like most people would want it on nearly all the time.

Yup, that is crystal clear from the feedback.

To prevent the package cache from feeling too magical I would want tools to list what's in the cache and gb build should be able to report the location and version of each package included in the build.
I can see myself using this so that I don't have to vendor my own internal libraries into each of my internal projects. The churn when a library is co-evolving with the project is the one aspect of vendoring that I find most annoying.

Noted. This feels like another facet of #493, which I do want to tackle sooner rather than later, but as my preference is to make this additional information output all the time, finding the right output format will be a complex business. Failing that a replacement of the undocumented gb depset command will be in order.

How do we make builds 100% repeatable when not vendoring all dependencies?

I don't think this is possible. This proposal trades reproducibility for convenience. I don't have enough experience to judge how much of the former would be given up, and what would be the implications of this.
I think this is somewhat mitigated by the general feeling that this should only be opt in, and so project owners can choose to make that tradeoff themselves, it will not be forced on them by gb.

@seh thanks for your comments

We need gb to be able to fetch a specific revision from a VCS. Today gb assumes that the desired revision is the tip or head revision, so we have in implicit label for it, but suppose that we could specify the desired revision instead.

gb vendor fetch provides most of this today. Can you explain a bit more about what is missing from your point of view.

Even without semvers available for most projects, I expect that such semvers will be non-surjective (and possibly non-injective) mappings to VCS revision IDs (in Git, commit hashes). If we have a dependency pinned by semver, we need a mapping from semver to VCS revision. Treatment of semvers is a layer on top of treatment of VCS revision IDs—a layer of indirection—just as Git treats tags as an alias layer on top of commit hashes.

I'm assuming you meant with semvers available. If so, this sounds like the argument for a lockfile in addition to a file specifying the version or range accepted.
I have two comments in response to that:

If you need a specific revision, you should vendor it and be done.
It's clear that I made a mistake in suggesting that a version number or a range would be acceptable for dependency resolution. I'm going to drop the idea of a range.

I'd like to see gb record a manifest of vendored dependencies, in increasing order of specificity:

Isn't this what gb-vendor does ?

With no version (implicitly requesting the tip revision)
With a VCS revision alias (in Git, a tag)
With a semver
With a specific VCS revision (in Git, a commit hash)
Whether the semver or the alias is more specific is hard to say; some VCS aliases float over time, whereas I expect that a semver will not. But it's possible that a semver could point at an indelible VCS alias (a "release tag").

gb-vendor does this with the exception of recording the tag. This is an oversight from the version 0 manifest and will be corrected at some point in the future.

With that in place, running gb vendor fetch would fetch the code available for the tip VCS revision and record that fetched revision in a manifest. At that point, deleting the fetched (cached) code but retaining the manifest would allow one to later fetch that same code again on demand—assuming that the server and resources remain available. We wouldn't need to check the fetched code into our own source code repository unless we didn't trust the upstream server. We'd only be checking in the most precise specification possible (apart from the code itself) of what code to use when needed.

You've raised a really important point about the interaction between gb-vendor and this new proposal. I had envisaged that the flow of dependencies would work something like this
a. gb build fetches dep from it's tip not going to do this
b. user chooses to pin dep to a release version
c. user chooses to vendor dep at a revision
You're suggestion that the flow of control works the other way around, you'd start with using gb vendor to fetch something, then once you're satisfied with it's stability, move to pinning that release version the depfile and removing it from $PROJECT/vendor/src.
I agree that this is a valid way of working, but I worry that is suffers from a chicken and egg problem -- if everone vendors random revisions of code, there is no pressure on upstreams to do proper releases, so you can never move to a pinning to a specific release.

How gb would map from semver to a VCS revision remains unspecified. However, I think that's fine, because you'd need to build the stuff underneath first before you could even use such a semver mapping.

I'm proposing the mapping would be what I proposed in 12302, tag repositories with a release number.
Thank you for your comments, I'm sorry if I have not answered all of them in detail.

@StabbyCutyou thanks for your comments. In responding to them a lot of them do not appear to be directly related to this proposal so I'm going to skip over them -- sorry for moving the goal posts. I do want to hear you ideas on dependency management for Go projects, but I want this thread to stay on topic.
You mentioned in your comment about libraries -- gb projects are not libraries. I know people want to use gb for writing packagers (libraries), but to make the problem space tractable gb is only targeting projects -- code that is not imported by other code.
With that said, while libraries might have a requirement to say "I can work with version 1.x of log15", projects will want to pin their dependency down to at least a specific version, "I want to use 1.9.2 of log15 for this project", and possibly to pin to a specific revision, which is addressed by gb's vendoring support.
The intention is to record in the project the version (as defined in proposal 12302) of a dependency and that is used to fetch the package when it is missing. I hinted above that there might be range support, I'm walking that back right now, it was a mistake. Versions must be absolute.
So, sorry, I'm not looking to solve the wider problem of dependency management between go libraries today, it's just too large of an elephant to eat in one sitting. The goal here is provide gb project owners with more tools to build Go applications reliably if they cannot or choose not to vendor.

I believe this approach would work well with the gb approach of "Each project has it's own private GOPATH", but not as well with the vanilla way GOPATH works. I have some notes in the code itself around some ideas to fix that, but they're wholly out of scope for this discussion.

The fact that GOPATH forces the user to only have one copy of a dependency in scope at once makes it pretty unworkable to have two projects in a single GOPATH with divergent dependencies. Canonical wrote godep (singular) to add some automation to handle this. I wrote gb to try to do better.

Thanks to everyone who contributed to the discussion so far. Based on your feedback I'd like to propose the following changes to the proposal:

This feature will default to off. This is pretty much a no brainer. You expect gb to be deterministic, that has to continue to be my primary concern. Message received loud and clear.
When enabled, this feature should not fall back to fetching an unspecified revision if none is specified, it should only fetch a specific release version.
The notion of the project owner being able to specify a version range, not just a version was a mistake as it introduces ambiguity into the dependency resolution. Message received loud and clear, there will be no support for version ranges.
As package resolution is becoming more complex, and there is an operational requirement for the project owner to actively know where a dependency is being satisfied from, several people asked for a tool -- probably a new subcommand -- that will list where each package is coming from. I'm going to take this as a separate issue.

Taking 4. as a separate TODO, I propose the following:
This feature is off by default, and is enabled by the presence of information that maps a dependency to a release version. Or to put that more concretely
a. dependency information is recorded in a file
b. the presence of that file activates this feature; no file, nothing will be fetched
c. dependencies are only fetched if they are present in the file, if they are not present, then nothing will be fetched, this is a partial application of the previous point.
d. dependencies are specified by a release version, version ranges are not supported. If you need more control, then you must vendor.
Comments ?
Thanks
Dave

Can you explain a bit more about what is missing from your point of view.

I confess that I don't know much about what gb vendor does today. I've used gb vendor fetch a few times and been satisfied with what it did the first time. I haven't had to revisit those dependencies to update them or reconcile them with some other edge in the dependency graph. (Detour: I still don't understand whether gb accommodates a dependency graph, as opposed to a tree, where the same package may be vendored as a dependency of several libraries, each with its own copy.)

I'm assuming you meant with semvers available.

No, I really did mean without. Restating, given the standstill with 12302, I'm assuming that we don't have semvers available today, but that shouldn't keep you (or us) from working on dependency version management. When semvers become available, they can sit on top of what you can build today.

Isn't this what gb-vendor does ?

Perhaps, but I don't know whether gb-vendor allows a user to express a requirement: I want package P at version V. I figured that one can ask gb-vendor to get the latest version of package P, and gb-vendor would remember which version it got so that in the future it could determine if a newer version is available. That's not the same as including such a package-to-version mapping in the user-visible data model.

if everone vendors random revisions of code, there is no pressure on upstreams to do proper releases, so you can never move to a pinning to a specific release.

True. It assumes that the upstream maintainer is not diligent enough to assign versions, but it does accommodate downstream experimentation as a form of QA. That is, if I consume package P, grab its latest version, and find it works acceptably, perhaps I'd pin the version I got. Then I find a bug in it, report it and maybe even contribute a fix that gets accepted, and so I'd figure out which newer upstream VCS revision contains my fix, and tell gb to start using that version instead. I'm not looking to track the incremental upstream progress. In lieu of deliberate semvers or even releases, though, I can still point at particular upstream VCS revisions as being significant points of reference for my project.

I’m really happy to see this idea of a package cache and I think it comes at the right time. I have run into several companies that because of compliance issues must manage their own repo of dependencies. They need to make sure that they are compliant with licensing. Developers must get approval to use a package. They also need to manage changes to the dependencies for the entire company. Understanding how widespread the usage of a dependency is also is important.
Because of this, vendoring is not an option and these dependencies can’t be saved with any project.
From a build perspective we only need to make sure a dependency is properly loaded on disk so the build can take place. I would like to state import path rewriting is never an option.
This is complicated because where are you going to load these dependencies on disk?
Dave is saying this cache will be a location for a user. I come from a perspective of working on different client projects. This will cause me problems because it will result in the cache folder being shared across clients. Maybe an environment variable can be used to help these types of situations. Maybe there is another convention based on how projects are named or a special folder inside the project that can be used as convention to find the cache folder? Something to think about.

In responding to them a lot of them do not appear to be directly related to this proposal so I'm going to skip over them -- sorry for moving the goal posts

On the contrary, it's me here who moved the goal posts a bit. My concept here is definitely out of scope. I could respond to some of your points and continue to explain the design a bit, and would gladly have the conversation, but I feel that it's likely a distraction from your actual RFC.

@ardan-bkennedy Why is a problem if a single cache is shared across clients?  If I understand correctly, the cache can contain multiple versions of the same package. If two clients share use the same version, then you save download time and disk space.  If two clients use different versions, then that's OK.  Or maybe I don't understand the requirements or proposal.

@seh

Can you explain a bit more about what is missing from your point of view.
I confess that I don't know much about what gb vendor does today. I've used gb vendor fetch a few times and been satisfied with what it did the first time. I haven't had to revisit those dependencies to update them or reconcile them with some other edge in the dependency graph.

That's ok, gb vendor fetch does pretty much what it says on the tin; it checks out some code, and copies it into your project.

(Detour: I still don't understand whether gb accommodates a dependency graph, as opposed to a tree, where the same package may be vendored as a dependency of several libraries, each with its own copy.)

Both, but that probably isn't helpful. Go dependencies are a graph, not a tree; it starts from your main package, branches out, then concentrates on the stdlib and ultimately the runtime package.
If your question is about the diamond dependency problem; gb solves that by the fact that there can only be one copy of pacakge's source code on disk in a project. There cannot be two different copies of a package's source on disk in the same place at once.

I'm assuming you meant with semvers available.
No, I really did mean without. Restating, given the standstill with 12302, I'm assuming that we don't have semvers available today, but that shouldn't keep you (or us) from working on dependency version management. When semvers become available, they can sit on top of what you can build today.

I don't understand what you mean by "semvers", it's just a convention, one that projects are actually doing anyway (check out core os, docker, etc). The release process I proposed in 12302 is really the simplest possible; git tag .... The Go team decided to punt on it, but that doesn't mean it cannot be a defacto standard -- and I think it should.

Isn't this what gb-vendor does ?
Perhaps, but I don't know whether gb-vendor allows a user to express a requirement: I want package P at version V. I figured that one can ask gb-vendor to get the latest version of package P, and gb-vendor would remember which version it got so that in the future it could determine if a newer version is available. That's not the same as including such a package-to-version mapping in the user-visible data model.

Sadly there is no way for a Go author to record that information. I mean, it's not physically impossible, but there is no convention, or standard do to it, so there is nothing gb vendor could do to recover that information, it simply does not exist.

if everone vendors random revisions of code, there is no pressure on upstreams to do proper releases, so you can never move to a pinning to a specific release.
True. It assumes that the upstream maintainer is not diligent enough to assign versions, but it does accommodate downstream experimentation as a form of QA. That is, if I consume package P, grab its latest version, and find it works acceptably, perhaps I'd pin the version I got. Then I find a bug in it, report it and maybe even contribute a fix that gets accepted, and so I'd figure out which newer upstream VCS revision contains my fix, and tell gb to start using that version instead. I'm not looking to track the incremental upstream progress. In lieu of deliberate semvers or even releases, though, I can still point at particular upstream VCS revisions as being significant points of reference for my project.

Yup, that's the gb vendor story, use that.

@ardan-bkennedy responding to some of your comments.

From a build perspective we only need to make sure a dependency is properly loaded on disk so the build can take place. I would like to state import path rewriting is never an option.

For the perspective of gb, assume that this feature means $PROJECT/vendor/src is a lazy populated cache. If that description doesn't help, please ignore it.

This is complicated because where are you going to load these dependencies on disk?

You mentioned import rewriting, you know how dimly I view that, so assume I'm not going to slip and let that happen. This of this cache as extra GOPATH entires that are populated lazily.

Dave is saying this cache will be a location for a user. I come from a perspective of working on different client projects. This will cause me problems because it will result in the cache folder being shared across clients. Maybe an environment variable can be used to help these types of situations. Maybe there is another convention based on how projects are named or a special folder inside the project that can be used as convention to find the cache folder? Something to think about.

Two things, the cache is of your project's dependencies, not your projects' code. The names of the items in the cache follow the usual rules of go get, ie, they look like urls. I'm not sure there can be an overlap there.

@lucidlime yup, that's basically how I see it. It's a cache keyed by <importpath,version> tuples.

Thanks to everyone for your feedback. Based on your responses I've updated the proposal, the changes are:

This feature will be opt in, it will be enabled by the presence of a dependency file in the project root.
This feature will be enabled only if the dependency file is present, and the dependency file lists explicitly the version required. If the file is updated to reflect a version which is not present locally, that will be downloaded in due course.

Dependency file
As the unanimous decision is to only use this feature for downloading specific release versions (I keep saying this, because I'm making a difference between release version, which is something the upstream does, and vcs revisions, which is just some old git hash), there needs to be somewhere to store this information.
I am proposing that this information be stored in a file in the root of the $PROJECT, the presence of this file will enable fetching to the per user cache dependencies matching an import path prefix (this logic will need some tightening up) -- if the file isn't there, or the prefix isn't matched, then nothing will be downloaded, the dependency will be reported as missing.
I've sketched an implementation for the format of this file in #537. I welcome your comments.

I don't understand what you mean by "semvers", it's just a convention, one that projects are actually doing anyway (check out core os, docker, etc).

I meant that some projects use semvers in tags (VCS aliases), but not every dependency out in the world does. This is different from the Maven world, where there's so such thing as an artifact that lacks a coordinate in the group-artifact-version triple space.

I may not have understood your question, could you please restate it.

When gb-vendor fetches a revision, surely it must be able to figure out which version it got, even when it just asked for the tip ("HEAD"). It can record this version internally. gb would then know that it has a copy of package P at VCS version V. That it can record that mapping internally is not the same as allowing the user to specify that mapping—perhaps by way of editing a file with a documented format, a la a Maven POM's dependencies element.
But I take your progress here to mean that you are allowing the user to specify that mapping. That's what I was suggesting you add as an evolution of what I think gb-vendor already does, promoting that internal bookkeeping to a user-editable specification.

I meant that some projects use semvers in tags (VCS aliases), but not every dependency out in the world does. This is different from the Maven world, where there's so such thing as an artifact that lacks a coordinate in the group-artifact-version triple space.

Yup, the fact that there is no release process for Go projects is a big problem at the moment.

When gb-vendor fetches a revision, surely it must be able to figure out which version it got, even when it just asked for the tip ("HEAD").

gb vendor records the revision it cloned from, go packages do not have a version, because there is no release process for Go projects.

It can record this version internally. gb would then know that it has a copy of package P at VCS version V.

gb vendor records the revision, not the version.

That it can record that mapping internally is not the same as allowing the user to specify that mapping—perhaps by way of editing a file with a documented format, a la a Maven POM's dependencies element.

If you mean recording which tag of a package to checkout, then that is what the depfile proposal is. If a simple release process of tagging revisions with a semver like tag is established, then that closes the loop.

But I take your progress here to mean that you are allowing the user to specify that mapping. That's what I was suggesting you add as an evolution of what I think gb-vendor already does, promoting that internal bookkeeping to a user-editable specification.

gb-vendor's manifest file is editable, but it's probably easier to use the tool to do that, and I think that doesn't really answer your question.
Here is how I see this working.

write some code that includes import "github.com/foo/bar"
add a line to your depfile, github.com/foo/bar version=1.9.3
gb now knows which tag to checkout, and will make sure that when the compiler goes to compile github.com/foo/bar as a dependency of your code, the copy of version 1.9.3 is compiled.

Tiny request: instead of a generic "depfile", it would be nice that the name of the file would have a direct relationship to the tool that should read it.  This makes it more obvious to the user which tool they need to build the system and reduces the chances of future naming conflicts.  Glide uses "glide.yaml", for example.  (This is a pet peeve of mine - e.g. Maven uses pom.xml and Ant build.xml - WTF?)
For example, "gb-build" or "gb-debs".

@jalkanen that's a fair request, nothing is set in stone at the moment, so now is the time to bikeshed. The depfile is only designed to hold the missing dependency information that is not available in the .go source file itself. I know others have plans for a much more comprehensive project metadata file, but I only need these few lines of information -- just the simplest thing that could possibly work.
If this feature is successful, probably one of two things will happen

Other dependency tools will support the depfile
gb will grow to a full project metadata file. If so, I don't want to steal the name for that file.

So, with those restrictions, what's a good name ?

dependencies.txt
deps.go ??
godeps ??


Fix segfault when using funpointer

This fixes the support for passing function pointers on platforms that use the no-exec bit in memory.
I believe this may be the underlying cause of issue ctypes #500, as we experienced the same issue when working on improvements for async_ssl.
The code was previously ignoring the function pointer provided by libffi and trying to executing the closure object directly (correct behavior for non no-exec platforms).

Many thanks for tracking down and fixing this problem, @tiash.
The fix looks right to me, and I've confirmed that it addresses the issue on an SELinux system.


fix-example-yaml

When a specific physical GPU device is assigned, the container can only request one GPU.
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Help the user feel less confused.
Which issue(s) this PR fixes:
Personal observation, No issues found.
Special notes for your reviewer:
Does this PR introduce a user-facing change?: no

Thank you for your contribution


Stretched border when cropping from landscape to portrait

Hi, I am trying to crop a video from 1280x720 to 404x720 (same aspect ratio but portrait).
The result is a video with a small stretched margin in the right side. (See picture)

I did used FillMode.CUSTOM but with scale 1, translation 0. Same thing with other fill modes.
Any idea what is happening?

The problem was caused by not using SurfaceTexture.getTransformMatrix() when rendering the video


Limit image upload size per file type

Is your proposal related to a problem?

We have noticed that when a user uploads a large PNG image 8MB+, that we get a request timeout error when we try to view the image in the Wagtail admin (we use Heroku that has a 30 second request timeout). It also has problems rendering the image on the website front end. We don't seem to get this problem with JPG images of a similar size, so it might be an underlying PILLOW/PIL PNG compression/decompression issue.
Therefore, it may be useful to be able to override the image upload size based on file type.
Describe the solution you'd like

# Keep what we already have as a fallback
WAGTAILIMAGES_MAX_UPLOAD_SIZE = 10 * 1024 * 1024  # 10mb

# Allow an override based on file type
WAGTAILIMAGES_MAX_UPLOAD_SIZE_JPG = 12 * 1024 * 1024  # 12mb

# Allow an override based on file type
WAGTAILIMAGES_MAX_UPLOAD_SIZE_PNG = 5 * 1024 * 1024  # 5mb

Describe alternatives you've considered

I except that the real issue might be with PILLOW/PIL being slow, but I don't really have any control over that. So some limit on upload sizes per file type would probably solve the issue for me.
Additional context

N/A
Working on this

Anyone can contribute to this. View our contributing guidelines, add a comment to the issue once you’re ready to start.

I'm not sure how useful this is in core.
You can achieve this yourself if you have a custom image model by overriding the image field and customizing how file size validation is done:
https://github.com/wagtail/wagtail/blob/2d568dd825e4b087d7cea1c4d1fa49d916b395c2/wagtail/images/fields.py#L108-L122

It looked quite difficult to override the image field when I traced it through, even with a custom image model (that I don't currently have). So my potentially simpler solution was to override the WAGTAILIMAGES_IMAGE_FORM_BASE, create a CustomImageForm and WAGTAILIMAGES_MAX_UPLOAD_SIZE_PNG setting.
import os

from django.core.files.uploadedfile import InMemoryUploadedFile
from django.core.exceptions import ValidationError
from django.conf import settings
from django.template.defaultfilters import filesizeformat

from wagtail.images.forms import BaseImageForm

class CustomImageForm(BaseImageForm):

    def clean_file(self):
        f = self.cleaned_data['file']

        # Only inspect the initial file upload
        if isinstance(f, InMemoryUploadedFile):
            extension = os.path.splitext(f.name)[1].lower()[1:]

            if extension == 'png':
                max_upload_size_png = getattr(settings, 'WAGTAILIMAGES_MAX_UPLOAD_SIZE_PNG', 10 * 1024 * 1024)

                if f.size > max_upload_size_png:
                    max_upload_size_text = filesizeformat(max_upload_size_png)

                    raise ValidationError(
                        'File is too large: %(file_size)s is larger than %(max_upload_size_text)s limit for PNG image files'
                        % {
                            'file_size': filesizeformat(f.size),
                            'max_upload_size_text': max_upload_size_text,
                        }
                    )
        return f


examples/mnist_cnn.py gives TypeError: only integer scalar arrays can be converted to a scalar index

[x] Check that you are up-to-date with the master branch of Keras. You can update with:
pip install git+git://github.com/keras-team/keras.git --upgrade --no-deps

[x] If running on TensorFlow, check that you are up-to-date with the latest version. The installation instructions can be found here.

[ ] If running on Theano, check that you are up-to-date with the master branch of Theano. You can update with:
pip install git+git://github.com/Theano/Theano.git --upgrade --no-deps

[x] Provide a link to a GitHub Gist of a Python script that can reproduce your issue (or just copy the script here if it is short).

https://github.com/keras-team/keras/blob/master/examples/mnist_cnn.py
running it gives error
TypeError: only integer scalar arrays can be converted to a scalar index

Which version of python were you using? Did this error occur before training or during training ?

using Python 3.6.4
this occurs at line 31.


Add no shuffle tag to test affected by today's seed

This adds a no shuffle tag to reopen the tree.
Fixes https://github.com/flutter/flutter/issues/90057
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Closing in favor of https://github.com/flutter/flutter/pull/90067


pySCG: Missing rules on CWE Top 25

Most Dangerous Software Weaknesses CWE Top 25 2023  can be interpreted as mandatory for a learning resource on secure coding.
Will need to debate list of rules to add to the Python - Secure Coding One Stop Shop
Missing rule:
1 : CWE-787 Out-of-bounds Write
4 : CWE-416 Use After Free
14 : CWE-190 Integer Overflow or Wraparound
17: CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer
23 CWE-94 Improper Control of Generation of Code ('Code Injection')
Not Python ?, JavaScript/Web/HTML/Architecture:
2 : CWE-79 Improper Neutralization of Input During Web Generation ('Cross-site Scripting')
7 : CWE-125 Out-of-bounds Read
9 : CWE-352 Cross-Site Request Forgery (CSRF)
11: CWE-434 Missing Authorization
13: CWE-287 Missing Authentication
19: CWE-918 Server-Side Request Forgery (SSRF)
20: CWE-306 Missing Authentication for Critical Function
22: CWE-269 Improper Privilege Management
24: CWE-863 Incorrect Authorization
25: CWE-276 Incorrect Default Permissions
Similar existing rule, need to check:
6 : CWE-20 Improper Input Validation
8 : CWE-22 Improper Limitation of a Path-name to a Restricted Directory ('Path Traversal')
10: CWE-434 Unrestricted Upload of File with Dangerous Type
16: CWE-77 Improper Neutralization of Special Elements used in a Command
Existing Rule, either online or pending publication as part of #531 :
3 : CWE-89 SQL Injection
5 : CWE-78 Os Command Injection
12 : CWE-476 NULL pointer Dereference
15: CWE-502: Deserialization of Untrusted Data
18: CWE-798 Hard-coded Credentials
21 CWE-362 Concurrent Execution Using Shared Resource with Improper Synchronization ("Race Condition")
Rg Helge

The following aren't relevant in Python (unless you include C extensions, which I presume is out of scope):

1 : CWE-787 Out-of-bounds Write
4 : CWE-416 Use After Free
14 : CWE-190 Integer Overflow or Wraparound
17: CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer

I created #715 as a small step towards this.


pkg/metrics: introduce v2

Introduce a v2 version of pkg/metrics. The current metrics package is not optimal:

Using objects that have been called with With allocated on each increment/set value call.
Having the option to call With ties consumer code with initialization code.
There is no way whether a counter is fully initialized with all labels.

A full discussion can be found in
https://github.com/scionproto/scion/pull/4527.
The new v2 version is compatible with prometheus, so no explicit conversion functions are offered, instead the prometheus creation functions can be used directly.
So far the new library has been plugged in selected places. The intention is that it will eventually replace the current library completely, however doing so in a single sweep would be too extensive.

This change is


Refactor/api

First step in standardizing the API. Lots of endpoints have been disabled due to needing a more impactful change in the code, I would rather fix those in upcoming PRs. The ones that are still active and have been tested. All of them have been moved to the new standardized API standards: the URL has been changed and the response format has been changed.
bootstrap/services.php might have to be deleted for ResponseServiceProvider to be seen (bug in Laravel 5.2).
Should merge #12 first

Too much to review, I trust you :D

Somehow it is not updating the comparison, a lot of these commits are already merged from PR #11 and #12

You can compare them here:
https://github.com/AEGEE/oms-neo-core/compare/refactor-2...refactor/api?expand=1

OK I approve


3.9.1-Preview: Add preview version 3.9.1

Pull Request Template
Description
Bump the preview API version to 3.9.1 and add 3.9.1 preview contract
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Is this 3.9.1 or 3.9.0-preview2? Because we didn't release 3.9.0, right?

Also, should the DIFF be versus 3.9.0-preview? It looks like it's against an earlier version (FeedToken mentions)