Access to current_user inside of rails-api

Hello everyone! I'm totally newbie in AngularJS. I try to set up authentication using your library, and I've stuck in one point. I use rails-api as a backend. When trying to achieve current_user inside of it, I have 401 Unauthorized error. I don't know what it could be, so I've try to compare pure working RoR/Devise (without json api) request, with my own (not working). Seems like I have no valid cookie.
Working example sends something like:
Cookie: _notes_session=RVo2cUo4SXRNblMrYnFZdURlV09pSUFFdEMvOHIvSTEwZjNjaXQ5NnlkYlhId3ZEYkpIaXJWdHJOaDFUUTRjYTcrdTJ5cDNId2paKzNlQUlPU05XMzBiTDlVTFR5TXpNdE1yc0RlNjJFeCtqQTNSclZVbHVTMmwzZWpUNER3c25zTllqaElrb0h1SCtKNnFhSFBST0F1TlpCWm0xbC9Qc0dMakxiZGtwY0NiS2pTeTRCZWw5SE5jRE5sTElRaGNTY1VreVI2dW5RUExUV0plYnZ5Ym9PblMzMDRUQlBmTEZVOWkxcktTVHdYOE5vN2hXaDNTVFhJUmEvN1NNMGRKTkh0TEFNSTN1by9mQTgyNzZ0VUdJb2Q1QTBMWlFRem1QSmRzcy9pcFNkOW5ZcmFiUFQ0Z3pZRjg1YzZKZzlQdXktLVZQUURqWmZYa2VDaXc1WWQ0RjgwZUE9PQ%3D%3D--f58ab59c39ff22799c3e577ae52b92765ce7d249
The question is: Do I really need that cookie to be authorized in my rails-api app, and when can I get this cookie.

Sorry, it was on rails-api side. Rails-api by default doesn't use ActionDispatch::Cookies and ActionDispatch::Session::CookieStore. You can prevent it by setting config.api_only = false in your application.rb.

But I suppose it's not a good practice


python3Packages.wandb: 0.12.16 -> 0.12.17

Motivation for this change
Upgrades python3Packages.wandb from 0.12.16 to 0.12.17
This PR was automatically generated by nixpkgs-upkeep.

CI workflow that created this PR.
Internal tag: 2ddb47e782f5cdf724c813f4eba6dd42.

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 174823 run on x86_64-linux 1

12 packages built:

openai (python39Packages.openai)
python310Packages.openai
python310Packages.spacy
python310Packages.spacy-loggers
python310Packages.spacy-transformers
python310Packages.textacy
python310Packages.wandb
python39Packages.spacy
python39Packages.spacy-loggers
python39Packages.spacy-transformers
python39Packages.textacy
python39Packages.wandb

LGTM I'll go ahead and merge tomorrow unless anyone objects


Loosens Rails version requirement on 5.0.0

The current constraint will require an update to lograge when Rails
5.0.1 is released. Previous versions of lograge only required a minimum
version and that appears to have worked out well. Given that, and the
stability of the internal Rails API, it's likely fine to just expect a
minimum version.

Closed via #182


Add support for conditional requests with ETag and Last-Modified headers

Quick summary of how this would work:

If a cached response contains an ETag header, add an If-None-Match header to the new request
If a cached response contains a Last-Modified header, add an If-Modified-Since header to the new request
If a 304 Not Modified response is received, returned the cached response and update expiration and headers (if changed)
If a 200 response is received, update the cache and return the new response

I have a workaround implemented which can be found here:
https://github.com/netomi/otterdog/blob/main/otterdog/providers/github/rest/requester.py#L182
I am willing to work on a patch to have this integrated in this library by default.
Something that I noticed while working on the workaround: when using session.disabled() to temporarily disable the cache, this is only valid for getting requests from the cache, the cache itself is still updated with responses received from the remote server, this should be fixed imho, as it is misleading, will create a separate ticket for it.

I am willing to work on a patch to have this integrated in this library by default.

That would be great! Thank you.

when using session.disabled()... the cache itself is still updated with responses

That's not the intended behavior, and this is supposed to be handled here. Thanks for the heads up.

Created #182 to illustrate the problem. The problem is that there are 2 ways to determine whether the cache is used. Via the cache actions and the is_cacheable method which leads to very wrong behavior when the cache is disabled which is hidden from the user. I just noticed some problems as strangely some cached responses got removed and I wanted to understand why.


Change the behavior of file extension associations

VSCode Version: Code 1.14.1 (2648980a697a4c8fb5777dcfb2ab110cec8a2f58, 2017-07-13T19:08:57.197Z)
OS Version: Darwin x64 16.6.0
Extensions:

Extension
Author (truncated)
Version

vscode-eslint
dba
1.2.11

vscode-dash
dee
1.7.0

tslint
eg2
0.16.0

vscode-npm-script
eg2
0.2.0

Steps to Reproduce:

Install Visual Studio Code
Click on any previously unassigned extension
Visual Studio Code will be opened instead of the previous app or nothing

I tried out Visual Studio Code and it is working fine but we are still in getting know each other phase.
Unfortunately Visual Studio Code aggressively assigned itself to all the extensions it knows and that feels very intrusive. I tried to un-assign the associations with RCDefaultApp without any luck.
Could you please somehow change the behavior or not assign anything by default? Thanks!

Reproduces without extensions: Yes

I could never reproduce this issue. What we have set up is the fact that Code registers itself as an application which is able to open a variety of different file formats. If you have never specified another application for a specific file format, it may very well be that Windows assumes that Code is the only one that can open it. On the other hand, if you have specified that application X should open file type A and then install Code, file type A will not be associated with Code. If you see otherwise, please tell me which file extension it is and which application was initially associated with it and I'll try to reproduce.
Ultimately we added an option in the setup (disabled by default) which lets you skip the association altogether, for this specific purpose.


Oauth "code" response for authorization code is not working to generate token

The code in the params response after going through the Oauth screen on my web app is not working
"Every user who authorizes your app will be redirected to the redirect_uri with an extra code parameter that looks something like 4/Ja60jJ7_Kw0. Just pass the code to the following method to authenticate and initialize the account:"
The code in the params is not in the same format as the code in the readme. I am getting something like this (changed slightly ofc)
https://thesiteIused.com/?code=4%2F0AJ0e-g7gQK-e6WKtMoE01IwApIrf5ScmV7qA1_aRDfpz5_JIGc0rqZxomd1aKk61rn4Mtg&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.upload%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube

I have tried using the whole code, parts of it, first 13 characters, percentage sign instead of a backslash, and everything in between. Still getting the following response.
A request to YouTube API was sent without a valid authentication: (Yt::Errors::Unauthorized)

Please note that if you're trying to call account.email, you'll need to request the userinfo.email scope.

I've faced the same situation and turn out the code 1 time use. So take the code and make an http request to google to get an access token and/or a refresh token to use with the library. Here is some code to exchange code to get tokens:
response = HTTParty.post(
      'https://accounts.google.com/o/oauth2/token',
      body: {
        client_id: ENV['YOUTUBE_CLIENT_ID'],
        client_secret: ENV['YOUTUBE_CLIENT_SECRET'],
        grant_type: 'authorization_code',
        code: @code,
        redirect_uri: @redirect_uri,
      },
      headers: {
        'Content-Type' => 'application/x-www-form-urlencoded'
      }
    )
    raise "Error: #{response.code}" if response.code != 200
    JSON.parse(response.body)

@giaunguyen2176, what is @code supposed to represent?

@synthead After signing in, google will redirect back to your registered callback url, which contains the code.


haddock: internal error: ..Cabal.../share/doc/html/doc-index.json: openBinaryFile: does not exist

Upon executing cabal v2-haddock --builddir=dist-docs.TTPG5l --haddock-for-hackage --enable-doc in ghcup-hs repository with ghc-9.2.6 and cabal <IP_ADDRESS>, I get:
haddock: internal error: /home/hasufell/.cabal/store/ghc-9.2.6/Cabal-<IP_ADDRESS>-694a87f40315650fbba1948b50f641d2839f3ae8b3cdaca746ac1c0a4650d8b2/share/doc/html/doc-index.json: openBinaryFile: does not exist (No such file or directory)
Error: cabal: Failed to build documentation for ghcup-<IP_ADDRESS>.

https://github.com/commercialhaskell/stack/issues/5694

https://github.com/haskell/cabal/issues/8104

The --haddock-options=--quickjump workaround from the cabal ticket doesn't work for me.

I also bumped into this error on cabal <IP_ADDRESS> and the --haddock-options=--quickjump workaround from https://github.com/haskell/cabal/issues/8104 also didn't work for me.
I ended up switching back to cabal <IP_ADDRESS> (which is still the version recommended by ghcup), where the workaround above still works.

@pasqu4le are you using GHC 9.2 or earlier? 9.2 series is at the end of life and the Haddock-side fix (#1488) has never been ported to it, unfortunately. SO, you either stick to Cabal 3.6 on GHC 9.2 or you can elect to upgrade both the compiler and the build tool: GHC 9.4+ and Cabal 3.8+ don't seem to suffer from this issue.
Some discussion: https://github.com/haskell/cabal/issues/9060#issuecomment-1604374404

Ah, yes, I'm indeed still using an older version of GHC.
@ulysses4ever thank you for answering and for the additional context :+1:

@pasqu4le good news is that this problem will probably be fixed in the coming real soon now Cabal 3.10.2.

I'm running into this issue now with brick-2.1. Hackage isn't building the docs for that release, and when I try to do it locally in order to upload to Hackage, I get the error that resulted in this ticket. I'm using GHC 9.2.7 and cabal-install <IP_ADDRESS> (Cabal <IP_ADDRESS>). Any recommendations for what I can do to resolve this in my situation?

@jtdaugherty https://github.com/haskell/haddock/issues/1582#issuecomment-1611412223

@jtdaugherty yeah, you can upgrade to GHC 9.4 and then deal with all the clang fallout on windows.


add Lock - unlock / open (to open lock remotely)

This won't work. You have lock twice.
I think I will add another button option: on / off. So for some entity types like switch and light it will change the service.
Or maybe a option so you can set the service yourself? But then again, you can only use services that only require entity_id. Less user friendly.

And btw, you already have a PR open with similar goal. Do this there.


[5.3] Add @elseunless to blade

I found myself wanting this today.
Not sure if you guys find it useful or not.
This PR will allow you to do this:
@unless ($collection->where('year', 2016)->isEmpty())
    // do something
@elseunless ($collection->where('year', 2015)->isEmpty())
    // do something
@else
    // do something
@endunless

Done.
I also fixed one that was already there previously.

Thanks. :)

I dont know. I just find this kind of hard to reason about.

This seems like a good idea to me.  If @unless(condition) is the same as @if(!condition) it would follow to have the rest of the control structure analogues implemented as well, especially for consistency.


[BUG] Cannot read property 'playlistId' of undefined

Steps to reproduce:

Navigate to the Watch later playlist.

Expected results:
No error to be displayed.
Actual results:
A Cannot read property 'playlistId' of undefined message is displayed instead of the slider.

:tada: This issue has been resolved in version 1.5.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Replace golint with revive

Changes
See https://groups.google.com/g/golang-nuts/c/rCP70Aq_tBc/m/8QHp6_cqBgAJ
as towards golint's deprecation. revive is supposed to be a drop-in
replacement.
/assign @julz

/approve


Update type definitions to match the latest in electron

ElectronMainAndRenderer has become AllElectron in the type definitions distributed with electron.

fixes #201


Could support doctrine/dbal to 3.x ?

Could support doctrine/dbal to 3.x ?

@limingxinleo done this on #75 🎊 👍

@limingxinleo done this on #75 🎊 👍


[mesheryctl] default token location displayed twice

See mesheryctl Command Tracker for current status of commands.
Current Behavior

The default location of the config string is shown twice under the "Global Flags".

Desired Behavior

Show it only once using Cobra's inbuilt capabilities.
Environment

Host OS: Mac
Meshery Server Version: edge-latest
Meshery Client Version: edge-latest
Platform: Docker

Contributor Resources

mesheryctl Contributing Guide
Beginner's guide to contributing to Meshery and mesheryctl
mesheryctl Command Tracker
Meshery CLI Commands and Documentation
🙋🏾🙋🏼 Questions: Layer5 Discussion Forum and Layer5 Community Slack

hey there, I want to give it a try.

Go ahead @afzal442


[JS-0693] Removed all v-html references in the project

Description
I have found every occurrence of v-html use in the vue codebase.  All of it has been replace with templated blocks of code as to prevent a xss vulnerability.  It was fixed by moving the string literal of the html code and moving it up to the template.  The function now only exports the variables injected into the interpolated expressions via a computed property.
bug fixes #JS-0693 (bugs from https://bugzilla.nearbeach.org)
One issue is I had to assume the noteHistory['fields']['object_note'] always contained a single <p> tag since that it how it is structured in NearBeach_basic_setup.json.  If this object can contain more complex html, v-html might be necessary
This PR completes issue #251
Type of change

[x] 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)
[ ] Database change that requires a migration
[ ] This change requires a documentation update

How Has This Been Tested?
I'm fairly sure this will work but I was unable get the environment running to test locally due to my unfamiliarity with python.
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Local manual testing via "./manage runserver"
[ ] Local Python Unit Testing via "./manage test"
[ ] Local Cypress E2E Testing
[ ] Tested on virtual box
[ ] Tested on server

Checklist:

[ ] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Sadly it is the output of a WYSIWYG. So they could have H1..H2 etc, ,

@alexjharrison I have flagged this as hacktoberfest-accepted :D So I am hoping this gets counted towards your t-shirt :D

Ah, since it's being saved as html from a WYSIWYG I don't think this is possible without a large rework.  Thanks for tagging me.
I'll go ahead and close the PR for this issue.


Refactor building process to be able to publish multiarch docker images

Closes #73
This PR adds support for multi-arch Docker images:

Refactored how binaries are built.
Refactor how docker images are built.
Docker images are built with the arch suffix.
Docker image creation will create a virtual tag that will reference the different images to the archs.
Use gcr.io/distroless/static:nonroot as the final base image instead of alpine.

Codecov Report

Merging #92 (4673fbe) into main (ceeb43f) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 4673fbe differs from pull request most recent head 76553b8. Consider uploading reports for the commit 76553b8 to get more accurate results

@@           Coverage Diff           @@
##             main      #92   +/-   ##
=======================================
  Coverage   80.24%   80.24%
=======================================
  Files          15       15
  Lines         815      815
=======================================
  Hits          654      654
  Misses        114      114
  Partials       47       47

Continue to review full report at Codecov.

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


Hard to select Admin parent  Menu ID

Cannot see the icons for the + /-   in select menu and menu order.
am missing the files.
will reload software

reloaded software from zip, issue resolved. might have been a composer glitch.


Standard Library Arg Functions Not Working

Arg and ArgCount Functions in the Standard Library do not work since the program arguments array is never initialized with the library.

Including in 0.5.0 milestone to go along with command line compiler goals


Exports more Types

Export (almost all) types and helper functions that are needed to construct the argument
of the subscribe function.

bors r+

bors r+


With solo5, firewall runs out of memory after a while and can't recover

First reported by @palainp in https://github.com/mirage/qubes-mirage-firewall/pull/116#issuecomment-708936007. I see this too now, after a few days.
2020-10-26 15:26:48 -00:00: INF [memory_pressure] Writing meminfo: free 115MiB / 124MiB (93.24 %)
[...]
2020-10-27 09:00:57 -00:00: INF [client_eth:dom33:<IP_ADDRESS>] who-has <IP_ADDRESS>? responding with fe:ff:ff:ff:ff:ff
2020-10-27 09:01:04 -00:00: INF [memory_pressure] Writing meminfo: free 13MiB / 124MiB (9.99 %)
2020-10-27 09:01:04 -00:00: WRN [firewall] Memory low - dropping packet and resetting NAT table
2020-10-27 09:01:04 -00:00: INF [memory_pressure] Writing meminfo: free 13MiB / 124MiB (9.99 %)
2020-10-27 09:01:04 -00:00: WRN [firewall] Memory low - dropping packet and resetting NAT table
2020-10-27 09:01:04 -00:00: INF [memory_pressure] Writing meminfo: free 13MiB / 124MiB (9.99 %)
2020-10-27 09:01:04 -00:00: WRN [firewall] Memory low - dropping packet and resetting NAT table

I managed to get memtrace (and memtrace_viewer) to work with MirageOS unikernels -- take a look at https://github.com/hannesm/memtrace-mirage this may be useful for debugging it further (being able to see the OCaml view of which call stacks refer to how much memory) -- see https://blog.janestreet.com/finding-memory-leaks-with-memtrace/ for a great description of memtrace_viewer.

My current thinking is that malloc_footprint() is too pessimistic and need some time to be updated when we run out of free memory.
The second solution offered by @mato in https://github.com/mirage/qubes-mirage-firewall/pull/116#issuecomment-704827905 was to use sbrk(0) instead of malloc_footprint() but this function is currently not available in nolibc (https://github.com/mirage/ocaml-freestanding/blob/master/nolibc/include/unistd.h).
The easiest workaround may be to add the state function (and use the slower but more accurate mallinfo) in addition to the actual quick_state and if we get low on free memory reported by quick_state we can more accurately assess the free memory before calling the GC. We will see a drop in performance (or a growth on CPU usage) for a while but when quick_state will be updated the unikernel will work as before.

It seems to fail very suddenly. Here's an example (I got it to print GC stats and heap stats once a minute; the unikernel had been running fine for several days before this):
GC stats
minor_collections: 7775
major_collections: 149
compactions:       0

minor_words:<PHONE_NUMBER>
promoted_words:   32060857
major_words:      32078117

top_heap_words: 1331712
heap_words:     1331712
live_words:     1008819
free_words:      316710
largest_free:       384
fragments:         6183

live_blocks: 271475
free_blocks: 49212
heap_chunks: 14
2020-11-01 03:31:48 -00:00: INF [memory_pressure] :Writing meminfo: free 115MiB / 124MiB (93.24 %)

GC stats
minor_collections: 7822
major_collections: 150
compactions:       0

minor_words:<PHONE_NUMBER>
promoted_words:   32236779
major_words:      32254039

top_heap_words: 1331712
heap_words:     1331712
live_words:     1184741
free_words:      140033
largest_free:       800
fragments:         6938

live_blocks: 309418
free_blocks: 15954
heap_chunks: 14
2020-11-01 03:32:48 -00:00: INF [memory_pressure] :Writing meminfo: free 115MiB / 124MiB (93.24 %)

GC stats
minor_collections: 7942
major_collections: 153
compactions:       0

minor_words:<PHONE_NUMBER>
promoted_words:   32681555
major_words:      32698815

top_heap_words: 1531904
heap_words:     1531904
live_words:      693951
free_words:      835167
largest_free:    194872
fragments:         2786

live_blocks: 204263
free_blocks: 23925
heap_chunks: 15
2020-11-01 03:32:57 -00:00: INF [memory_pressure] :Writing meminfo: free 12MiB / 124MiB (9.10 %)
2020-11-01 03:32:57 -00:00: WRN [firewall] Memory low - dropping packet and resetting NAT table

GC stats
minor_collections: 7943
major_collections: 155
compactions:       0

minor_words:<PHONE_NUMBER>
promoted_words:   32681970
major_words:      32699230

top_heap_words: 1531904
heap_words:     1531904
live_words:      468643
free_words:     1062198
largest_free:    194812
fragments:         1063

live_blocks: 144429
free_blocks: 14564
heap_chunks: 15
2020-11-01 03:32:57 -00:00: INF [memory_pressure] :Writing meminfo: free 12MiB / 124MiB (9.10 %)

So, it had 115 MB free. Then it tried to increase the OCaml heap by 1.5 MB. Then there was only 12 MB free??
When this happened, I was uploading a 30K file to gmail.
When it happens, it always seems to have just under 10% free.

If you give it, say, 512MB of memory, and sample meminfo every 30s or so (both the raw numbers from GC and OS.MM), what does that look like over time? And, is there an amount of memory with which you reach a plateau and don't run out?

@mato: that's roughtly what I'm doing already (except sampling every 60s rather than every 30s). I'd normally run the firewall with 32MB, but here I'm testing with 128MB, which should be way more than it needs.
Memory use looks completely flat until it fails. I only showed the last two good reports before failure, but it continued like that for days.
Note that the reports above where it went from 115 MB free to 12 MB free (and head_chunks went up by 1) are only 9 seconds apart!

Memory use looks completely flat until it fails. I only showed the last two good reports before failure, but it continued like that for days.

Ah, so, it suffers from "sudden death" after working fine for days. That's very strange. No ideas off the top of my head, I'll think about it.

Between 03:32:48 and 03:32:57 the number of fragments is divided by 2 and the size of the largest free block increased a lot, it may reveals a memory consolidation from the allocator.
I'm not sure I understand correctly how and when the footprint value is updated but looks like we might have to expect success in this test : https://github.com/mirage/ocaml-freestanding/blob/master/nolibc/dlmalloc.i#L4775
This bug is difficult to trigger because we may have to wait a long time to get it. I'm currently trying to evaluate the free memory available with mallinfo() if we are low on the value reported by malloc_footprint.

Update:
I use a mirage-xen pinned at https://github.com/palainp/mirage-xen.git that add stat() using mallinfo() and this modified status function in memory_pressure.ml:
let status () =
  let stats = OS.Memory.quick_stat () in
  if fraction_free stats > 0.1 then `Ok
  else (
    let stats = OS.Memory.stat () in
    if fraction_free stats > 0.1 then (
      Log.info (fun f -> f "quick_stat reported low memory but stat doesn't");
      `Ok
    ) else (
      Gc.full_major ();
      let stats = OS.Memory.stat () in
      report_mem_usage stats;
      if fraction_free stats < 0.1 then `Memory_critical
      else `Ok
    )
  )

This morning I got the following in the unikernel logs:
2020-11-06 09:02:16 -00:00: INF [client_eth:dom15:<IP_ADDRESS>] who-has <IP_ADDRESS>? responding with fe:ff:ff:ff:ff:ff
2020-11-06 09:02:24 -00:00: INF [memory_pressure] quick_stat reported low memory but stat doesn't
...
2020-11-06 09:02:57 -00:00: INF [memory_pressure] quick_stat reported low memory but stat doesn't
2020-11-06 09:03:22 -00:00: INF [client_eth:dom10:<IP_ADDRESS>] who-has <IP_ADDRESS>? responding with fe:ff:ff:ff:ff:ff

So now I still don't know what the bug is due to, but when it appears the kernel runs 100% for 30" then goes back to a normal situation.

After the previous quick_stat reported low memory but stat doesn't the unikernel worked fine for 2h, but then this message came back and stayed for another 2h...
Now I'm trying to use malloc_trim() when there is a difference between the free memory returned by footprint() and mallinfo() to try to update the value returned by footprint() sooner : https://github.com/palainp/ocaml-freestanding/commit/d50da12bca520e8b4f8b89f8d5bbb4508654632d https://github.com/palainp/mirage-xen/commit/2ec471009f246bc9ad37715d1b30c72f353f181c https://github.com/palainp/qubes-mirage-firewall/commit/1d459cde1b03564221cbddb262df555775a322f9

Update: Unfortunately, using malloc_trim() didn't change anything (the quick_stat still report low memory when stat doesn't). I'm now trying to call sbrk() instead of malloc_footprint(): https://github.com/palainp/mirage-xen/commit/fddeef92a01ade0817f481bbf20a1970549214a0 (and ocaml-freestanding no longer need to be pinned).
I actually have the same memory reporting with malloc_footprint() when the unikernel starts:
2020-11-12 06:58:15 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB / 60MiB (85.90 %)

and with sbrk():
2020-11-12 14:14:19 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB / 60MiB (85.89 %)

bit of a strange observation here.
my "mirage fw test instance" is between a "vpn VM" and a "sync backup offsite" one that gets restarted hourly.
this tends to be a not so bad test because it sees a lot of vm stop/starts and plenty of traffic and doesnt make me too unhappy when it breaks (the backup sync will just restart it on next cycle).
for the last 5 days, i have been running a mirage-fw with the following particulars there:

templated pvh,  so with https://github.com/Solo5/solo5/pull/482 applied so it would start through grub
the "report mem stats every 10 min" from https://github.com/mirage/qubes-mirage-firewall/pull/121
vm set to memory 42, maxmem 1000 (which in practice gets reported as 1GB total by solo5 from the start, and xen slowly adjusts it up over the next few days)

this fw has been stable for 5d now, and grepping the log there has been zero movement in the mem stats, they have all been "INF [memory_pressure] Writing meminfo: free 987MiB / 996MiB (99.16 %)".
it did not even blink with different amounts of downstream VMs, and it has been pushing a lot of GBs in those days, using up about 25k sec of CPU time.
for comparison, another instance (no mem-reporting, started as dom0-supplied kernel, 64MB total) would reliably hit the OOM wall within very few hours.
not fully sure what that means yet, some options include "it didnt see any peaks at all", "the peaks are too short to be seen with 10min reporting, and stay well below 1GB", or "the OOM doesnt happen when started through multiboot".
going to crosstest with a different load profile // usecase and a different mem setting and/or bootpath in the backup role next.

i can rule out "something different about the used package versions" (caused by pinning solo5 to dev for multiboot or building outside docker in general):
the exact same binary that is stable when run templated/grub/multiboot hits the OOM wall when running via "plain xen" path.
still no OOM when multibooted, and using it in "all roles" now.
one unrelated looking crash:
Fatal error: exception (Failure "Netif: ERROR response")
Raised at file "string.ml", line 115, characters 19-34
Called from file "src/sexp.ml", line 113, characters 13-47
Solo5: solo5_exit(2) called

no idea what that was about or what triggered it.

Any developments on this?

From https://github.com/mirage/qubes-mirage-firewall/issues/120#issuecomment-728114134 I hear:

still no OOM when multibooted

Any updates on this @xaki23? The Netif error "Failure 'Netif: ERROR response'" is rather poor error handling, maybe @talex5 or @djs55 or @avsm have an idea what a good error handle should be? Maybe the netif should be removed? (Failing/exiting looks like the wrong strategy).

"Netif: ERROR response" only appears in frontend.ml, so this means the failed connection is the one to sys-net, so recovery probably isn't possible. Though perhaps it could try reinitialising the interface.

Update: Here are some news regarding this issue.
The #121 misled us because it seems that the memory suddenly drops below 10% which indicates that the unikernel is suffering from a sudden death error. In fact, the stats parameter is not updated before every meminfo prints.
If we change the code to:
let report_mem_usage stats =
  Lwt.async (fun () ->
      let rec aux () =
        OS.Xs.make () >>= fun xs ->
        OS.Xs.immediate xs (fun h ->
+            let stats = OS.Memory.quick_stat () in
            OS.Xs.write h "memory/meminfo" (meminfo stats)
          ) >>= fun () ->
        OS.Time.sleep_ns (Duration.of_f 600.0) >>= fun () ->
        aux ()
      in
      aux ()
  )

We can see that the free memory slowly decreases until it reaches the 10% threshold (without sudden death issue).
In the following log, the free memory decreases (a print is made every 2") when network traffic occurs:
2022-01-06 10:12:19 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB / 59MiB (84.99 %)
2022-01-06 10:12:21 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB / 59MiB (84.99 %)
2022-01-06 10:12:23 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB / 59MiB (84.99 %)
2022-01-06 10:12:25 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB / 59MiB (84.99 %)
2022-01-06 10:12:27 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB / 59MiB (84.99 %)
2022-01-06 10:12:29 -00:00: INF [memory_pressure] Writing meminfo: free 44MiB / 59MiB (73.03 %)
2022-01-06 10:12:31 -00:00: INF [memory_pressure] Writing meminfo: free 40MiB / 59MiB (66.19 %)
2022-01-06 10:12:33 -00:00: INF [memory_pressure] Writing meminfo: free 38MiB / 59MiB (64.05 %)
2022-01-06 10:12:35 -00:00: INF [memory_pressure] Writing meminfo: free 36MiB / 59MiB (60.88 %)
2022-01-06 10:12:37 -00:00: INF [memory_pressure] Writing meminfo: free 25MiB / 59MiB (41.18 %)

The current footprint function used to estimate the free memory comes from https://github.com/mirage/qubes-mirage-firewall/pull/116#issuecomment-704827905 because mallinfo() is too expensive to be called on every packet that comes to the firewall.
However footprint() is based on the acquired heap size from the system and is currently never lowered (we can call trim() but this is not exposed by mirage-xen).
We have therefore tried to implement a replacement for this footprint() which will follow the malloc/free calls to give an approximation of the 'currently used memory'. The current changes can be seen in https://github.com/winux138/mirage-xen/commit/aa7bde4a83cbe52ff58f1c356cd766b98fb3012a and https://github.com/winux138/ocaml-freestanding/commit/16f7a96071219fabe1aecb59bc86929e6a1d9993
The following log shows 3 differents things:

default footprint/stat function, the "Writing meminfo" lines (one call every 2")
my alternative footprint/stat function that tries to get closer to the correct value, the "Stat_alt" lines (one call every 2")
the GC calls and the real value for free memory given by mallinfo(), the "Stat_slow" (one call every 20")

2022-01-06 10:11:59 -00:00: INF [memory_pressure] Stat_slow meminfo: free 52MiB (54175264) / 59MiB (87.59 %)
2022-01-06 10:11:59 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54174160) / 59MiB (87.58 %)
2022-01-06 10:11:59 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:01 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54171824) / 59MiB (87.58 %)
2022-01-06 10:12:01 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:03 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54169440) / 59MiB (87.58 %)
2022-01-06 10:12:03 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:05 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54167040) / 59MiB (87.57 %)
2022-01-06 10:12:05 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:07 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54154784) / 59MiB (87.55 %)
2022-01-06 10:12:07 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:09 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54152304) / 59MiB (87.55 %)
2022-01-06 10:12:09 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:11 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54149168) / 59MiB (87.54 %)
2022-01-06 10:12:11 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:13 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54141952) / 59MiB (87.53 %)
2022-01-06 10:12:13 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:15 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54139584) / 59MiB (87.53 %)
2022-01-06 10:12:15 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:17 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54127312) / 59MiB (87.51 %)
2022-01-06 10:12:17 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:19 -00:00: INF [memory_pressure] Collect
2022-01-06 10:12:19 -00:00: INF [memory_pressure] Stat_slow meminfo: free 52MiB (54175264) / 59MiB (87.59 %)
2022-01-06 10:12:19 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54174160) / 59MiB (87.58 %)
2022-01-06 10:12:19 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:21 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54171728) / 59MiB (87.58 %)
2022-01-06 10:12:21 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:23 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54165040) / 59MiB (87.57 %)
2022-01-06 10:12:23 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:25 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54162688) / 59MiB (87.57 %)
2022-01-06 10:12:25 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:27 -00:00: INF [memory_pressure] Stat_alt meminfo: free 52MiB (54065536) / 59MiB (87.41 %)
2022-01-06 10:12:27 -00:00: INF [memory_pressure] Writing meminfo: free 51MiB (52571600) / 59MiB (84.99 %)
2022-01-06 10:12:29 -00:00: INF [memory_pressure] Stat_alt meminfo: free 48MiB (49556816) / 59MiB (80.12 %)
2022-01-06 10:12:29 -00:00: INF [memory_pressure] Writing meminfo: free 44MiB (45170128) / 59MiB (73.03 %)
2022-01-06 10:12:31 -00:00: INF [memory_pressure] Stat_alt meminfo: free 46MiB (47596640) / 59MiB (76.95 %)
2022-01-06 10:12:31 -00:00: INF [memory_pressure] Writing meminfo: free 40MiB (40943056) / 59MiB (66.19 %)
2022-01-06 10:12:33 -00:00: INF [memory_pressure] Stat_alt meminfo: free 45MiB (46788704) / 59MiB (75.64 %)
2022-01-06 10:12:33 -00:00: INF [memory_pressure] Writing meminfo: free 38MiB (39615952) / 59MiB (64.05 %)
2022-01-06 10:12:35 -00:00: INF [memory_pressure] Stat_alt meminfo: free 44MiB (45881520) / 59MiB (74.18 %)
2022-01-06 10:12:35 -00:00: INF [memory_pressure] Writing meminfo: free 36MiB (37658064) / 59MiB (60.88 %)
2022-01-06 10:12:37 -00:00: INF [memory_pressure] Stat_alt meminfo: free 41MiB (42171712) / 59MiB (68.18 %)
2022-01-06 10:12:37 -00:00: INF [memory_pressure] Writing meminfo: free 25MiB (25472464) / 59MiB (41.18 %)
2022-01-06 10:12:39 -00:00: INF [memory_pressure] Collect
2022-01-06 10:12:39 -00:00: INF [memory_pressure] Stat_slow meminfo: free 51MiB (52978304) / 59MiB (85.65 %)
2022-01-06 10:12:39 -00:00: INF [memory_pressure] Stat_alt meminfo: free 51MiB (52977200) / 59MiB (85.65 %)
2022-01-06 10:12:39 -00:00: INF [memory_pressure] Writing meminfo: free 31MiB (31821264) / 59MiB (51.45 %)
2022-01-06 10:12:41 -00:00: INF [memory_pressure] Stat_alt meminfo: free 49MiB (51112656) / 59MiB (82.63 %)
2022-01-06 10:12:41 -00:00: INF [memory_pressure] Writing meminfo: free 31MiB (31821264) / 59MiB (51.45 %)
2022-01-06 10:12:43 -00:00: INF [memory_pressure] Stat_alt meminfo: free 48MiB (50218128) / 59MiB (81.19 %)
2022-01-06 10:12:43 -00:00: INF [memory_pressure] Writing meminfo: free 31MiB (31821264) / 59MiB (51.45 %)
2022-01-06 10:12:45 -00:00: INF [memory_pressure] Stat_alt meminfo: free 48MiB (49546560) / 59MiB (80.10 %)
2022-01-06 10:12:45 -00:00: INF [memory_pressure] Writing meminfo: free 31MiB (31821264) / 59MiB (51.45 %)
2022-01-06 10:12:47 -00:00: INF [memory_pressure] Stat_alt meminfo: free 47MiB (48764480) / 59MiB (78.84 %)
2022-01-06 10:12:47 -00:00: INF [memory_pressure] Writing meminfo: free 31MiB (31821264) / 59MiB (51.45 %)
2022-01-06 10:12:49 -00:00: INF [memory_pressure] Stat_alt meminfo: free 46MiB (48124704) / 59MiB (77.80 %)
2022-01-06 10:12:49 -00:00: INF [memory_pressure] Writing meminfo: free 31MiB (31821264) / 59MiB (51.45 %)
2022-01-06 10:12:51 -00:00: INF [memory_pressure] Stat_alt meminfo: free 46MiB (47388880) / 59MiB (76.61 %)
2022-01-06 10:12:51 -00:00: INF [memory_pressure] Writing meminfo: free 31MiB (31821264) / 59MiB (51.45 %)

In the previous we can see that the Stat_slow (mallinfo) and the Stat_alt (alternate used memory) are almost the same, while the footprint values drops down quickly.
So far, I'm still facing an issue, at some point we overestimate the free memory (rephrase we underestimate the used memory), I must be missing an allocation in dlmalloc or counting twice some frees:
2022-01-06 10:23:19 -00:00: INF [memory_pressure] Collect
2022-01-06 10:23:19 -00:00: INF [memory_pressure] Stat_slow meminfo: free 51MiB (52978304) / 59MiB (85.65 %)
2022-01-06 10:23:19 -00:00: INF [memory_pressure] Stat_alt meminfo: free 53MiB (55400928) / 59MiB (89.57 %)
2022-01-06 10:23:19 -00:00: INF [memory_pressure] Writing meminfo: free 40MiB (40930768) / 59MiB (66.17 %)

Despite the last issue I think that this track is promising, any thought on that ?

Nice work - and sorry about the misleading PR!
I don't have a QubesOS machine any longer, but has anyone tried @hannesm's memory profiling mentioned in https://github.com/mirage/qubes-mirage-firewall/issues/120#issuecomment-718663332? That will probably show what's taking up the space.

I can also confirm that this estimate is pretty good, I have the same free memory percentage as mallinfo on the 2 decimals places (which gives an error of at most 6kB).
I could also observe a time when the fast estimate is too optimistic compared to the real free memory value, and then it comes back to a good estimation within 20 sec:
2022-01-17 09:10:14 -00:00: INF [memory_pressure] Mallinfo meminfo: free 42MiB / 59MiB (71.17 %)
2022-01-17 09:10:14 -00:00: INF [memory_pressure] Quick_stat meminfo: free 42MiB / 59MiB (71.17 %)
2022-01-17 09:10:34 -00:00: INF [memory_pressure] Mallinfo meminfo: free 43MiB / 59MiB (72.57 %)
2022-01-17 09:10:34 -00:00: INF [memory_pressure] Quick_stat meminfo: free 43MiB / 59MiB (72.57 %)
2022-01-17 09:10:51 -00:00: INF [client_eth:dom9:<IP_ADDRESS>] who-has <IP_ADDRESS>? responding with fe:ff:ff:ff:ff:ff
2022-01-17 09:10:54 -00:00: INF [memory_pressure] Mallinfo meminfo: free 43MiB / 59MiB (72.54 %)
2022-01-17 09:10:54 -00:00: INF [memory_pressure] Quick_stat meminfo: free 43MiB / 59MiB (72.54 %)
2022-01-17 09:11:14 -00:00: INF [memory_pressure] Mallinfo meminfo: free 43MiB / 59MiB (72.33 %)
2022-01-17 09:11:14 -00:00: INF [memory_pressure] Quick_stat meminfo: free 43MiB / 59MiB (72.64 %)
2022-01-17 09:11:19 -00:00: INF [client_eth:dom9:<IP_ADDRESS>] who-has <IP_ADDRESS>? responding with fe:ff:ff:ff:ff:ff
2022-01-17 09:11:34 -00:00: INF [memory_pressure] Mallinfo meminfo: free 43MiB / 59MiB (72.41 %)
2022-01-17 09:11:34 -00:00: INF [memory_pressure] Quick_stat meminfo: free 43MiB / 59MiB (72.41 %)
2022-01-17 09:11:55 -00:00: INF [memory_pressure] Mallinfo meminfo: free 43MiB / 59MiB (72.41 %)
2022-01-17 09:11:55 -00:00: INF [memory_pressure] Quick_stat meminfo: free 43MiB / 59MiB (72.41 %)

I will try to monitor this alternative quick stat function on a simpler unikernel. With that I guess I will be able to use the memstat profiler.

Update (with good news):
I modified the patch proposed by @winux138 a bit and I now have no delta between what mallinfo gives and what we have as a "quick estimate" of free memory. If anyone wants to test, they can use the following pins:
$ opam pin
mirage-xen.7.2.0     git  git+https://github.com/palainp/mirage-xen.git#malloc-usage
ocaml-solo<IP_ADDRESS>    git  git+https://github.com/palainp/ocaml-solo5.git#malloc-usage

And add the following modification into memory_pressure.ml:
 let status () =
-  let stats = Xen_os.Memory.quick_stat () in
-  if fraction_free stats > 0.1 then `Ok
+  let stats = Xen_os.Memory.memory_usage_stat () in
+  if fraction_free stats > 0.6 then `Ok
   else (
+    Log.info (fun f -> f "We need a collection");
     Gc.full_major ();
+    Xen_os.Memory.trim();
     let stats = Xen_os.Memory.quick_stat () in
-    report_mem_usage stats;
-    if fraction_free stats < 0.1 then `Memory_critical
+    if fraction_free stats < 0.1 then (
+      report_mem_usage stats; `Memory_critical
+    )
     else `Ok
   )

It probably will needs some tuning around the 60% and 10% values, but the idea behind that is that we now have the real memory used and even if we're a little bit below 60% of free memory it may be like guyere and Ocaml will have some troubles getting blocks large enough for some datas allocations.
When I tried to be too eager with the first fraction I ran into an issue where the heap goes really high (at 90+% of the heap+stack area) and triggers a page fault (#PF) trap. So I prefer to call the GC earlier and use trim to try and lower the heap boundary. After that, we can look at where the heap is, and it it's still too high, we can inform the hypervisor that we are running out of memory.
Using the same protocol as @winux138 and with this memory pressure policy change I never get down to 25% of free memory with quick_stat, and 50% of really free memory. I can see some "We need a collection" messages, but they're don't flood the logfile as previously and they stop when the network traffic drops, and more importantly I haven't had any "memory critical" messages.

This is excellent news, thanks for you hard work on it @palainp. Could you open PRs for the projecs involved? Then we can review, merge, and release :)

With mirage 4.2.0 in the pipeline, which includes @palainp @winux138 patches for ocaml-solo5 & mirage-xen, is this issue solved @palainp? It now allows us to include the trim call into the memory pressure. Could you please open a PR (or add that to #140)?


ActiveSupport::TestCase support through a rewriter

Implemented a simple rewriter to rewrite calls to methods called test, with a single positional argument (String) and a block argument. These calls are converted into a method definition using the argument as a method name and block argument as the method body.
Motivation

This rewriter is motivated by common usages of ActiveSupport::TestCase in Rails applications. As described here, ActiveSupport::TestCase provides the means to declare a test case using a block format (via ActiveSupport::Testing::Declarative). Since the block passed to the test method is called on the instance of the concrete test subclass, this was impossible to type externally.
With this rewriter we are able to expose the block to Sorbet in an instance method body and Sorbet can correctly typecheck the body. As a result there is a high chance that existing applications that were using #typed: true strictness in their ActiveSupport::TestCase test files will get new typechecking errors.
Test plan

See included automated tests.

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build result here:
→ https://go/builds/bui_IUfaW0TxX9UwMJ

@jez I see that you have approved this, but also see that you have concerns about this being available by default.
Is that the main reason why this PR has not been merged yet? If so, would it make sense to add this rewriter behind some kind of a flag so that it is not active by default?

@jez I see that you have approved this, but also see that you have concerns about this being available by default.
Is that the main reason why this PR has not been merged yet? If so, would it make sense to add this rewriter behind some kind of a flag so that it is not active by default?

Sorry, forgot about this. It was because of this:

This looks good to me, pending a test run on Stripe's codebase.

I'll kick that off now.

Sorry, forgot about this. It was because of this:

This looks good to me, pending a test run on Stripe's codebase.

I'll kick that off now.

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_ImldqFOnLTudff
→ https://go/builds/bui_ImldUQrPAqv5O8

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_ImldqFOnLTudff
→ https://go/builds/bui_ImldUQrPAqv5O8


Example capture.py doesn't work with sampling frequency less than 20kHz

Hello!
When I try to use capture.py example with frequency lower than 20 kHz it crashes:
$ python pyjoulescope_examples/bin/capture.py --frequency 10000 cap.jls
Capturing data from JS110-001783: type CTRL-C to stop
<joulescope.data_recorder.DataRecorder object at 0x7f467c0ec0d0> stream_notify() exception
Traceback (most recent call last):
  File "/home/robert/code/test/remote-js/venv/lib/python3.11/site-packages/joulescope/v1/device.py", line 430, in _stream_process_call
    rv |= bool(fn(*args, **kwargs))
               ^^^^^^^^^^^^^^^^^^^
  File "/home/robert/code/test/remote-js/venv/lib/python3.11/site-packages/joulescope/data_recorder.py", line 205, in stream_notify
    raise ValueError('stream_buffer length too small.  %s > %s' %
ValueError: stream_buffer length too small.  400000 > 300000

Python version: 3.11.4
Python modules:
$ pip freeze
certifi==2023.7.22
charset-normalizer==3.2.0
contourpy==1.1.0
cycler==0.11.0
fonttools==4.42.1
idna==3.4
joulescope==1.1.9
joulescope-server==0.1.5
kiwisolver==1.4.5
matplotlib==3.7.2
numpy==1.25.2
packaging==23.1
Pillow==10.0.0
psutil==5.9.5
pyjls==0.7.3
pyjoulescope-driver==1.3.18
pymonocypher==<IP_ADDRESS>
pyparsing==3.0.9
python-dateutil==2.8.2
requests==2.31.0
six==1.16.0
urllib3==2.0.4

JouleScope JS110 S/N 001783

Yes, this is exactly what I was trying to do.
I was not aware of this entry point
Thank you!
The issue with the example still remains though. Up to you to decide what to do about it.


[BugFix] Use IP4 localhost form for zmq bind

See https://stackoverflow.com/a/8958414
Should address issues https://github.com/vllm-project/vllm/issues/7138, https://github.com/vllm-project/vllm/issues/7118.

It looks strange to me, why @robertgshaw2-neuralmagic does not met this when he test the functionality. Is it ZMQ version specific?

It looks strange to me, why @robertgshaw2-neuralmagic does not met this when he test the functionality. Is it ZMQ version specific?

I had the same thought

I am also confused why this issue does not arise in automation or locally


fix jq theme

jq shows white for [ and {

@dickeyxxx made you collaborator.
Please merge to master following this guide.
I will then version and publish to npm.
Thanks.

Thanks, published as 0.7.1


Remove pgbackups, no longer needed by Heroku

Addresses https://github.com/city72/city-72/issues/148

Thank you!! I trust your expertise on this. I'm going to accept the pull request and then do a little test deploy (especially since it's as easy pressing a button :)
The Heroku Button has really made a significant impact on the number of people that are in the process of adopting this platform. Thanks again for contributing it!!

@arena I just did a test-deploy too, everything seems to work but let me know if you find otherwise.

@friism works like a charm. Thanks again!
On Mon, Mar 30, 2015 at 8:25 PM, Michael Friis<EMAIL_ADDRESS>wrote:

@arena https://github.com/arena I just did a test-deploy too,
everything seems to work but let me know if you find otherwise.
—
Reply to this email directly or view it on GitHub
https://github.com/city72/city-72/pull/149#issuecomment-87921051.


fixing bug introduced by separating cartesian planning into three calls

Resizing the segmented_cartesian_traj array fixes the segfault

Travis is broken because of https://github.com/davetcoleman/moveit_grasps/pull/12, merging


Day20

Resolves #49.

Pull Request Test Coverage Report for Build 119

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 118:
0.0%

Covered Lines:
24

Relevant Lines:
24

💛  - Coveralls

Pull Request Test Coverage Report for Build 121

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 118:
0.0%

Covered Lines:
24

Relevant Lines:
24

💛  - Coveralls


Fix build remove stale test

Signed-off-by: Justin Terry (VM<EMAIL_ADDRESS>

path.Unmount is now smart enough to not fail the operation if it isnt mounted and just does the directory delete. This test doesnt do anything we need.


transaction arrangment

currently, the arrangement is not proper latest transaction is shown at the bottom.
Ideally, the latest transaction should be on top.
Correct date is not showing in transaction.

will check today I have done few transaction will try tomorrow if it works fine will close. @Deveshshankar


Remember last command states.

Such as when a player uses /god, logs out, and logs back in -- they would still be in godmode on login.

Thats a task of a plugin...

Commands such as /god and /vanish are part of Rocket.
Dealing with commands from plugins is a separate issue.
Rocket should behave properly.

Properly != How you want them to behave

In this case, it is very =.

Yeah... This would also require some sort of storage backed right? To persist states between server restarts? Also @Ejraiel Rocket is a one man project so it would be @fr34kyn01535 implementing all of this... His reasoning is probably a combination of his time weighed against the usefulness of such a feature that could be done with a plug-in.

Yeah, I get all that.
Programming details aside, my main issue here is the automatic closure with no comment.
Feels very "I don't care" to receive that kind of treatment.
Even one sentence would be great; to show the thinking / reasoning, and not just toss people aside.
Thank you very much for your input here.

Hum, i really don't ;D
Customization is up to plugin developers, i am sure i gave developers all the tools they need to do do something like that ...


Why does the README.md refer to SESSION_TOKEN?

I have made this work without a SESSION_TOKEN, and per a comment in Issue 405, you don't need a SESSION_TOKEN.
Shouldn't the README  be revised to delete the reference to the SESSION_TOKEN?
Alternatively, if there is some use case where it's necessary, shouldn't the README be revised to reflect that?

This would be nice to know.


Fix limit bug, taken bug, add allday to set time command

All them shizzle don't work son
For real

Nicceee


fix(extractor): ignore lines that generate unmarshaling errors

In this PR, we handle behavior of the program if a line of the git command cannot be unmarshaled.
To reproduce, you can try this command :
env VCS_TOKEN=<TOKEN_HERE> ./src-fingerprint -v --provider repository --object "https://github.com/Linkedin/gobblin-elr"

This repo will produce an error on one given fingerprint.

Before this PR : this ends up producing an "incorrect" line in the jsonl output. With empty type, size and sha.
After this PR : the concerned fingerprint is ignored and is not part of the output anymore.

If you have ideas regarding why the error happens in the first place, this can be interesting, I did not find any obvious reason for this.

@Walz, if you happen to have an idea on the reason why the unmarshal error happens, I'd be interested ! 🙂

Also, you should be able to reproduce with this repo : https://github.com/linkedin/gobblin-elr
One line causes an error and yields an "almost empty" json line.

The error is invalid character '\x10' in string literal because the filepath is gobblin-core/src/main/java/gobblin/converter/avro/test\x10.schema
We can do something like:
for i, ch := range cleanedLine {
  switch {
    case ch < ' ':
      cleanedLine[i] = ' '
  }
}

To remove every control character from cleanedLine.  (inspired by https://groups.google.com/g/golang-nuts/c/NiQiAahnl5E/m/aBpattUxvuIJ)
I tested locally and it removes the warning.

Thanks for finding a workaround ! I think for now, we may just skip these lines rather than renaming the file.
If that's okay for you, can I merge the PR ?


chore: release 1.4.5

:robot: I have created a release *beep* *boop*
1.4.5 (2021-04-26)
Bug Fixes

release 1.4.5 (25bc19d)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/GluuFederation/cloud-native-edition/releases/tag/v1.4.5 :sunflower:


cannot find os-tmpdir is thrown from osenv.js

Error: Cannot find module 'os-tmpdir'
at Function.Module._resolveFilename (module.js:325:15)
at Function.Module._load (module.js:276:25)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object.<anonymous> (/usr/lib/node_modules/apiconnect/node_modules/apiconnect-cli-logger/node_modules/osenv/osenv.js:4:16)

I was wondering what could cause this issue?
Do you rely on NODE_PATH to set up?
or you will require node install path in the $PATH?
Looks like this issue is consistently happen when people is using NVM.
[root@kvm7rh61 ~]# apic
Error: Cannot find module 'os-homedir'
RHEL 7
[root@dpkvm7r1 ~]# apic
module.js:328
throw err;
^Error: Cannot find module 'os-tmpdir'
at Function.Module._resolveFilename (module.js:326:15)
at Function.Module._load (module.js:277:25)
at Module.require (module.js:354:17)
at require (internal/module.js:12:17)
at Object. (/root/.nvm/versions/node/v4.2.6/lib/node_modules/apiconnect/node_modules/apiconnect-cli-logger/node_modules/osenv/osenv.js:4:16)
at Module._compile (module.js:410:26)
at Object.Module._extensions..js (module.js:417:10)
at Module.load (module.js:344:32)
at Function.Module._load (module.js:301:12)
at Module.require (module.js:354:17)
at require (internal/module.js:12:17)
Thanks in advance.
It seems that setting NODE_PATH resolves the issue on some cases.

How did you come to be using this module?  os-tmpdir is listed as a dependency, so it should get installed along with osenv.
If this was included as a dep of apiconnect-cli-logger, it seems like maybe npm installed a broken tree somehow?  What does npm -v output?

This just started happening for me.
npm broke itself.
I had to downgrade because something said it did not support npm 5, so of course I googled it, this being the modern world where nothing is documented and everything relies on online help always being available and correct.
So then I did
~/react-native:$ npm install -g npm@latest-1
And that busted it. npm won't run now.

@ExtAnimal You've tried to install npm version 1.  I'm not surprised that is not going well, that version of npm is incredibly old and very much unsupported.
I recommend going to https://nodejs.org/ and installing wiht the big green button, or run curl https://www.npmjs.com/install.sh | bash to install just npm.  (You can also download and inspect the script before running it manually, if you don't like the curl|sh approach.)


use GitHub actions for linting

What does this pull request do?
use GitHub actions for linting

:grey_exclamation: Build Aborted

There is a new build on-going so the previous on-going builds have been aborted.

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-08-18T08:50:24.918+0000

Duration: 14 min 50 sec

Test stats :test_tube:

Test
Results

Failed
0

Passed
2413

Skipped
1418

Total
3831

Steps errors
Expand to view the steps failures

Show only the first 10 steps failures

Restore files previously stashed

Took 0 min 0 sec . View more details here
Description: coverage-python-3.10-aiopg-newest

Restore files previously stashed

Took 0 min 0 sec . View more details here
Description: coverage-python-3.10-asyncpg-newest

Restore files previously stashed

Took 0 min 0 sec . View more details here
Description: coverage-python-3.10-pymemcache-newest

Restore files previously stashed

Took 0 min 0 sec . View more details here
Description: coverage-python-3.10-httpx-newest

Restore files previously stashed

Took 0 min 0 sec . View more details here
Description: coverage-python-3.10-httplib2-newest

Restore files previously stashed

Took 0 min 0 sec . View more details here
Description: coverage-python-3.10-prometheus_client-newest

Restore files previously stashed

Took 0 min 0 sec . View more details here
Description: coverage-python-3.10-aiobotocore-newest

Restore files previously stashed

Took 0 min 0 sec . View more details here
Description: coverage-python-3.10-kafka-python-newest

Archive the artifacts

Took 0 min 0 sec . View more details here
Description: [2022-08-18T09:04:12.345Z] Archiving artifacts
Python-python-3.10-django-4.0 tests failed : hudson.

Error signal

Took 0 min 0 sec . View more details here
Description: Python-python-3.6-django-3.1 tests failed : org.jenkinsci.plugins.workflow.steps.FlowInterruptedException

:robot: GitHub comments
To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.

/test linters : Run the Python linters only.

/test full : Run the full matrix of tests.

/test benchmark : Run the APM Agent Python benchmarks tests.

run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

:globe_with_meridians: Coverage report

Name
Metrics % (covered/total)
Diff

Packages
100.0% (68/68)
:green_heart:

Files
100.0% (227/227)
:green_heart:

Classes
100.0% (227/227)
:green_heart:

Lines
89.751% (17444/19436)
:+1:

Conditionals
77.18% (3186/4128)
:+1:

Closed this PR, since it was much nicely done in https://github.com/elastic/apm-agent-python/pull/1658 :)


wifi-1704: Wifi6 Add missing hostapd patches for events

Added missing client and RRM events support to wifi6-hostapd
Signed-off-by: Yashvardhan<EMAIL_ADDRESS>

Merged thanks


feat: DepositFeed receive function

Description
It is convenient for users to be able to deposit funds
directly to L2 by simply doing an ETH send to an address.
The prevents needing an ABI.

Codecov Report

Merging #274 (59c32d1) into main (f7b090f) will increase coverage by 0.27%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #274      +/-   ##
==========================================
+ Coverage   55.34%   55.62%   +0.27%
==========================================
  Files          39       39
  Lines        2873     2873
==========================================
+ Hits         1590     1598       +8
+ Misses       1120     1115       -5
+ Partials      163      160       -3

Impacted Files
Coverage Δ

opnode/rollup/driver/state.go
85.89% <0.00%> (+3.20%)
:arrow_up:

opnode/bss/submitter.go
64.61% <0.00%> (+4.61%)
:arrow_up:

Continue to review full report at Codecov.

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

Stating the obvious, this will require extra processing in the rollup-driver to work.
I suppose the idea is that we'll deduct the fee from the sent amount. If the sent amount is not even enough to pay for the L2 fee, then the amount is lost (sent to sequencer?).
Is the added complexity of multiplying the ways to deposit worth the gains? There is probably going to be an SDK that makes deposits relatively easy. Even if languages without the SDK, it's "just* a contract call on L1.
Seems like the real benefit to me is the gas savings. This is basically a trustless teleportr that can be used for large amounts too.
I feel like bridging small amounts from L1 will become less and less of a concern as time goes, and we can always keep running teleportr. Not convinced it's warranted to bake this into the design, but I'm not feeling extremely strongly about it either, worth discussing!

Stating the obvious, this will require extra processing in the rollup-driver to work.
I suppose the idea is that we'll deduct the fee from the sent amount. If the sent amount is not even enough to pay for the L2 fee, then the amount is lost (sent to sequencer?).
Is the added complexity of multiplying the ways to deposit worth the gains? There is probably going to be an SDK that makes deposits relatively easy. Even if languages without the SDK, it's "just* a contract call on L1.
Seems like the real benefit to me is the gas savings. This is basically a trustless teleportr that can be used for large amounts too.
I feel like bridging small amounts from L1 will become less and less of a concern as time goes, and we can always keep running teleportr. Not convinced it's warranted to bake this into the design, but I'm not feeling extremely strongly about it either, worth discussing!

I'm ok with closing this if it adds too much complexity!

depositTransaction is called right? So it still emits the same event etc. Why would it add extra complexity in the derivation function? I think it's fine. The hardcoded gas may not be as nice though, and fee payments of deposits may also need a default.

Oooh, right. It emits the event. Thanks @protolambda for pointing out. Sorry @tynes, yeah I think this makes a lot of sense.
 It emits the event. Thanks @protolambda for pointing out. Sorry @tynes, yeah I think this makes a lot of sense.  Was thinking we could name the deposit contract, something like deposits.optimistic-ethereum.eth or something, then people could just send eth to it

you can fix the slither check with this patch:
0001-Update-slither-db.patch.txt
I think it's too finnicky, we should reduce it to a warning.

I'm going to close this for now since @maurelian has taken it over. @maurelian - please reopen when you're ready.


A problem with EncodecWrapper()

Code:
wav24k = wav24k.unsqueeze(0)
codec.eval()
codes, _, _ = codec(wav24k, return_encoded = True)
Problem:
File "preprocess.py", line 117, in process_one
codes, _, _ = codec(wav24k, return_encoded = True)
File "/home/lab-li.zhipeng/miniconda/enter/envs/ns2vc/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
return forward_call(*args, **kwargs)
File "/home/lab-li.zhipeng/miniconda/enter/envs/ns2vc/lib/python3.8/site-packages/audiolm_pytorch/encodec.py", line 103, in forward
if emb:
RuntimeError: Boolean value of Tensor with more than one value is ambiguous
How can i solve this problem? Input wav24k.shape = (1, 1, T)

i think it was introduced in https://github.com/lucidrains/audiolm-pytorch/pull/195 based on the PR we could just check is None instead of truthiness, or probably better yet just put it inside the if return_encoded conditional. Want to make a PR?

whoops, my bad for merging it too quickly, should be good!

it work correctly now?
Thanks you for your work


[docs] Update the version-2.4.1-sidebars.json file for 2.4.1 release

Motivation
Adopt new Pulsar Functions structure in 2.4.1 release.
Modifications
Refine the version-2.4.1-sidebars.json file in the versioned_sidebars folder.

run cpp tests
run integration tests

run integration tests

run integration tests


Table 3: star/emu-val vs. backtick/code

In Table 3, the distinction between star/emu-val and backtick/code is unclear. E.g., given the example of putting 'Function.prototype' in backticks, it seems like it would also be reasonable to put 'TypeError' in backticks, but we have the example of putting 'TypeError' in stars. Are they both valid, depending on context? If so, can you explain when one should use one vs. the other?

One thing that occurs to me: in the ES6 spec, most occurrences of 'TypeError' are in the context of "throw a TypeError exception" or something similar, and performing this action involves "a newly created TypeError object". Now, what this means is not entirely clear: it could mean "create an object using the constructor in the 'TypeError' property of the global object", but since that could change, I'm guessing it means "create an object using the %TypeError% intrinsic". If it were the former, then putting 'TypeError' in backtick/code would make sense, since the constructor used is the same as what you'd get if you wrote 'TypeError' in the script. But since it probably means the latter, then maybe putting 'TypeError' in star/emu-val is a way to help convey that.
(Still, it would be clearer to say "throw a %TypeError% exception", or at least add a sentence to http://www.ecma-international.org/ecma-262/6.0/#sec-throw-an-exception .)

I think the rationale for *'s is that it's not referring to the expression "TypeError" but the instrinsic TypeError object. Many of the references to X.prototype include "expression" verbage like in clause 17 (http://www.ecma-international.org/ecma-262/6.0/#sec-ecmascript-standard-built-in-objects) which definitely points towards backticks for that usage. Probably %TypeError% should also be star'd but it's unformatted currently. I agree with your proposed clarification.

I'm not sure how to clarify this in Table 3 though. Thoughts?

Closing for now as I think it's ok, but will take PRs/suggestions for better copy if someone has them later.


feat: advice bo integration frontend updates

Describe your changes
Ticket: https://pins-ds.atlassian.net/browse/ASB-2027
This PR confirms frontend advice pages work correctly with back office integration (if in feature flag: BACK_OFFICE_INTEGRATION_GET_ADVICE_CASE_REFERENCES) and regression (NI as before). It also standardises the query parameter from caseRef to caseReference.
Useful information to review or test
To test the back office integration with advice frontend locally,  use case reference BC0110001:
#index
http://localhost:9004/projects/BC0110001/s51advice

#detail
http://localhost:9004/projects/BC0110001/s51advice/1

To test regression with advice frontend locally,  use case reference TR040009:
# index
http://localhost:9004/projects/TR040009/s51advice

# detail
http://localhost:9004/projects/TR040009/s51advice/TR040009-Advice-00009

Type of change 🧩

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update
[ ] Other (please explain in the description section above)

Checklist before requesting a review

[x] I have performed a self-review of my own code
[x] I have double checked this work does not include any hardcoded secrets or passwords
[x] I have made corresponding changes to the documentation
[x] I have provided details on how I have tested my code
[x] I have referenced the ticket number above
[x] I have provided a description of the ticket
[x] I have included unit tests to cover any testable code changes

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

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


Fix for kubelet startup on nodes when using TLS bootstrapping

Always write a kubeconfig file - even when using the TLS bootstrapping feature
Failure to specify a kubeconfig file will result in a failed startup and cryptic "file not found" error message on the kubelet.

Codecov Report

Merging #1522 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1522   +/-   ##
=======================================
  Coverage   25.46%   25.46%
=======================================
  Files          97       97
  Lines        5003     5003
=======================================
  Hits         1274     1274
  Misses       3582     3582
  Partials      147      147

Continue to review full report at Codecov.

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


SASS-6056: Update remuneration url

Description
Update remuneration url on tax avoidance page and a fix in messages.
Checklist PR Raiser
Note: This is just not a tick box, make sure you follow all the below steps
Before creating PR

[ ]  Have you run the tests?
[ ]  Have you run the it tests?
[ ]  Have you run the journey tests? (where applicable)
[ ]  Have you addressed warnings where appropriate?
[ ]  Have you rebased against the current version of main?
[ ]  Have you checked code coverage isn’t lower than previously?
[ ]  Have you done the group review in the team?

After PRs been raised

[ ]  Have you checked the PR Builder passes?

Checklist PR Reviewer
Before Reviewing

[ ]  Have you pulled the branch down?
[ ]  Have you assigned yourself to the PR?
[ ]  Have you moved the task to “in review” on JIRA?
[ ]  Have you checked to ensure all dependencies are up to date?
[ ]  Have you checked to ensure its been rebased against the current version of main?

Whilst Reviewing

[ ]  Have you run the tests?
[ ]  Have you run the it tests?
[ ]  Have you run the journey tests?
[ ]  Have you looked at the JIRA story to make sure all Acceptance Criteria has been met?
[ ]  Have you checked for individual and agent content matching with the prototype? (where applicable)
[ ]  Have you checked for welsh transaltion for individual and agent? (where applicable)
[ ]  Have you checked for errors messages for individual and agent on both english and welsh? (where applicable)
[ ]  Run wave (chrome extension) for accessibility (where applicable)

After Reviewing

[ ]  Have you checked for merge conflicts or any changes in the current main that may affect the current pull request? i.e. does it need another rebase?
[ ]  Have you checked to make sure there are no builds in the pipeline before you merge?
[ ]  Have you moved the task to “in pipeline” on Jira?
[ ]  Demo to Business Analyst

These changes have been included in another pr relating to updating the messages.


NPC Indicator ghosting between sessions

NPC Indicator seems to remember highlights across sessions. (login/logout)
Describe the bug

Have your settings to highlight any NPC visible
Log out and log back in
The NPC will keep moving, but a new ghost of the NPC will appear in a offset location.

Expected behavior
No ghosting of NPC indicators are intended
Screenshots
In these screenshots I logged in and out of one account without moving,
and logged back in on second account.

Game after several re-logs:

Environment

OS: Windows
RuneLite version: 1.7.23
Launcher version: 2.1.7

fixed in 3c5f8123313b5f52027b5b2bd32f6c6c0d49dea1

Can't reproduce, but want to bring awareness to the bug still being present.
Think it may have been caused when returning from a random event? (Flippa's pinball random event)
Sorry for incomplete reproduction guide, first occurrence since runelite updated.


added episode.py

I added episode.py that includes the command "/episode".
"/episode" crawls einundzwanzig.space for the latest podcast episodes and returns the URL. The podcast format can be specified by adding following arguments: "alle", "interview", "lesestunde", "news" or "weg". If no arguments are used, "/episode" will return the lastest episode of all format.

added timeout and error handling for requests.get. If the request fails for some reason, users will get notified and receive a link to EINUNDZWANZIG Spotify instead.
removed root URL from variables and moved it to config file
fixed typo in bot.py (synch/sync)
updated requirements.txt

I did test the original commit with my own bot, but in a "single file" environment with out Docker etc.

I've added two more commits with some style changes. Let me know what you think.

Thanks for cleaning up! f-strings and using variables in strings were new concepts for me (as you might have noticed...). I also removed the root URL from the argument passed to the function and included it in getEpisode.


Bump dependencies to patch security advisories

Security Advisories fixed:
golang.org/x/text v0.3.7
IDs:  GO-2021-0113
Links:
https://osv.dev/vulnerability/GO-2021-0113

This doesn't removes the affected version from go.sum so I guess scanners will report this nevertheless.

Go uses  MVS to find the minimum required version. So this change will ensure it will only consider v0.3.7+, and should also reflect scanners.
Example of similar change on kubebuilder:
Before: https://deps.dev/go/sigs.k8s.io%2Fkubebuilder%2Fv3/v3.0.0-alpha.0.0.20211203185037-c869ec1a0c7c
After: https://deps.dev/go/sigs.k8s.io%2Fkubebuilder%2Fv3/v3.0.0-alpha.0.0.20211205153232-0036a354829c
For more in-depth discussion:
https://github.com/kubernetes-sigs/kubebuilder/pull/2438#issuecomment-985310736


Simplified upload and download Functions

Why can't you just write:
binary = download("s3://wow/omg/amazing") # or even dl("...")

Instead you have to write:
binary = CloudFiles("s3://wow/omg/").get("amazing")

Released dl(...) in version 1.20.0


"Lopătari" is listed in the drop-down menu

Description:
"Lopătari" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Lopătari" in the search bar.

Expected results
The location is listed in the drop-down menu as "Comuna Lopătari, BUZĂU".


RFC: Run the Node service in trinity's main process

How many times have you wished you could stick some pdb.set_trace() calls in the chain-syncer code
to debug a trinity run? This is something that always frustrated me, but the fact that we run the
chain syncer in a sub process meant it was not easy (if possible at all?) to do so.
Well, it recently ocurred to me that trinity's main process is actually not doing much work and
if we run the Node service in the main process it will be much easier to debug and we'd significantly
reduce the amount of IPC calls we make (since we'd no longer use the queued logger there).
How would you guys feel about such a change? Am I overlooking something? Is there anything else that
warrants running the Node service in a separate process?

I have no objections that come to mind. :+1:

@cburgdorf how should I go about combining the two plugin_managers that would now live in the main process?

So, one thing that comes to my mind is that currently the central event bus is running in the main process which was convenient to begin with because:

the main process naturally holds handles to each other process to stick Endpoints in
As @gsalgado it doesn't do much which is perfect for the event bus because it really just runs an event loop to pass messages on to other processes.

This would change quite a bit when the node itself runs in the main process. I noticed that the syncing process can block quite a lot which would in turn slow down message passing to all other processes.
However, I'd actually love to have the central event bus (that piece that creates endpoints for each other process) to live in its own process so that we never have to worry about anything blocking it and slowing message delegation down. I'm just not sure how that would look like yet.
So, in general, no objections we just should make sure to figure out how to deal with that.
Also, I'd hope we could get #1212 merged in before this.

how should I go about combining the two plugin_managers that would now live in the main process?

I guess we need to redesign the things around the process scopes a bit. We would basically go from our current 3 different scopes to just 2. https://github.com/ethereum/py-evm/blob/master/trinity/extensibility/plugin.py#L51-L62

@cburgdorf Any idea what is causing trinity to hang after the main() process has successfully killed the DB subprocess and returned? As shown below, after I hit Ctrl+C, trinity.main() returns, but it hangs there until I Ctrl+C again, at which point I get those errors from lahja
    INFO  09-13 17:33:38     service  Starting fast-sync; current head: #35668
^C    INFO  09-13 17:33:40      server  Closing server...
    INFO  09-13 17:33:45     service  Timed out waiting for <trinity.nodes.mainnet.MainnetFullNode object at 0x7fec9d55bc18> to finish its cleanup, forcibly cancelling pending tasks and exiting anyway
    INFO  09-13 17:33:46        main  Keyboard Interrupt: Stopping
    INFO  09-13 17:33:46         ipc  Sent SIGINT to process 8960, waiting 10 seconds for it to terminate
    INFO  09-13 17:33:46         ipc  Process 8960 has already terminated
    INFO  09-13 17:33:46        main  DB server process (pid=8960) terminated
    INFO  09-13 17:33:46        main  Reached the end of trinity.main()
^CException ignored in: <module 'threading' from '/usr/lib/python3.6/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.6/threading.py", line 1294, in _shutdown
    t.join()
  File "/usr/lib/python3.6/threading.py", line 1056, in join
    self._wait_for_tstate_lock()
  File "/usr/lib/python3.6/threading.py", line 1072, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt
Task was destroyed but it is pending!
task: <Task pending coro=<Endpoint._try_connect() running at /home/salgado/virtualenvs/pyevm/lib/python3.6/site-packages/lahja/endpoint.py:70> wait_for=<Task pending coro=<Endpoint._connect() running at /home/salgado/virtualenvs/pyevm/lib/python3.6/site-packages/lahja/endpoint.py:78> wait_for=<Future pending cb=[_chain_future.<locals>._call_check_cancel() at /usr/lib/python3.6/asyncio/futures.py:403, <TaskWakeupMethWrapper object at 0x7fec97d350d8>()]> cb=[<TaskWakeupMethWrapper object at 0x7fec97d79738>()]>>
Task was destroyed but it is pending!
task: <Task pending coro=<EventBus._start() running at /home/salgado/virtualenvs/pyevm/lib/python3.6/site-packages/lahja/eventbus.py:59> wait_for=<Future pending cb=[_chain_future.<locals>._call_check_cancel() at /usr/lib/python3.6/asyncio/futures.py:403, <TaskWakeupMethWrapper object at 0x7fec97d798b8>()]>>
Task was destroyed but it is pending!
task: <Task pending coro=<Endpoint._connect() running at /home/salgado/virtualenvs/pyevm/lib/python3.6/site-packages/lahja/endpoint.py:78> wait_for=<Future pending cb=[_chain_future.<locals>._call_check_cancel() at /usr/lib/python3.6/asyncio/futures.py:403, <TaskWakeupMethWrapper object at 0x7fec97d350d8>()]> cb=[<TaskWakeupMethWrapper object at 0x7fec97d79738>()]>

As @pipermerriam pointed out, both https://pypi.org/project/rpdb/#description and https://pypi.org/project/remote-pdb/#description should allow us to interactively debug any trinity subprocess, so I'm no longer sure it's worth pursuing this, although it'd certainly simplify trinity.main() a bit

@gsalgado I'm now inclined to close if you think you can get what you want from those libraries.  I do like the main process being simple and would like to keep that if possible, though my reasons are thin (just liking the simplicity of the main process doing so little).

Any idea what is causing trinity to hang after the main() process has successfully killed the DB subprocess and returned

I think that is partly because of a bug in lahja that is already fixed in a newer version and coming with this commit.
However, I also have a slight preference of keeping the main process as is mostly because:

the current event bus topology benefits from a (mostly) idle main process
we will continue to refactor things out into isolated plugins that spawn their own processes (e.g. #1212 moves the JSON-RPC Server but I guess things like the transaction pool will follow)
that previous point basically means that having a better way of debugging other processes still seems like something we would benefit more from


Fix date calculation bug in MonthCalendarSelection example

The date manipulation being performed in these samples was incorrect, and would throw ArgumentOutOfRangeException in cases such as when the date was the first day of any month (because today.Day - 1 would be 0, which is invalid for the DateTime constructor).
The change corrects this by using AddMonths and AddDays methods.
Aside - it's unclear to me why SelectionStart and SelectionEnd need to be reduced by one day.  The docs don't spell that out, but the original samples did this and I needed to keep an AddDays(-1) to retain the same effect on the control.  Perhaps something here is 0-based instead of 1-based?

Thanks @mj1856 for fixing it.


CI | Update with GitHub Action from Ember 4.1

Using GitHub Actions template generated by<EMAIL_ADDRESS>👉 Using standard things
👉 Testing Ember 4

Waiting for some feedback here https://github.com/configcat/common-js/issues/42 in order to be able to make the tests pass


Could not continue execute other cases after failure case

I write API test base on the guild runn Grpc server
I have 2 test files:

login_test.yml (multiple case):

desc: Login
vars:
  request:
    - "001-Success-request.json"
    - "002-IncorrectPassword-request.json"
    - "003-IncorrectUsername-request.json"
  response:
    - "001-Success-response.json"
    - "002-IncorrectPassword-response.json"
    - "003-IncorrectUsername-response.json"
steps:
  - loop:
      count: len(vars.request)
    include:
      path: requestBase.yml
      vars:
        request: "json://../test-data/login/{{ vars.request[i] }}"
        response: "json://../test-data/login/{{ vars.response[i] }}"
        testPath: "/login"
        testCase: "Login { vars.request[i] }}"

logout_test.yml (multiple case)

1 requestBase.yml file as below:
runners:
  greq:
    addr: ${BASE_GRPC_URL}
    tls: false
    protos:
      - ../../../*.proto
steps:
  - greq:
      "{{ vars.testPath }}":
        headers:
          test-case: "{{ vars.testCase }}"
        message: "{{ vars.request }}"
    test: compare(current.res.message, vars.response)

main_test.go
func TestAPI(t *testing.T) {
	flag.Parse() // Parse the flags

	err := godotenv.Load(".env")
	if err != nil {
		log.Fatal("Error loading .env file")
	}

	opts := []runn.Option{
		runn.T(t),
		runn.Debug(true),
	}

	runner, err := runn.Load(
		*testPath,
		opts...,
	)

	if err != nil {
		t.Error(err)
	}

	ctx := context.TODO()

	if err := runner.RunN(ctx); err != nil {
		t.Log(err)
	}
}

When I run all test.
When case 001 login success, case 002 login failure. It stop (do not run case 003 login, although logout_test still run)
I change: t.Fatal(err) -> t.Error(err)
purpose continue execute other case if in test_file.yml has failure case.
But it does not work. It still stop.
Could you share idea or something wrong here? Thank you very much!

Hi @k1LoW ,
Thanks for quickly response.
Currently, in the login_test scenario has 3 cases.
Expected: when case 002 failure then case 003 continue execute.
Actual: when case 002 failure then all case remaining of login_test do not execute.
I think cause by: t.Fatal() stop it.
So I change t.Fatal() to t.Error() to avoid that but it doesn't seem to work.
Forgive my ignorance on this matter. 🙇♂

Currently, in the login_test scenario has 3 cases.

In runn, these are only steps, which must be consecutive and successful.
If you want them to be test cases, you need to separate the runbook.
There is an option called force:, but again this is only for forcing all the steps to run, and it does not take into account the cases you mention.

Can you provide an example requestBase for a multi-instance runbook
Suppose you are looping 3 cases in turn
Then when the 2nd case reports: test failed on "Generated by runn new".steps[0]: condition is not true
We will continue to run the third case
If I misunderstand something, please let me know 🙇

Separate login_test.yml into three separate files ( not loop ).

Thanks for support @k1LoW .
I got it!
When any step failure => The scenario will be failure.
So we should split scenarios into sperate files.


Support borrowed types such as &str or slice

Right now this thing handles types with Arbitrary trait implemented, such as String or Vec. It cannot correctly react to functions accepting &str as parameter, because there is no Arbitrary trait implementation for those types.

In fact, closed by putting borrowed values into Boxes.


Update advancedbackups-readme.txt

I gave it a shot, feel free to close this PR if you don't think it's better :)

That's definitely better than what I had haha

Run the script found in the /backups folder

Personally, I'd remove the / here - doing that would be inconsequential in default configs, and make more sense if someone changes their backups directory? Otherwise, I'm more than happy to merge

There we go 👍

All happy with that. Merging


About unittest_db

Hello, could you tell me where I can find file unittest_db?

Hi! We are uploading all the data one by one here,
https://huggingface.co/datasets/NTU-NLP-sg/xCodeEval
We almost uploaded all the data. There are still a few files that need to be uploaded after ensuring they match the checksum and some internal checks.
We are scheduled to upload the full data with all internal checks within two more days. Please follow https://github.com/ntunlp/xCodeEval for any data-related issues.
We aim to discuss about eval benchmark related issues here.

Just to give you a heads-up, all data has been uploaded.
Please open the issue if you have any more queries.


Jquery UI autocomplete and Bootstrap select Bug

Hello,
when using jquery ui and bootstrap-select together, I get following error on my page:
Uncaught TypeError: Cannot read property 'apply' of null$.fn.val @ bootstrap-select.self-16a81c2….js?body=1:137_value @ autocomplete.self-3befc48….js?body=1:577(anonymous function) @ widget.self-c160224….js?body=1:116(anonymous function) @ autocomplete.self-3befc48….js?body=1:407handlerProxy @ widget.self-c160224….js?body=1:461
bootstrap-select.self-16a81c2….js?body=1:137 Uncaught TypeError: Cannot read property 'apply' of null$.fn.val @ bootstrap-select.self-16a81c2….js?body=1:137_value @ autocomplete.self-3befc48….js?body=1:577(anonymous function) @ widget.self-c160224….js?body=1:116_change @ autocomplete.self-3befc48….js?body=1:487(anonymous function) @ widget.self-c160224….js?body=1:116blur @ autocomplete.self-3befc48….js?body=1:205handlerProxy @ widget.self-c160224….js?body=1:427dispatch @ jquery.self-bd7ddd3….js?body=1:5227elemData.handle @ jquery.self-bd7ddd3….js?body=1:4879

// set data-selected on options that are programmatically selected
// prior to initialization of bootstrap-select
var _val = $.fn.val;
$.fn.val = function(value){
  if (this.is('select') && value) {
    this.find('option[value="' + value + '"]').data('selected', true);
  }

  return _val.apply(this, arguments);
};

Does anyone know the reason?

This has been fixed in the latest master. In the future, see guidelines for contributing.

Bug reports
A bug is a demonstrable problem that is caused by the code in the repository.
Good bug reports are extremely helpful - thank you!
Guidelines for bug reports:

Use the GitHub issue search. Check if the issue has already been reported.

Check if the issue has been fixed. Try to reproduce it using the latest master or development branch in the repository.

Provide environment details. Provide your operating system, browser(s), jQuery version, Bootstrap version, and bootstrap-select version.

Create an isolated and reproducible test case. Create a reduced test case.

Include a live example. Make use of jsFiddle or jsBin to share your isolated test cases.


Ternary operator to not trim undefined address or phone number

Was seeing error when fetching zipcode: 75201
TypeError: Cannot call method 'trim' of undefined

Thanks for the fix. Merged it into master, but there are some failing tests. I'll see if I can get those fixed this evening, and then package up a 0.4.0 release.

Noticed the failure, it seems that continuing with some undefined fields causes problems further down.  I'll see if there is anything I can clean up as well.

Made a ticket for the failing unit tests.  #9


New package: Sigstore.Cosign version 2.3.0

Pull request has been created with komac v2.3.0 :rocket:
Resolves: https://github.com/microsoft/winget-pkgs/issues/165441
Microsoft Reviewers: Open in CodeFlow

Verify:


fix(vite): use h3 cors handler for vite routes only

🔗 Linked issue
resolves https://github.com/nuxt/nuxt/issues/22512
resolves https://github.com/nuxt/nuxt/issues/23962
❓ Type of change

[ ] 📖 Documentation (updates to the documentation or readme)
[x] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
This turns off vite's cors handler (https://github.com/expressjs/cors) by default, in preference to using h3's handler only for routes to be transformed by vite. This should enable us to avoid CORS headers on Nuxt/Nitro endpoints that aren't handled by vite.
If the user configures vite.server.cors then this is respected.
📝 Checklist

[x] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

This is good imo for the fix but also we could find a way to disable vite cors overrides entirely allow both consistent behavior when h3 util / route rule used (route rule is normalized to cors headers not using utility) and also user custom behavior

I think that is what this fix does. It does disable vite cors header handler entirely. But maybe I'm misunderstanding you?

Indeed it does disable vite feature and directly adds OPTIONS handler via a nuxt default behavior. What i meant was to avoid this too, in next steps iterating with nitro.

Ah, I see. But Nuxt only does this for routes that are handled by vite, leaving normal nitro routes unhandled.


[Rx -> Coroutine Migration] : Incrementally migrate some methods in local datastore to corountine

Towards #1581

@JSunde @gino-m  PTAL?

/gcbrun

/gcbrun


Windows Terminal to have folder management to manage sessions please

Description of the new feature/enhancement
Would like to see Windows Terminal to have folder management feature. I have lots of sessions that folder management is necessary for me to organize them.
Thank you.

I'm sorry, could you elaborate more? I'm not exactly sure what you're asking for.
Maybe you're thinking of something like what's described in this: https://github.com/microsoft/terminal/issues/1571#issuecomment-519504048 ?

Hello team,
First of all, let me congratulate you for this amazing product.
I face the same issue, so may i can explain.
Currently, we can store remote ssh session using profil customisation.
For exemple:
...
],
"SSH": [
{
"name": "SSH Jenkins Scaleway",
"commandline": "ssh -L 44400:localhost:44400<EMAIL_ADDRESS>"hidden": false,
"backgroundImage": "ms-appdata:///roaming/fond_term3.gif",
"backgroundImageOpacity": 0.8,
"backgroundImageStrechMode": "fill"
}
],
...
However, because of number of session we could face, it isrequired to organize it using sub-menu of sub-folder.
This new fetaure would be great.
Best regards,

/dup #1571

Good find! Thanks for following up 😄
/dup #1571


Undocumented options in '--help' for 'sam package'

Description
The sam package command doesn't document the --output-template-file in the options list. It does use it in the example, but them leaves it out of the documented options.
Also suggest it should document the --s3-prefix option.
Steps to reproduce
sam package --help
Observed result
Usage: sam package [OPTIONS] [ARGS]...

  The SAM package command creates a zip of your code and dependencies and
  uploads it to S3. The command returns a copy of your template, replacing
  references to local artifacts with the S3 location where the command
  uploaded the artifacts.

  e.g. sam package --template-file template.yaml  --output-template-file packaged.yaml
  --s3-bucket REPLACE_THIS_WITH_YOUR_S3_BUCKET_NAME

  This is an alias for aws cloudformation package. To learn about other parameters you can use,
  run aws cloudformation package help.

Options:
  --template-file PATH  The path where your AWS SAM template is located
  --s3-bucket TEXT      The name of the S3 bucket where this command uploads
                        the artifacts that are referenced in your template.
                        [required]
  --debug               Turn on debug logging to print debug message generated
                        by SAM CLI.
  --help                Show this message and exit.

Expected result
Expected --output-template-file option to be documented under 'Options'. And suggest the --s3-prefix option should be there too.
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

OS: Windows 10
sam --version: SAM CLI, version 0.18.0

Aside from the fact that the documentation is missing the text on --output-template-file under OPTIONS does  sam-cli honor if the flag is passed ?

Yes @amieka the options work fine if passed. Just that this and some other highly useful options aren't documented, so you can only find out about them through other people's examples or some reverse engineering.

This will be addressed with #1437.
sam package shells out to aws cloudformation package in AWS CLI. Any option your installed AWS CLI version supports is supported by sam package. Which is also mentioned in the help text: "This is an alias for aws cloudformation package. To learn about other parameters you can use,
run aws cloudformation package help."

This is an alias for aws cloudformation package. To learn about other parameters you can use,
run aws cloudformation package help.

Good point @jfuss, didn't even see that; my eye steers straight to the Options: heading and ignored the intro 😄  My fault, but it maybe worth moving that sentence at the end of 'Options' rather than in the intro.

We have recently removed our reliance on aws cli for sam package. Starting in v0.31.0, all options are present in the help text. We are still working through deploy.
Given this issue is about package, I am going to close this one.