Core dumps when executing TRSM call with latest GCC (gcc12)

While doing some regression testing on the new GCC12 compiler (built from trunk), we discovered core dumps when executing TRSM calls.
These core dumps occur both in our power-optimized TRSM code and in the generic TRSM code.
We determined that they are caused by array address offsets being computed incorrectly as negative values.
We found that if we modify the code to ensure that all computations of pointer addresses into the A array are done using exclusively "long int" variables (no mixing "int" and "long int"), and if we also slow down the computations with an if-test containing a conditional print statement, then the problem goes away.
We do NOT advocate such a modification as a patch or a workaround.
We view it as evidence that there might be a compiler bug involved, particularly because it only happens with this new, not-yet-released compiler.
We solicit your thoughts on the matter.

For completeness, here's a "git diff" showing the changes we made to eight files
(the LN, LT, RN and RT files for generic TRSM and for power-optimized TRSM):
diff_file.txt

So you just changed one type to BLASLONG and added some casts? Similar code is about everywhere, though BLASLONG style in most places.
Does it fails same way with release trains i.e 11.1 and/or 10.3 ?

I'd think the conditional printf is preventing some over-zealous optimization - but if this only happens with a development snapshot that must be early stage1 at best, I would prefer to ignore it at this time (i.e. defer to the gcc team).

This should wait until mis-compilation gets into stable branches, or hopefully not.

Err, "gets into stable branches" may be a bit late for this, but there will surely be a stage3 in about five months where it might make more sense to check for this again. At least I see nothing obviously wrong with the current TRSM code (and nor did any of the other compilers in use on various platforms) - going from int to long may be sensible in the future but I do not think this is directly related to the miscalculation or overflow of the offsets.

Maybe it is a 32/64 confusion in some other place, that it gets unitialized upper half somehow by means of wild optimisations and chokes. It has to be checked if at all against same gcc with lower optimisation levels, not here.

We have NEWS:
After opening a GCC Bugzilla issue, we were quickly notified of a suspicious commit that might have been the problem in GCC12.  My colleague Peter Bergner quickly created a compile with that commit removed, and the problem indeed goes away entirely.  Definitely a GCC problem, and definitely identified to be part of a bad commit.
We will leave this issue OPEN until we have a GCC12 which runs OpenBLAS cleanly, and then we will close this issue.

And, even better NEWS:
We had a fix for this problem that has already been uploaded to GCC12, but Peter Bergner was unaware of it!
This problem no longer occurs in GCC12, and I'm closing this issue now.


fix (most) biocCheck issues

Travis is failing due on bioconductor devel, but otherwise good to go. related to #313


simple state machine with an action client and a topic subscriber

state machine has two states
one state transitions to another state based on the data received on a topic
one of the states contains an action client which sends a goal to /fibonacci action server. The implementation of action server is provided as part of ROS2 tutorials.

┆Issue is synchronized with this Jira Task by Unito

Hi Sukhraj, I had a look to the build, and I have two requests...

Can we add the standard apache2 license for these files...
smacc2_sm_reference_library/simple_action_client_example/include/simple_action_client_example/mode_selection_client/cl_mode_select.hpp: could not find copyright notice
smacc2_sm_reference_library/simple_action_client_example/include/simple_action_client_example/orthogonals/or_mode_select.hpp: could not find copyright notice
2 errors, checked 377 files
smacc2_sm_reference_library/simple_action_client_example/include/simple_action_client_example/orthogonals/or_fibonacci.hpp: could not find copyright notice
1 errors, checked 341 files
smacc2_sm_reference_library/simple_action_client_example/include/simple_action_client_example/mode_selection_client/client_behaviors/cb_mode_select.hpp: could not find copyright notice

And can you rename the state machine to sm_simple_action_client (for files) /SmSimpleActionClient (for class) to keep with the naming convention of the reference library please?

I'm tempted to just squash the PR and just do it myself, but I'm trying to follow the CI process here;)
Thank you, I really appreciate it. I'm excited to get this PR merged.

// Copyright 2021 RobosoftAI Inc.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
/*****************************************************************************************************************
*

Authors: Sukhraj Klair

******************************************************************************************************************/

Hi @sukhrajklair, lets try running the pre-commit run -a command on your local machine please and then pushing. I think it will pass the format check after that.

Hi @brettpac
Looks like all of the formatting errors are fixed


Prevent repeated OtherBranch name suffixes being appended

fix an issue wherein certain plugin execution orders could lead to the other branch suffix being applied to a version repeatedly +normalized-branch-name+normalized-branch-name-SNAPSHOT
This is associated with issue #105

Pull Request Test Coverage Report for Build 428

3 of 4 (75.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 72.378%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/main/java/com/e_gineering/maven/gitflowhelper/OtherBranchVersionExtension.java
3
4
75.0%

Totals

Change from base Build 423:
-0.02%

Covered Lines:
621

Relevant Lines:
858

💛  - Coveralls

Nice catch @rdefreitas ! I noticed this happening once, but failed to reproduce it. I have included it into my outstanding PR #120 as well.


Having node: prefix panicked at JSR version 0.41.0

input
// main.ts

import { argv } from 'node:process';

console.log(argv.slice(2));

// build.ts

import { build, emptyDir } from "@deno/dnt";

await emptyDir("./npm");

await build({
  entryPoints: ["./main.ts"],
  outDir: "./npm",
  shims: {
    deno: "dev",
  },
  package: {
    name: "your-package",
    version: "0.1.0"
  },
});

error
panicked at wasm\src\lib.rs:24:1:
unexpected exception: JsValue(TypeError: Unsupported scheme "node:" for module "node:process". Supported schemes: ["data:","blob:","file:","http:","https:"].
TypeError: Unsupported scheme "node:" for module "node:process". Supported schemes: ["data:","blob:","file:","http:","https:"].
    at getValidatedScheme (https://jsr.io/@deno/cache-dir/0.8.0/file_fetcher.ts:59:11)
    at FileFetcher.fetch (https://jsr.io/@deno/cache-dir/0.8.0/file_fetcher.ts:288:20)
    at FetchCacher.load (https://jsr.io/@deno/cache-dir/0.8.0/cache.ts:24:30)
    at fetch_specifier (https://jsr.io/@deno/dnt/0.41.0/lib/pkg/snippets/dnt-wasm-a15ef721fa5290c5/helpers.js:6:22)
    at __wbg_fetchspecifier_a6bda29173284144 (https://jsr.io/@deno/dnt/0.41.0/lib/pkg/dnt_wasm.generated.js:336:21)

Probalby due to https://github.com/denoland/dnt/pull/379


Add support for the GARDENA smart garden radio module type 1, which i…

…s used on all GARDENA gateways

This was for Meetup (https://www.meetup.com/de-DE/embedded-software/events/302424246/) purposes only.


Update default version in composer require command

Coverage remained the same at 66.825% when pulling e6fd1c8a5bb0e0609adb6dba068e911a32be37f0 on geerlingguy:patch-1 into 24c64a8f6aeb63f439fd0680985e85aaab5a61dd on hirak:master.


Add framer-motion extension

Description
Adding an extension to link to Framer Motion docs (https://www.framer.com/motion/) and a glossary of the utilities available to copy directly.
Screencast
https://github.com/raycast/extensions/assets/12908185/e7ae6498-33e5-45a4-a79b-15e65c1b5638
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

@samuelkraft thanks for the review 🙌
I'll try to get these changes pushed in.


[DRAFT] ROS2: ff_common

This one also was rather easy to port. There was a nodelet dependency but this package didn't seem to contain any managed nodelets and seemed to be just a library.

Issue: The symlinks for the includes are broken in the install folder.

@marinagmoreira this builds correctly, we can merge it :)


Can't set expiration time permissions

Maby this is a bug:
https://stackoverflow.com/questions/42986256/google-drive-sdk-can-not-set-expiration-time-permissions

I am able to replicate the same issue you described. I debugged through the code and I didn't see anything stand out. If I have time this week, I'll try to directly hit the api using Postman to see if I get different results.

@kevinkhuat
Okay great :)

@J05HI
I was able to hit the api directly using Postman, and I was not able to add an expiration time. I didn't see an option to set an expirationTime when creating a new permission. I did see one for updating one
https://developers.google.com/drive/v3/reference/permissions/update
I tried making a request to update the permission, but I got this message:
{  "error": {   "errors": [    {     "domain": "global",     "reason": "cannotSetExpiration",     "message": "Expiration dates cannot be set on this item."    }   ],   "code": 403,   "message": "Expiration dates cannot be set on this item."  } }
I'm not too sure why the permission can't be set.

@kevinkhuat
Thanks for your effort! Maybe a bug.
A Google guy should look at this

@bshaffer
Noone would like to fix this?

Duplicate of #36760655, #36761485

Thanks!
I hope it'll be fixed soon :)

I suddenly started receiving this error, in an already working solution yesterday, can you guys check if you made any regression or something? the error appear when setting an expiration date on a pdf file. (this worked fine until yesterday)
Return message:
{
"error": {
"errors": [
{
"domain": "global",
"reason": "cannotSetExpiration",
"message": "Expiration dates cannot be set on this item."
}
],
"code": 403,
"message": "Expiration dates cannot be set on this item."
}
}


HB crashes after trying to update the Firmware of IKEA Lightbulbs via Web UI

HI,
As the title says... HB is always crashing, when i try to Update the firmware via the "Update Now" Button in the Zigbee WebUI.
I am on homebridge-zigbee-nt v2.5.10...
Any Hints/Ideas? @madchicken
[Sun Jul 31 2022] [ZigBee-UI] Request: http://192.168.x.y:9000/api/devices/0xd0cf5efffec7zzzz/checkForUpdates
[Sun Jul 31 2022] [ZigBee-UI] Request: http://192.168.x.y:9000/api/devices/0xd0cf5efffec7zzzz
[31.7.2022, 17:20:06] [ZigBee] Bind 0xd0cf5efffe091111/1 genPowerCfg from '0x00124b000be95bbbb/1' failed (AREQ - ZDO - bindRsp after 10000ms)
[Sun Jul 31 2022] [ZigBee-UI] Request: http://192.168.x.y:9000/api/devices/0xd0cf5efffec7zzzz/updateFirmware
[31.7.2022, 17:21:01] Error: Bind 0xd0cf5efffe091111/1 genPowerCfg from '0x00124b000be95bbbb/1' failed (AREQ - ZDO - bindRsp after 10000ms)
at Timeout._onTimeout (/usr/lib/node_modules/homebridge-zigbee-nt/node_modules/zigbee-herdsman/src/utils/waitress.ts:64:35)
at listOnTimeout (node:internal/timers:559:17)
at processTimers (node:internal/timers:502:7)
[31.7.2022, 17:21:01] Got SIGTERM, shutting down Homebridge...
[31.7.2022, 17:21:01] [ZigBee] Stopping zigbee service
[31.7.2022, 17:21:01] [ZigBee] Zigbee: disabling joining new devices.
[31.7.2022, 17:21:01] Got SIGTERM, shutting down child bridge process...
[31.7.2022, 17:21:01] Got SIGTERM, shutting down child bridge process...
[31.7.2022, 17:21:02] [ZigBee] Stopping http server
[31.7.2022, 17:21:06] [HB Supervisor] Homebridge Process Ended. Code: 143, Signal: null
[31.7.2022, 17:21:11] [HB Supervisor] Restarting Homebridge...
[31.7.2022, 17:21:11] [HB Supervisor] Started Homebridge v1.5.0 with PID: 6082

Could you try to reboot the whole system? It seems something related to the dongle...

It is a CC2531 Dongle...

This is probably the reason 😞


upgrade developers.md

fixes #747
Some of the conventions are a little out of date. I've updated what I thought was important.

typos fixed

ok, I really need to get to the bottom of that one

might be sufficient to start vendoring in go 1.5

lol that's the muxado error. This one was the renter error


Bugs with the interface when clearing MultiSpinBox, and LabelItem objects

Spin boxes inside MultiSpinBox objects are not properly removed, causing it to have multiple spin boxes that should have been removed when clearing the grid layout.
For the labels manager, removing the "edit layer" from napari viewer would reset some variables to None. That causes to lose track of the current active LabelItem object.

Solved with PR #10


nodejs prefix & embed npmrc

Because it's easier to manage permissions when everything that is supposed to be owned by the server process is in the same place. Because the nodejs installation doesn't have any clear requirement to be where it is, figured it could be moved to the etc dir.
Also embedded an npmrc to be picked up by the installed nodejs. There isn't any example to override the npmrc to be embedded during the build process, but that's exactly how I plan do to it.

@jimisaacs i prefer use configurable npmrc (path/env) instead of embedded npmrc.

@ije Ah, maybe I misunderstood what you meant by ENV (i.e. NPM_* vars)
So my problem is, I'm not sure how you configure it like this. I know there's a hierarchy that goes from $prefix/etc/npmrc which is what I'm using, and $HOME/.etc, and then package level .npmrc which I don't think applies here.
Is there a way to configure npm to use an npmrc? Can you elaborate if you have something specific in mind?

https://docs.npmjs.com/cli/v7/configuring-npm/npmrc

@ije are you suggesting to have a configurable path to an npmrc that nodejs.go would copy into place at $PREFIX/etc/npmrc? Sorry, I'm probably jumping to conclusions at this point, will wait for your reply ;)

Ok last comment before I wait. My server environment is running as a non-provisioned user, but if I literally define $HOME node, npm, and yarn all pick it up just fine. So I can use the $HOME/.npmrc for configuration.
That said, that means I can remove the embed portion of this PR, though I'm still wondering what you are thinking.

i see, then i suggest create a npmrc file dynamic in the build script, here is how i enable the china traffic splitting feature: https://github.com/alephjs/esm.sh/blob/9be43ace1f6b4bd1dbd98586d858e47db678fd05/scripts/build.sh#L9

but for docker, env-* maybe make more sence

@ije I think I see what you are saying, but because I solved my issue without code changes, I was actually about to remove all things npmrc related from this, and just keep the nodePrefix stuff. Does that sound ok for now?

si, nodePrefix looks great 👍

@ije ok, have a look at the new diff when you get a chance

looks great 👍


JS Highlighting: '/*' in string disrupts comment highlighting

Information:

Prism version: 1.23.0
Plugins: none
Environment: Node (built with prism-react-renderer)

Description
When a string contains /* (which is common in configurations with glob matching), only the directly next line comment directive gets properly highlighted.
If a block comment is inserted somewhere, however, the subsequent line comments are parsed correctly again.
Example

(I am using the vscode-dark theme provided by prism-react-renderer)

This has been fixed in 1.24.0. (live demo)

Thanks. Turns out it's just that prism-react-renderer hasn't bumped its dependencies since two months ago...


Properties set in _hover does not override other properties.

Describe the bug
Property does not get overrided by the same property set in _hover using a Factory
I created a component using the Factory function and was trying to make some styling using _hover.
It work great except it doesn't override values that are already set.
To Reproduce
Open the snack and then hover the Choice component
Expected behaviour
The border color should be primary.500 when hovered. Instead it stays gray.100
CodeSandBox/Snack link
https://codesandbox.io/s/peaceful-taussig-5s1cz?file=/src/components/Choice.tsx
Platform

NativeBase version: 3.2.1
OS: MacOS BigSur
Browser: Chrome
Browser version: Version 94.0.4606.81 (Official Build) (x86_64)
Expo sdk version https://github.com/expo/react-native/archive/sdk-42.0.0.tar.gz
node 16.3.0
yarn 1.22.11

@etiennelacoursiere Thanks for reporting this issue! We've kept it on high priority.


Automatic registration/de-registration of child view.

From<EMAIL_ADDRESS>on November 14, 2013 12:07:54
If a view has properties to hold references to its child views.  When those properties are set, the children property should automatically be updated.
Original issue: http://code.google.com/p/foam-framework/issues/detail?id=80

This was done for CViews. And in U2, the View lifecycle is much better defined than it was before.
Closing this one.


Support git@github.com:foo/bar.git style repository url.

Now, supports following url in package.json
{
    "repository": {
    "type": "git",
    "url": "https://github.com/foo/bar"
  }
}

But, does not support following url in package.json
  "repository": {
    "type": "git",
    "url": "git@github.com:foo/bar.git",
  }

:beer:


RingBuffer's copy constructor and operator= are not working with the active part of 'queue_'

In RingBuffer's copy constructor and operator= and is construction like this:
        for (size_t i = 0; i < r.size(); ++i)
            queue_[i] = r.queue_[i];

but this works ONLY in head_ pointer position is 0.
For example this code:
    arx::RingBuffer<int, 4> buf {1, 2, 3, 4};

    Serial.print("buf[]:");
    for (size_t i = 0; i < buf.size(); ++i) {
      Serial.print(" [");
      Serial.print(i);
      Serial.print("]=");
      Serial.print(buf[i]);
    }
    Serial.println();

    buf.pop_front();
    buf.pop_front();

    Serial.print("buf[] after 2x pop_front:");
    for (size_t i = 0; i < buf.size(); ++i) {
      Serial.print(" [");
      Serial.print(i);
      Serial.print("]=");
      Serial.print(buf[i]);
    }
    Serial.println();

    arx::RingBuffer<int, 4> b2(buf);

    Serial.print("b2[] created by copy constructor:");
    for (size_t i = 0; i < b2.size(); ++i) {
      Serial.print(" [");
      Serial.print(i);
      Serial.print("]=");
      Serial.print(b2[i]);
    }
    Serial.println();

produces this output:
buf[]: [0]=1 [1]=2 [2]=3 [3]=4
buf[] after 2x pop_front: [0]=3 [1]=4
b2[] created by copy constructor: [0]=0 [1]=0

b2 should be equal to buf.

I thought that RingBuffer's :operator==() has the same issue, but it seems to be ok. The problem is only when queue_ is directly accessed.

Thank you!


Problems with sockjs Fallback

Before pusher-js v1.12.4 Pusher used either WebSocket or Flash as a fallback. Since https://github.com/pusher/pusher-js/commit/54bde39e9267489b2f1df714199436629fa5194e they started using sockjs as a second fallback method.
As of now slanger works fine with WebSockets and with Flash. But if you've got a client which does not have WebSocket support and does not have Flash (for example my Android 4.0.4 smartphone), the pusher-js library tries to talk with the original pusher.com server (via http://sockjs.pusher.com/pusher)
Do you have plans to support sockjs too? Or should one use pusher-js <= v1.12.3

Any progress on this?
Thanks!!

+1

@stevegraham any progress on this?


python print chinese language error

Problem Description
When I get a web page with Chinese, I find that all Chinese in the html is abnormal
Steps to reproduce the behavior:
The screenshot of the problem is as follows. The Chinese displayed in the web output of mitmproxy is normal, but I use flow.response.get() in Python, print is error
The code snippet I used is as follows

addons.py

import sys
# -*- coding: utf-8 -*-
sys.path.append("./venv/lib/python3.9/site-packages/")

addons = [
    counter.Counter(),
    joker.Joker(),
]

joker.py

class Joker:
    def response(self, flow: mitmproxy.http.HTTPFlow):
        print("-------------------------------------")
        print("flow.request.url:")
        print(flow.request.url)
        print("uri:")
        print(uri)
        print("uri.path:")
        print(uri.path)
        print("uri.netloc:")
        print(uri.netloc)
        print(type(text))
        print("flow.response.headers:")
        print(type(flow.response.headers))
        print(flow.response.headers.get("Content-Type"))
        print(flow.response)
        print("flow.request.method:")
        print(flow.request.method)
        print("flow.request.headers:")
        print(type(flow.request.headers))
        print(flow.response.get_text())

counter.py

import mitmproxy.http
from mitmproxy import ctx

class Counter:
    def __init__(self):
        self.num = 0

    def request(self, flow: mitmproxy.http.HTTPFlow):
        self.num = self.num + 1
        ctx.log.info("We've seen %d flows" % self.num)

run shell

mitmweb -s addons.py

System Information
mitmproxy --version
Mitmproxy: 7.0.2
Python:    3.9.5
OpenSSL:   OpenSSL 1.1.1k  25 Mar 2021
Platform:  macOS-10.16-x86_64-i386-64bit

English is not very good, sorry
If there is anything unclear, let me add
Thank you for helping me

Thanks for the detailed report! 😃
The problem here is that mitmproxy did not pick up <meta charSet="utf-8"/> because our regex only matched on charset and not on charSet. #4785 fixes this.
You can:

Wait for the next release.
Install a development snapshot from https://snapshots.mitmproxy.org/branches/main/ (should be updated in ~10mins)
Use flow.request.content.decode("utf8") for this specific instance.


feat: Include pinned safe apps in dashboard widget

What it solves
Part of #3693
How this PR fixes it
Pinned safe apps are included with a given weight when ranking tracked safe apps for the dashboard widget.
How to test it

Open the Safe app
Navigate to the dashboard
Observe that pinned apps are displayed within the safe apps widget

Screenshots

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

19 of 21 (90.48%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 35.368%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/components/Dashboard/SafeApps/Grid.tsx
0
1
0.0%

src/routes/safe/components/Apps/trackAppUsageCount.ts
19
20
95.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
3609

Relevant Lines:
9254

💛  - Coveralls

I thought I tested a similar ticket like this before, I don't know what is new here.
This is what I checked and you can tell me if I'm missing something:
Pinned apps are always first in the safe apps witdget
The ranking still work between pinned apps (most visited apps show first between pinned apps)
The ranking system still works fine between non-pinned apps
The if the apps have no ranking they will show randomly in the rest of the slots


[Prototype] Exploration of 2 column type comparison in tsc

Re: https://gist.github.com/orta/f80db73c6e8211211e3d224a5ab47624
But being prototyped using external npm packages and not intended to ever ship, but with this draft PR I can make tsc builds etc.

Lets see if a build requires the package lock update too

@typescript-bot pack this

@typescript-bot pack this

Test command now noops
@typescript-bot pack this

A repo if folks want to clone and have a look: https://github.com/orta/ts-2-col-tester

@typescript-bot pack this


feat(node): upgrade minimum version

BREAKING CHANGE: upgrade minimum version to 20

Current dependencies on/for this PR:

main

PR #16   👈

This stack of pull requests is managed by Graphite.


css: Replace all RGB colors with HSL colors

All RGB hex codes, rgb() colors, or rgba() colors, were replaced with hsl() or hsla() by a script.
I spent quite a while trying to manually verify the changes and handle edge cases, so hopefully everything is in order. (If you're wondering why the number of additions is slightly more than deletions, it's because I split up one line that got particularly huge with the inserted hsla colors.)
This resolves #4603

Automated message from Dropbox CLA bot
@cory2067, it looks like you've already signed the Dropbox CLA. Thanks!

Codecov Report

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

@@           Coverage Diff           @@
##           master    #5495   +/-   ##
=======================================
  Coverage   86.68%   86.68%
=======================================
  Files         431      431
  Lines       53461    53461
  Branches     2086     2086
=======================================
  Hits        46343    46343
  Misses       7118     7118

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 bd9459f...00899f8. Read the comment docs.

Merged, thanks @cory2067!


Vendor libnetwork dc52820147f40fe424c8959987af3b396f842639

Docker changes to use libnetwork Sandbox, which is ground-work for future integration with user namespace support.
This brings no network functionality change to Docker.
Tests for libnetwork changes are in ibnetwork project.
Vendoring includes major fix to net namespace handling which will fix #15341, #15855, #14464, #13931, #15948, #15788
Some of the changes in this vendoring include:

Don't discard error message on sending response #487
Do not print the word nil in a log. #482
Allow tests to be interrupted #481
Add Refresh() to Sandbox #479
Fix resolv.conf and hosts handling in sandbox #478
Do not panic on setns failure #477
Explicitly set namespace for all network operations #476
lock port mapper when reapplying iptables rules #472
Fix panic due to mismatched types #471
Overlay driver should assign interface mac based on the IP #469
Add DNS 'options' support #467
Simplify NetworkOverlaps function #442
Introduce Sandbox entity #365

Fixes #15341.

LGTM

LGTM

LGTM


Why do we have to add a plugin to tailwind config when creating a theme with tailwind.

Reproduction
Not relevant
Describe the bug
This is not a bug per se. I was just wondering why we have to do this: Add the formKitTailwind plugin from @formkit/themes to our project's tailwind.config.js file..
Creating a tailwind theme works just by overriding the default theme in a main.js/ts file of a vue project.
Environment
Not relevant

You dont have to of course, but the reasons you might want to are explained in the guide
Mostly its for things like variants

The formkit plugin for tailwindcss is to add formkit variants to tailwindcss, its not an actual theme with default styles and so on, if you want for example to style the input when there is an error you use the variant formkit-invalid:border-red-500. Maybe we could change its name to make it more obvious what the plugin does.

Ah, my bad. Thank you for the answer!


Error PRAGMA

⚠ Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

Description
Hello,
after a planned reboot of the docker host, UptimeKuma won't restart:
👟 Reproduction steps
Planned reboot
👀 Expected behavior
Startup
😓 Actual Behavior
Container is unhealthy
🐻 Uptime-Kuma Version
latest
💻 Operating System and Arch
Ubuntu 20.04
🌐 Browser
Chrome
🐋 Docker Version
No response
🟩 NodeJS Version
No response
📝 Relevant log output
==> Performing startup jobs and maintenance tasks
==> Starting application with user 0 group 0
Welcome to Uptime Kuma
Node Env: production
Importing Node libraries
Importing 3rd-party libraries
Importing this project modules
Prepare Notification Providers
Version: 1.11.3
Creating express and socket.io instance
Server Type: HTTP
Data Dir: ./data/
Connecting to the Database
Trace: [Error: PRAGMA journal_mode = WAL - SQLITE_NOTADB: file is not a database] {

  errno: 26,
  code: 'SQLITE_NOTADB'
}
    at process.<anonymous> (/app/server/server.js:1542:13)
    at process.emit (events.js:400:28)
    at processPromiseRejections (internal/process/promises.js:245:33)
    at processTicksAndRejections (internal/process/task_queues.js:96:32)

I cannot reproduce the problem, how did you restart the docker?
I believe that your db file is corrupted or the volume is missing.
You should check the /app/data directory.

I suppose the container got corrupted during a resize of the partition where docker is installed.
Never mind, it was a bit of a pain, but I did a fresh start and set up everything again. Now I exported the Backup JSON for next time.


New Results.Stream() overloads

blog

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

ID: ed83a5ff-cb3a-8655-9f9a-a441da52424e
Version Independent ID: ed83a5ff-cb3a-8655-9f9a-a441da52424e
Content: What's new in ASP.NET Core 7.0
Content Source: aspnetcore/release-notes/aspnetcore-7.0.md
Product: aspnet-core
Technology: aspnetcore-releasenotes
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Add in
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis/responses?view=aspnetcore-7.0#stream
and What's new


Dots and Arrow showing up without slick font

The arrows and dots didn´t work, just plain text vas displayed.
Fixed it by changing the content in the theme.css in the prev, next and dot clasess. Instead of the arrow/dot in the content property I used the unicode value .
Dont know if this is a bug, beacuse its only happenig in some sites which are in spanish, so I concluded it had to do with the charset or something used to ensure accents are being displayed correctly. So I here is what i did to fix it:
.slick-prev:before
{
content: '\2190';
}
[dir='rtl'] .slick-prev:before
{
content: '\2192';
}
.slick-next:before
{
content: '\2192';
}
[dir='rtl'] .slick-next:before
{
content: '\2190';
}
/* Dots */
.slick-dots li button:before
{
content: '\2022';
}
I have tested it on other sites without the charset/accent thing going on...  it still works! So I guess it makes it more compatible to use the unicode instead.

Please use utf-8 and also please read the contribution guidelines in the repository. :)


Hide tasks of specific status hides all tasks when empty

Hi
When you remove the default value ("x, -" ) from the field "Hide tasks of specific status" and leave it blank, the plugin won't show any task.
Thank you for the amazing plugin there is no alternative to it.

Mark this as a bug to be fixed.

Hi @vkamenski , sorry for the late reply but I believe this issue is somehow resolved in current version, could you please confirm and closs this issue?


Interface doesn't display validation errors when removing an object from a container

This is related to https://github.com/OSU-Net/cyder/issues/987. We may not currently have any validation errors on ctnr-object removal, but we would like to in the future.

I was using it wrong.


pouch logs command doesn't work

Ⅰ. Issue Description
pouch logs can't get logs on running container
Ⅱ. Describe what happened
using pouch logs to get log from running a container, nothing is returned
Ⅲ. Describe what you expected to happen
pouch logs command should work as docker logs
Ⅳ. How to reproduce it (as minimally and precisely as possible)

cid=$(pouch run --name test -d busybox sh -c "while true; do $(echo date); sleep 1; done")
pouch logs $cid

Ⅴ. Anything else we need to know?
$ cid=$(sudo docker run --name test -d busybox sh -c "while true; do $(echo date); sleep 1; done")
$ sudo docker logs $cid
Mon May 21 10:08:46 UTC 2018
Mon May 21 10:08:47 UTC 2018
Mon May 21 10:08:48 UTC 2018
Mon May 21 10:08:49 UTC 2018
Mon May 21 10:08:50 UTC 2018
Mon May 21 10:08:51 UTC 2018
Mon May 21 10:08:52 UTC 2018
Mon May 21 10:08:53 UTC 2018
Mon May 21 10:08:54 UTC 2018
Mon May 21 10:08:55 UTC 2018
Mon May 21 10:08:56 UTC 2018
Mon May 21 10:08:57 UTC 2018
Mon May 21 10:08:58 UTC 2018
Mon May 21 10:08:59 UTC 2018
Mon May 21 10:09:00 UTC 2018
Mon May 21 10:09:01 UTC 2018
Mon May 21 10:09:02 UTC 2018
Mon May 21 10:09:03 UTC 2018
Mon May 21 10:09:04 UTC 2018
$ rpm -q alidocker
alidocker-<IP_ADDRESS>-1615116.alios7.x86_64
Ⅵ. Environment:

pouch version (use pouch version):
$ git rev-parse HEAD
1e75a1190a46d8b84113462ad33b96636d5242a5

OS (e.g. from /etc/os-release):
$ sudo cat /etc/os-release
NAME="Alibaba Group Enterprise Linux Server"
VERSION="7.2 (Paladin)"
ID="alios"
ID_LIKE="fedora"
VERSION_ID="7.2"
PRETTY_NAME="Alibaba Group Enterprise Linux Server 7.2 (Paladin)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:alibaba:enterprise_linux:7.2:GA:server"
HOME_URL="https://www.aliyun.com/"
BUG_REPORT_URL="http://bbs.aliyun.com/"

ALIBABA_BUGZILLA_PRODUCT="Alibaba Group Enterprise Linux 7"
ALIBABA_BUGZILLA_PRODUCT_VERSION=7.2
ALIBABA_SUPPORT_PRODUCT="Alibaba Group Enterprise Linux"
ALIBABA_SUPPORT_PRODUCT_VERSION=7.2

Kernel (e.g. uname -a):
$ uname -r
3.10.0-327.ali2012.alios7.x86_64

Install tools:
nothing

Others:
nothing

Could you help to take a look at this? @fuweid

Hi @allencloud and @chuanchang , since I have only finished the Pouch Logs API in the last PR, the Pouch Logs CLI is no-op. I will make it works. For now, it's expected.

Any update on this? @fuweid


sbt-assembly dependency error

I'm receiving the below error, when I'm trying use sbt-assembly plugin for scala project.
unable to get resource for com.eed3si9n#sbt-assembly;0.14.5: res=https://repo.typesafe.com/typesafe/ivy-releases/com.eed3si9n/sbt-assembly/scala_2.12/sbt_1.0/0.14.5/ivys/ivy.xml: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
sbt-plugin-releases: unable to get resource for com.eed3si9n#sbt-assembly;0.14.5: res=https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases/com.eed3si9n/sbt-assembly/scala_2.12/sbt_1.0/0.14.5/ivys/ivy.xml: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Here is the version details :
Scala : 2.11.8
Spark : 2.3.1
sbt : 1.2.8
sbt-assembly : 0.14.5

It looks like your HTTPS certificate is unable to validate https://repo.typesafe.com/ according to the error message.


usage_time in session.details() returns None for ibm_cloud channel

Describe the bug
Comparing the sessions details between the ibm_cloud and the ibm_quantum channels, I saw that the usage_time was always None for cloud vs it always showed an actual number for the platform
Steps to reproduce

run a session via cloud
check session.details()['usage_time']

Expected behavior
it returns the usage time of the session
Suggested solutions
Additional Information

qiskit-ibm-runtime version: 0.29.0
Python version: 3.11.3
Operating system: macOS

This would have to be fixed on the server side - usage is not yet supported on the cloud channel https://github.com/Qiskit/qiskit-ibm-runtime/issues/1567#issue-2211742624


RHEL82 - KDUMP-CRASH-AUTO-SIZE not expected skipped

Actually it supports crashkernel=auto, we use CONFIG_KEXEC_AUTO_RESERVE=y to do the judgement, but it is not that case on RHEL82.

I'd like to figure out what happen in RHEL8.2, then no need this config CONFIG_KEXEC_AUTO_RESERVE setting.


Add Detailed Section to Each Scholarship Card for More User Information

I would like to suggest adding a "Details" section for each scholarship card on the scholarships page. This will help users see more information directly on the card itself before clicking on the "Apply Now" button.
Users should be able to click a "More Details" button on each card to expand/collapse the extra details. This will keep the card layout clean while still allowing access to additional information.
pls assign me and add level pls

@iwanturequity sure go ahead

Make sure to join the discord server for further communication
Don't forget to star the repository
Complete the task in next 2 days and kindly mention your issue # in your pr like:
Closes #IssueNumber

Note: the level of the issue may change based on the quality of the PR code


running outside the browser in a cli

Really cool approach here.
wondering if the abstraction allows running this on a server ?
Then i can use the same code for front end as for backend stuff like:

Making reports (html to PDF)
Making emails. THink mail merge.
Maybe even pre rendering web pages.

This serves 2 purposes:

Efficient DOM manipulation.
Elegantly design HTML components using Go.

Working outside the browser wouldn’t need efficient DOM manipulation. So you’d just be getting the abstraction around Go’s template/html package. That could work for sure.


Single-core FreeRTOS, ISR stops running on the non-FreeRTOS core

This problem was discussed on the SDK forum here, where @kilograham thought it sounds like a bug.
The issue arises with single-core FreeRTOS (configNUMBER_OF_CORES=1), starting the task scheduler on core0, and an ISR running on core1. The same code was also tested with threadsafe background mode, poll mode, and SMP FreeRTOS, and the problem doesn't happen in any of those versions.
On core1, the ADC is set to free-running mode, and this ISR is initiated to trigger on ADC_IRQ_FIFO. It saves the value from adc_fifo_get() in a static variable:
static volatile uint16_t temp_adc_raw;
static volatile unsigned long isr_runs = 0;
static volatile absolute_time_t last_isr_t;

static void
__time_critical_func(temp_isr)(void)
{
	uint16_t val = adc_fifo_get();
	critical_section_enter_blocking(&temp_critsec);
	temp_adc_raw = val;
	critical_section_exit(&temp_critsec);
	isr_runs++;
	last_isr_t = get_absolute_time();
}

isr_runs and last_isr_t are debugging variables, to count the number of ISR runs and the time of the last run. The critical section is initialized in main().
On core0, the FreeRTOS task scheduler runs a task that gets a WiFi connection and initializes lwIP callbacks. The lwIP calls are then managed by the task scheduler. The app uses this function to retrieve the latest ADC value, called from the lwIP callbacks on core0:
uint32_t
get_temp(void)
{
	uint16_t raw;

	critical_section_enter_blocking(&temp_critsec);
	raw = temp_adc_raw;
	critical_section_exit(&temp_critsec);
	printf("isr_runs=%u last_isr_t=%llu\n", isr_runs,
	       to_us_since_boot(last_isr_t));

	/* ... do some computation and return a value ... */
}

The printf output shows how often the ISR ran, and when it ran last in µs since boot.
In the problematic version of the app, when a network client makes a request and the lwIP callback calls get_temp(), the output shows that the ISR ran a few thousand times, then stopped:
isr_runs=12133 last_isr_t=5549347

These values never increase. The effect is that the network client gets back the value that was saved on the last ISR run, rather than continuously updated values derived from the ADC.
When I run the app in the other modes (threadsafe background, poll, and SMP FreeRTOS), the debug outputs always increase, and the network client gets the most recent value from the ADC.
This has been tested with SDK 1.5.1 and both of FreeRTOS V11.1.0 (current latest) and V10.6.2, which was the last version before the smp branch was merged to main. The same thing happened with both FreeRTOS versions.
In the same app, I have an async_context at-time worker that is also started on core1. It does the intercore synchronization in the same way as with the ISR -- the recurring worker function saves a static value, and the lwIP calls from core0 retrieve it, protected by a critical section. The network client always gets an updated value, including in the single-core FreeRTOS version. So although the ISR has stopped, the at-time worker continues running.
There is evidence that the ISR may have stopped around the time that the WiFi connection reaches the linkup state (which is done by the initializer task run by FreeRTOS on core0). I'm also saving a timestamp right after cyw43_tcpip_link_status() returns CYW43_LINK_UP, whose us_since_boot value is shown here as t:
t=5549470
[...]
isr_runs=12133 last_isr_t=5549347

The difference between the LINK_UP timestamp and the last ISR timestamp was 123µs in this case. The deltas I've seen here are usually in the 100s of µs range, always <= 1ms.
So to summarize:

An ISR triggered on ADC_IRQ_FIFO for a free-running ADC stops for some reason after a few thousand runs.
This happens when the app runs with single-core FreeRTOS, but not with the non-FreeRTOS choices for  cyw43_arch, and not with SMP FreeRTOS.
The ISR is stopped at a time that is apparently close to the time when the WiFi connection, executed in a FreeRTOS task, reaches the linkup state.

I've found a workaround, or a fix, depending on how you look at it.
I've added a semaphore that ADC initialization (as shown in the last comment) now waits for before doing anything else:
	sem_acquire_blocking(up);
	adc_init();
	/* ... and so forth as above ... */

The semaphore is signaled from the core0 initialization task after the network reaches the linkup state. So the ADC/IRQ initialization does not proceed until after that happens.
With that, everything works as expected. The debugging output shows that the number of ISR runs and the time of the last run increase on every get_temp() call, and the network client gets up-to-date values that originated from the ADC.
So the solution appears to be: don't start an ISR on a non-FreeRTOS core until the network is brought up by a task running on the FreeRTOS core. That is evidently only necessary in the single-core FreeRTOS configuration.
(I suspect that the ADC init code can run before waiting, and only the ISR enable has to wait for the semaphore.)
I'd say this is either a workaround for a bug in FreeRTOS or in the RP2040 port, or a fix for a bug in my own code, depending on whether this is considered works as designed for FreeRTOS and/or the port.
I personally would say that it's worth looking into why this happens in the port, since the wait is only necessary in the one specific configuration. I wouldn't have expected that an ISR on one core gets stopped unless it waits until after the link is brought up on the other core.

It is surprising that this works on SMP and not otherwise; the most common issue is with IRQ setup on SMP if you don't pin the setup task, as it may migrate from one core to the other at inconvenient times when not pinned.
Can you attach a ZIP for repro?

The workaround doesn't work as well as I thought. The code sample from my previous comment left out debugging output that I believed to be irrelevant:
	sem_acquire_blocking(up);
	puts("Doesn't work without this output");

But as the message says, if I leave out the puts() line, the fix doesn't work. I tried a few things to fix that, but can't explain it.
@kilograham I pushed a branch just for this issue, can you use that to try to reproduce?
https://gitlab.com/slimhazard/picow-http-example/-/tree/issue-1751
If so, there are some build requirements:
https://gitlab.com/slimhazard/picow_http/-/wikis/required-software
At minimum you need gperf and the four Python classes. I don't think that's too much of a PITA, but I guess I'm biased.
I think you'll be all right with the Quick Start:
https://gitlab.com/slimhazard/picow-http-example/-/tree/issue-1751#quick-start
cmake -DWIFI_SSID and -DWIFI_PASSWORD are just like in pico-examples. You only need -DHOSTNAME to test the TLS examples, and I wouldn't bother, that has nothing to do with the issue. -DCMAKE_BUILD_TYPE=Debug helps with some extra debug output.
The four relevant test apps are:

picow-http-example-freertos-sys-single (this was the problem case)
picow-http-example-freertos-sys-smp
picow-http-example-background
picow-http-example-poll

When you deploy one of those and if all goes well, you first see progress getting the wifi connection in the console, and eventually "http started". Then you can point a browser to http://picow (or whatever host name you chose), and you should see something like this:
https://gitlab.com/slimhazard/picow-http-example/-/wikis/Screenshots
The temperature value gets updated by Javascript every few seconds, or you can invoke it directly with curl http://picow/temp. The issue here was that the value should change occasionally; when the ISR stopped, it never changed. As you know, the on-die sensor doesn't change especially rapidly, even when all is working well. If I want it change faster, I put my finger on the RP2040 or blow a fan on it to make it warmer or cooler.
Let me know if you have any questions.

Might be worth retrying with the latest FreeRTOS here https://github.com/raspberrypi/FreeRTOS-Kernel

Might be worth retrying with the latest FreeRTOS here https://github.com/raspberrypi/FreeRTOS-Kernel

Do I need to use SDK 2.0.0 to build with that version? I tried it with version 1.5.1, and the app doesn't appear to be happy with it at all. Not just the single-core variant, but also the SMP version that I previously had working is now not working.
I'll have to investigate more to find out why. But if SDK 2.0.0 is required, then that explains it.

To correct my previous comment, I can run the SMP version successfully. I'm using SDK 1.5.1, and the FreeRTOS version from the raspberrypi repo as @kilograham advised above, at commit 4f7299d.
The single-core version is now failing configASSERT( pxTCB == pxCurrentTCB ) in xTaskPriorityDisinherit(), line 6700 of tasks.c. The call stack includes async_context_freertos_release_lock(), called by async_context_freertos_add_at_time_worker() which in turn was called by async_context_add_at_time_worker_in_ms() from my own code. Full stack trace below.
However, the async_context code called is called on the core that isn't running the FreeRTOS task scheduler. Is that the fundamental conceptual problem? My hypothesis: in a build that includes pico_cyw43_arch_lwip_sys_freertos in target_link_libraries, every async_context worker is assumed to be a FreeRTOS task. With configNUMBER_OF_CORES=1, if it's launched from a core that isn't running the scheduler, it's bound to fail.
Here's what my app does:

main() calls multicore_launch_core1(core1_main)
On core1, which is not running the scheduler, async_context workers are started.
On core0, main() goes on to create a FreeRTOS task and launches the scheduler.

Now I'm thinking that that's doomed to fail, because in the second step the workers are assumed to be FreeRTOS tasks. Is that right?
The assertion has something to do with holding a mutex, and might be bypassed with configUSE_MUTEXES != 1, but if my guess is right that's kind of beside the point. If FreeRTOS tasks are running around that the scheduler doesn't know about, something is bound to fail.
If this explanation is correct, then it means that single-core FreeRTOS can only succeed if the non-FreeRTOS core does not use async_context workers -- right?
Stack trace:
#0  _exit (status=status@entry=1)
    at /home/me/Develop/pico/pico-sdk/src/rp2_common/pico_runtime/runtime.c:187
#1  0x1001148a in __assert_func (
    file=file@entry=0x1005c760 "/home/geoff/Develop/pico/picow-http-example/lib/FreeRTOS-Kernel/tasks.c", line=line@entry=6700,
    func=func@entry=0x1005c6b8 <__func__.6232> "xTaskPriorityDisinherit",
    failedexpr=failedexpr@entry=0x1005c9ac "pxTCB == pxCurrentTCB")
    at /home/me/Develop/pico/pico-sdk/src/rp2_common/pico_runtime/runtime.c:271
#2  0x1001aa80 in xTaskPriorityDisinherit (
    pxMutexHolder=0x200031c8 <ucHeap+5304>)
    at /home/me/Develop/pico/picow-http-example/lib/FreeRTOS-Kernel/tasks.c:6700
#3  0x1001904c in prvCopyDataToQueue (
    pxQueue=pxQueue@entry=0x200043c0 <ucHeap+9904>,
    pvItemToQueue=pvItemToQueue@entry=0x0, xPosition=xPosition@entry=0)
    at /home/me/Develop/pico/picow-http-example/lib/FreeRTOS-Kernel/queue.c:2408
#4  0x10019440 in xQueueGenericSend (
    xQueue=xQueue@entry=0x200043c0 <ucHeap+9904>,
    pvItemToQueue=pvItemToQueue@entry=0x0, xTicksToWait=<optimized out>,
    xTicksToWait@entry=0, xCopyPosition=0)
    at /home/me/Develop/pico/picow-http-example/lib/FreeRTOS-Kernel/queue.c:975
#5  0x100195c4 in xQueueGiveMutexRecursive (xMutex=0x200043c0 <ucHeap+9904>)
    at /home/me/Develop/pico/picow-http-example/lib/FreeRTOS-Kernel/queue.c:787
#6  0x10017fb2 in async_context_freertos_release_lock (
    self_base=self_base@entry=0x20001030 <cyw43_async_context_freertos>)
    at /home/me/Develop/pico/pico-sdk/src/rp2_common/pico_async_context/async_context_freertos.c:226
#7  0x1001816c in async_context_freertos_add_at_time_worker (
    self_base=0x20001030 <cyw43_async_context_freertos>,
    worker=<optimized out>)
    at /home/me/Develop/pico/pico-sdk/src/rp2_common/pico_async_context/async_context_freertos.c:235
#8  0x1000063c in async_context_add_at_time_worker_in_ms (ms=0,
    worker=0x20000470 <rssi_worker>,
    context=0x20001030 <cyw43_async_context_freertos>)
    at /home/me/Develop/pico/pico-sdk/src/rp2_common/pico_async_context/include/pico/async_context.h:317
#9  initiate_rssi (params=params@entry=0x20021e28 <linkup>)
    at /home/me/Develop/pico/picow-http-example/src/tasks.c:215
#10 0x10000364 in core1_main ()
    at /home/me/Develop/pico/picow-http-example/src/main-freertos.c:40
#11 0x100182e4 in core1_wrapper (entry=0x10000355 <core1_main>,
    stack_base=<optimized out>)
    at /home/me/Develop/pico/pico-sdk/src/rp2_common/pico_multicore/multicore.c:97
#12 0x0000017e in ?? ()

I think I have this figured out. So that this isn't just a blog about me debugging my app, I think the relevance for the SDK is that, if FreeRTOS is running on one core, then there are constraints about what can run on the other core that hadn't been clear to me. If an async_context is initialized on the core running FreeRTOS, in this case via pico_cyw43_arch, then async_context_freertos will be assumed as the default for workers running on the non-FreeRTOS core. They will execute code as though they are FreeRTOS tasks, but not under the control of the task scheduler, and hence will almost certainly fail.
So I'm writing this down in case someone goes searching for a similar issue someday. Maybe something about these restrictions could be mentioned in a future edition of the SDK docs.
I had implemented work on the non-FreeRTOS core that was calling a function from cyw43_driver (cyw43_wifi_get_rssi()), after the pico_cyw43_arch had been initialized on the core running FreeRTOS. The cyw43_driver code on the non-FreeRTOS core makes use of the default context, which turns out to be async_context_freertos, and then bad things happen -- for example it tries to get the FreeRTOS mutex, or it checks the core number against that of the task scheduler, all of which throw assertions.
The solution was just to implement the work that involves pico_cyw43_arch as a FreeRTOS task, and run it on the FreeRTOS core. Other work that doesn't involve any async_context (in my case IRQ-driven ADC reads) can run on the non-FreeRTOS core.
I have it working with V11.1.0 of the FreeRTOS kernel again. But I think the newer version in the raspberrypi repo did a better job of revealing what the problem was, mainly by failing assertions that showed the call stack in FreeRTOS code where I hadn't expected it.
I'll update the forum thread where this got started. Unless you think I've got the explanation all wrong, I think this issue can be closed now.

Yes, it's a bit non-obvious. Maybe we should have an example for this.

I just noticed that https://github.com/raspberrypi/pico-sdk/issues/1540 discusses a similar initial misunderstanding (with a similar response by @peterharperuk).

Doesn't look the same to me.


Error while generating SharedKey - algorithm identifier 1.2.840.1135<IP_ADDRESS> in key not recognised

Getting following error while trying to generate Shared Key with a generated Public key (from this package) and my server's Private key.
{
"key": "",
"errorInfo": {
"errorCode": "java.security.spec.InvalidKeySpecException",
"errorInfo": null,
"errorMessage": "encoded key spec not recognized: algorithm identifier 1.2.840.1135<IP_ADDRESS> in key not recognised"
}
}
Steps to Reproduce

Generate Key using /ecc/v1/generateKey API
Take the Pubic Key value and use it in /ecc/v1/getSharedKey API
Use Server's Private Key (in PKCS8PrivateKey format) with PEM headers added
Hit the API with the values as obtained above

Expected behavior
Expected sharedkey as result.
Possible Fix
SO pointers point to upgrading org.bouncycastle library - which I upgraded from 1.64 to 1.70 - same error persists.
I am not an expert in Java but I used VSCode's ability to update my gradle config - which I am assuming did the right thing by getting the required version during the build.
Your Environment
The forwardsecrecy project is locally executed using VSCode debugger. Java version is SE 18+36-2087 mixed mode.
I am working on Windows 10 machine with the calls to forwardsecrecy coming from a .NET Core project.
Let me know if anything more is needed.
Screenshot of Swagger:

Log messages on Console

Further info.
I have made sure that the private key pem format is p8 without encryption using following openssl conversion.
$ openssl pkcs8 -in key1410.pem -topk8 -out p8key1410-nocrypt.pem -nocrypt
(pkcs8 key was obtained from pkcs12 pfx file).
I have enabled logs at DEBUG level and they are pasted here .
PS D:\Projects\sandbox\rahasya-main>  d:; cd 'd:\Projects\sandbox\rahasya-main'; & 'C:\Program Files\Java\jdk-18\bin\java.exe' '-agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=localhost:3404' '-XX:+ShowCodeDetailsInExceptionMessages' '@C:\Users\fspl-~1\AppData\Local\Temp\cp_9kqfzyht8ujy8jc6227ps6pfy.argfile' 'io.yaazhi.forwardsecrecy.ForwardSecrecyApplication'
BouncyCastle version is BouncyCastle Security Provider v1.64
BouncyCastle version is BouncyCastle Security Provider v1.64
.   ____          _            __ _ _
/\ / ' __ _ () __  __ _ \ \ \
( ( )__ | '_ | '| | ' / ` | \ \ \
\/  )| |)| | | | | || (| |  ) ) ) )
'  || .__|| ||| |_, | / / / /
=========||==============|/=////
:: Spring Boot ::        (v2.2.3.RELEASE)
2022-10-14 07:50:50.450  INFO 9324 --- [  restartedMain] i.y.f.ForwardSecrecyApplication          : Starting ForwardSecrecyApplication on FSPL-TECH with PID 9324 (D:\Projects\sandbox\rahasya-main\bin\main started by fspl-tech in D:\Projects\sandbox\rahasya-main)
2022-10-14 07:50:50.454 DEBUG 9324 --- [  restartedMain] i.y.f.ForwardSecrecyApplication          : Running with Spring Boot v2.2.3.RELEASE, Spring v5.2.3.RELEASE
2022-10-14 07:50:50.455  INFO 9324 --- [  restartedMain] i.y.f.ForwardSecrecyApplication          : No active profile set, falling back to default profiles: default
2022-10-14 07:50:50.638  INFO 9324 --- [  restartedMain] .e.DevToolsPropertyDefaultsPostProcessor : Devtools property defaults active! Set 'spring.devtools.add-properties' to 'false' to disable
2022-10-14 07:50:50.641  INFO 9324 --- [  restartedMain] .e.DevToolsPropertyDefaultsPostProcessor : For additional web related logging consider setting the 'logging.level.web' property to 'DEBUG'
2022-10-14 07:50:54.263  INFO 9324 --- [  restartedMain] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2022-10-14 07:50:54.284  INFO 9324 --- [  restartedMain] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2022-10-14 07:50:54.285  INFO 9324 --- [  restartedMain] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.30]
2022-10-14 07:50:54.467  INFO 9324 --- [  restartedMain] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2022-10-14 07:50:54.468  INFO 9324 --- [  restartedMain] o.s.web.context.ContextLoader            : Root WebApplicationContext: initialization completed
in 3826 ms
2022-10-14 07:50:55.761  INFO 9324 --- [  restartedMain] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 5 endpoint(s) beneath base path '/actuator'
2022-10-14 07:50:55.921  INFO 9324 --- [  restartedMain] pertySourcedRequestMappingHandlerMapping : Mapped URL path [/v2/api-docs] onto method [springfox.documentation.swagger2.web.Swagger2Controller#getDocumentation(String, HttpServletRequest)]
2022-10-14 07:50:56.103  INFO 9324 --- [  restartedMain] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'
2022-10-14 07:50:56.216  INFO 9324 --- [  restartedMain] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server is running on port 35729
2022-10-14 07:50:56.532  INFO 9324 --- [  restartedMain] d.s.w.p.DocumentationPluginsBootstrapper : Context refreshed
2022-10-14 07:50:56.589  INFO 9324 --- [  restartedMain] d.s.w.p.DocumentationPluginsBootstrapper : Found 1 custom documentation plugin(s)
2022-10-14 07:50:56.673  INFO 9324 --- [  restartedMain] s.d.s.w.s.ApiListingReferenceScanner     : Scanning for api listing references
2022-10-14 07:50:57.036  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_1
2022-10-14 07:50:57.042  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_2
2022-10-14 07:50:57.051  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_3
2022-10-14 07:50:57.067  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_4
2022-10-14 07:50:57.079  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_5
2022-10-14 07:50:57.086  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_6
2022-10-14 07:50:57.089  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_7
2022-10-14 07:50:57.113  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: decryptUsingPOST_1
2022-10-14 07:50:57.163  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: encryptUsingPOST_1
2022-10-14 07:50:55.761  INFO 9324 --- [  restartedMain] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 5 endpoint(s) beneath base path '/actuator'                                                                                peration named: generateKeyUsingGE
2022-10-14 07:50:55.921  INFO 9324 --- [  restartedMain] pertySourcedRequestMappingHandlerMapping : Mapped URL path [/v2/api-docs] onto method [springfox.documentation.swagger2.web.Swagger2Controller#getDocumentation(String, HttpServletReperation named: getSharedKeyUsingPquest)]
2022-10-14 07:50:56.103  INFO 9324 --- [  restartedMain] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing Executort(s): 8080 (http) with context porService 'applicationTaskExecutor'
2022-10-14 07:50:56.216  INFO 9324 --- [  restartedMain] o.s.b.d.a.OptionalLiveReloadServer       : LiveReload server iecyApplication in 7.826 seconds (Js running on port 35729
2022-10-14 07:50:56.532  INFO 9324 --- [  restartedMain] d.s.w.p.DocumentationPluginsBootstrapper : Context refreshed   DispatcherServlet 'dispatcherServ
2022-10-14 07:50:56.589  INFO 9324 --- [  restartedMain] d.s.w.p.DocumentationPluginsBootstrapper : Found 1 custom documentation plugin(s)                                                                                t 'dispatcherServlet'
2022-10-14 07:50:56.673  INFO 9324 --- [  restartedMain] s.d.s.w.s.ApiListingReferenceScanner     : Scanning for api liation in 11 mssting references                                                                                ret
2022-10-14 07:50:57.036  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_1
2022-10-14 07:50:57.042  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_2
2022-10-14 07:50:57.051  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_3
2022-10-14 07:50:57.067  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_4
2022-10-14 07:50:57.079  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_5
2022-10-14 07:50:57.086  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_6
2022-10-14 07:50:57.089  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: handleUsingGET_7
2022-10-14 07:50:57.113  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: decryptUsingPOST_1
2022-10-14 07:50:57.163  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: encryptUsingPOST_1
2022-10-14 07:50:57.183  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: generateKeyUsingGET_1
2022-10-14 07:50:57.216  INFO 9324 --- [  restartedMain] .d.s.w.r.o.CachingOperationNameGenerator : Generating unique operation named: getSharedKeyUsingPperation named: getSharedKeyUsingPOST_1
2022-10-14 07:50:57.372  INFO 9324 --- [  restartedMain] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context port(s): 8080 (http) with context path ''
2022-10-14 07:50:57.378  INFO 9324 --- [  restartedMain] i.y.f.ForwardSecrecyApplication          : Started ForwardSecrecyApplication in 7.826 seconds (JecyApplication in 7.826 seconds (JVM running for 9.675)
2022-10-14 07:51:09.941  INFO 9324 --- [nio-8080-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
2022-10-14 07:51:09.942  INFO 9324 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2022-10-14 07:51:09.955  INFO 9324 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 11 ms
2022-10-14 07:51:10.223  INFO 9324 --- [nio-8080-exec-1] i.y.f.controller.ECCController           : Generate Shared Secret
2022-10-14 07:51:10.225 DEBUG 9324 --- [nio-8080-exec-1] i.y.f.controller.ECCController           : Get PrivateKey
2022-10-14 07:51:30.368 DEBUG 9324 --- [nio-8080-exec-1] i.y.forwardsecrecy.service.ECCService    : Successfully initialised the key factory
2022-10-14 07:51:33.904 DEBUG 9324 --- [nio-8080-exec-1] i.y.forwardsecrecy.service.ECCService    : Its a private key
2022-10-14 07:51:36.353 DEBUG 9324 --- [nio-8080-exec-1] i.y.forwardsecrecy.service.ECCService    : PKCS8 decoded
2022-10-14 07:51:43.724 ERROR 9324 --- [nio-8080-exec-1] i.y.f.controller.ECCController           : Error when deriving secret key

As this is a blocker presently and the keys generated by TestAA are not being consumed in .NET, this docker image is the only way to complete the AA / FIP cycle.
I would appreciate, if this is taken up on urgent basis. Thanks.

Is it possible for you to extract the key as a hex and use the X25519 controller apis?

Hi,
I install the pack on a different linux box and am exposing the APIs.
Currently its working for me.
When I get time, I will do what you have suggested and revert. It may take
some time.
Re Tapan
--
Tapan Trivedi
On Wed, Nov 9, 2022 at 5:50 PM Sasikumar Ganesan @.***>
wrote:

Is it possible for you to extract the key as a hex and use the X25519
controller apis? — Reply to this email directly, view it on GitHub, or
unsubscribe. You are receiving this because you authored th
External Email...Caution Could be SPAM sophospsmartbannerend
Is it possible for you to extract the key as a hex and use the X25519
controller apis?
—
Reply to this email directly, view it on GitHub
https://us-east-2.protection.sophos.com?d=github.com&u=aHR0cHM6Ly9naXRodWIuY29tL1NhaGFtYXRpL3JhaGFzeWEvaXNzdWVzLzI4I2lzc3VlY29tbWVudC0xMzA4NjcwNDE1&i=NjIyODNmMzAyNDNkNjYxMjNjYTdkZDEy&t=UG9welFQdVlDZzdqNEFXRGZPLzJZZG1ZMmx0SWlhYUIyTUZHL3ZuRXNEND0=&h=b50ef665ba7b476daad4b3ef96e0668f&s=AVNPUEhUT0NFTkNSWVBUSVb5ANN_SyiGPrcsfDsMAnynIxGUWs-MzxRaQ5795haRcA,
or unsubscribe
https://us-east-2.protection.sophos.com?d=github.com&u=aHR0cHM6Ly9naXRodWIuY29tL25vdGlmaWNhdGlvbnMvdW5zdWJzY3JpYmUtYXV0aC9BVVIyNFpINEdONTNWVFZVUDczUFhaVFdIT0pKRkFOQ05GU002QUFBQUFBUkVDNzc0TQ==&i=NjIyODNmMzAyNDNkNjYxMjNjYTdkZDEy&t=Z04wVjJ6M2l5NUxaWTNXM0NWdUlPWWF0cHhkdGRsdFBJWHN1SFl6M2VVRT0=&h=b50ef665ba7b476daad4b3ef96e0668f&s=AVNPUEhUT0NFTkNSWVBUSVb5ANN_SyiGPrcsfDsMAnynIxGUWs-MzxRaQ5795haRcA
.
You are receiving this because you authored the thread.Message ID:
@.***>


[Package Issue]: Git.Git uninstalls extensions during upgrade

Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Installation issue.
Brief description of your issue
When performing an upgrade to the Git.Git package, an uninstall is performed which removes any extensions, even if they are also installed using winget. Most noteworthy being Microsoft.GitCredentialManagerCore and GitHub.GitLFS.  This forces you to keep a list of all extensions and reinstall them manually after any upgrade, and realistically prevents you from ever running upgrade --all as it risks breaking things.
Steps to reproduce
winget install Git.Git -v 2.39.0
winget install Microsoft.GitCredentialManagerCore
winget upgrade Git.Git

Actual behavior
extensions are uninstalled although any configurations in .gitconfig remain.
Expected behavior
extensions to remain in-place or be automatically reinstalled after a git upgrade so functionality remains.
Environment
Windows Package Manager v1.3.2691
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22623.1245
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.2691.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Screenshots and Logs
No response

I believe this is actually an issue with the git installer itself. I checked the manifest, and winget is just calling the git installer after downloading it, since the manifest has UpgradeBehavior: install. I then checked the inno setup file and there isn't any special switch for upgrading.
The only other thing I could possibly see happening is if a user scoped install was used when it was intended to be a machine scoped install, or vice versa.


allow async getJSON (& adapt saveJSON)

why not go the whole way with promises?
this way we don’t force people (e.g. me 😛) to use sync variants of IO functions.

@flying-sheep, great! I'll merge this today or tomorrow (on my phone right now). Thank you!

@flying-sheep could you also fix the failing tests please?

OK, done!

@flying-sheep published

thank you!


Redo of visualisation and adaptive PRs (396, 380)

Fixes #407
Fixes #376

Codecov Report

Merging #411 (363fac8) into main (95e2ddd) will decrease coverage by 3.79%.
Report is 1 commits behind head on main.
The diff coverage is n/a.


New extension: geminiExtension.js

This extension allows using Google Gemini inside of Scratch projects (fun fact: the extension itself is generated by Google Gemini!). This can be useful in a lot of cases, like working chatbots, characters with realistic AI-powered dialogue that adapts to the things that happen in the game, and more.

I guess I'll make my own extension hosting service for my extensions.
On Sun, Apr 21, 2024 at 12:54 PM LilyMakesThings @.***>
wrote:

@.**** commented on this pull request.
In extensions/-Microboy-/geminiExtension.js
https://github.com/TurboWarp/extensions/pull/1418#discussion_r1573854007
:

@@ -0,0 +1,66 @@
+// Name: Gemini Extension
+// ID: geminiExtension
+// Description: Allows using Google Gemini within Scratch projects. In fact, this extension is generated by Google Gemini itself!

In fact, this extension is generated by Google Gemini itself!
We seriously prohibit extensions that are generated by AI and not
created by someone who has any prior JavaScript experience.
Language models do not understand how to make Scratch extensions, let
alone TurboWarp extensions which have a whole other set of needs.
What you've done here is just admitted that you haven't read any of the
TurboWarp extension documentation, nor the contributing guidelines. Quite a
self report, don't you think?
For that very reason I'm not even going to review this.
—
Reply to this email directly, view it on GitHub
https://github.com/TurboWarp/extensions/pull/1418#pullrequestreview-2013480509,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYUH7MS7JX5OFDCRMWVGOOLY6PVLBAVCNFSM6AAAAABGROYD5WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDAMJTGQ4DANJQHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Also, I've read the guidelines and gave Google Gemini several different
examples and debug prompts to get it working, and they don't say anything
about AI-generated extensions.
On Sun, Apr 21, 2024 at 12:54 PM LilyMakesThings @.***>
wrote:

@.**** commented on this pull request.
In extensions/-Microboy-/geminiExtension.js
https://github.com/TurboWarp/extensions/pull/1418#discussion_r1573854007
:

@@ -0,0 +1,66 @@
+// Name: Gemini Extension
+// ID: geminiExtension
+// Description: Allows using Google Gemini within Scratch projects. In fact, this extension is generated by Google Gemini itself!

In fact, this extension is generated by Google Gemini itself!
We seriously prohibit extensions that are generated by AI and not
created by someone who has any prior JavaScript experience.
Language models do not understand how to make Scratch extensions, let
alone TurboWarp extensions which have a whole other set of needs.
What you've done here is just admitted that you haven't read any of the
TurboWarp extension documentation, nor the contributing guidelines. Quite a
self report, don't you think?
For that very reason I'm not even going to review this.
—
Reply to this email directly, view it on GitHub
https://github.com/TurboWarp/extensions/pull/1418#pullrequestreview-2013480509,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYUH7MS7JX5OFDCRMWVGOOLY6PVLBAVCNFSM6AAAAABGROYD5WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDAMJTGQ4DANJQHE
.
You are receiving this because you authored the thread.Message ID:
@.***>


Create v1.3.0 tag

In support of https://github.com/spf13/cobra/issues/1597, we want to tag this repository with the same "version" that was used before we migrated the code here. This still communicates the version of the cobra CLI but also represents the final tag that the two will correlate.
In otherwords, this tag is the split in the road that will enable use to seperate cobra from cobra-cli
The release note for v1.3.0 of this repo will note that all previous history and release markers can be tracked in the spf13/cobra repo.
If there are no objections, I will do this within the week 👀

As mentioned, it makes sense to me that cobra-cli 1.3 should be "exactly" the same as the cobra generator 1.3 except for the renaming.
That being said I'm not sure what's best about supporting the .cobra-cli.yaml configuration file of #6.  Should it be in 1.3 or not?

Why not start with a 1.3.1 with the minor changes from the move? There isn't any particular reason why we need the 1.3 to live in both places and in the worst case it would make for some frustrations if they differed slightly between the repos.

What if we cut v1.3.0 which is exactly what was in spf13/cobra
and then cut a quick followup of v1.3.1 with any "fixes" that make sense for this repo?

But what is the point of the v1.3.0? If its exact (same sha for the build) then no user could possibly need it. If its not the same then it should be v1.3.1, right?

I guess I'm not sure the benefit either; just thought it'd click nicely with where spf13/cobra is at right now
@johnSchnake @marckhouzam - we good to cut a v1.3.0 tag today?

I do like that we have a tag that corresponds to the 1.3.0 release of the spf13/cobra repo (although the code is slightly different because of the renaming).  We can do 1.3.1 release quickly after to deal with the renaming of the configuration file and possibly some other small improvements.
So it's 👍 for me @jpmcb

👍  from me as well to have a 1.3.0 that is the ~same as cobra 1.3.0 modulo rename

Sounds good to me - v1.3.0 incoming today! 👀

Tagged and released! https://github.com/spf13/cobra-cli/releases/tag/v1.3.0


Fix AccessibleTeamReposEnv.RepoIDs can not get the correct result

Possibly fix #32677
There are two function we can remove a member from an organization.
RemoveOrgUser and RemoveTeamMember
RemoveTeamMember seems correct, as by my test it can correctly update the watch list.
But for RemoveOrgUser, it can not correctly remove the watch list for private repos in the organization, as there's a miss in the condition.
About the fix:
If user is null or user is restricted, then we need to add the condition to filter the private repos.
But the logic now is if user is not restricted, only public repos will be count.
This line comes from:
https://github.com/go-gitea/gitea/pull/6274/files#diff-780b130df406563b7f1b2dd8add33e4160a91f9a130ef99f7282389e20ea9efbR777

Looks like the fix is unrelated to the #32677 ? Can you confirm the user is restricted? And BTW maybe you need a test for that.

Looks like the fix is unrelated to the https://github.com/go-gitea/gitea/issues/32677 ?

When user leave the org and RemoveOrgUser was used. And in this function, it is using AccessibleReposEnv to get the repo ids which user should unwatch the repo. But because of the logic problem, it can not get the private repo ids when the user is not restricted.


license key

hello
How can I activate the structurizr new license Key,  I have new license information, but I could not understand where it is written

If you're referring to the Structurizr on-premises installation, the license key is embedded in the download, which is available from your structurizr.com dashboard.

Tanks

Forgive me for bothering you again, but maybe give me a little instruction that will help our
System administrators in license renewal

If you've recently renewed your on-premises license and would like access to the new features/updates, you will need to download and install the new version of the software:

Download link: https://structurizr.com/user/download/structurizr-onpremises.war (you will need to be signed in at structurizr.com)
Deployment guide: https://structurizr.com/help/on-premises/deployment


Delete tempfile if error occurs during download.

This addresses the issue of ensuring tempfiles are cleared in the event an error occurs during download in base, S3, and FileSystem modules. Implementation is straightforward like we discussed, the challenge was in testing.

Made the requested edits. Thanks for your feedback. 😃


Refactor test fixture utilities

As part of the upgrade to knex 0.11 (see #7195), a flag was added to the sqlite test config that uses "null" as the default value (for inserts that don't have a default?).
This fixed the tests in the short-term; however, the test fixture utilities need to be evaluated and refactored so that this work-around is not needed.
This issue exists as a place for potential discussion as to how to refactor the tests, as well as a reminder that the tests need to be refactored 😄

I haven't been able to find a good fixture library in the npm-world yet. Seems like one that works specifically with bookshelf/knex would be ideal?

Note: Knex does have a seed api: http://knexjs.org/#Seeds-API which might work well for this, given that it is built into knex.

@kirrg001 do you have any thoughts about this?

I am gonna close this, I don't think we're going to be doing this anytime soon. It'll likely happen whenever we really need it 😁


[Bug]: Service worker reload message doesn't disappear

Summary
Clicking the "reload" button on the service worker update prompt doesn't refresh the page, meaning users have to manually refresh to use the latest version after clicking it
Reproduction

Have an out of date version of LP
Click "reload" on the update prompt

Expected

Browser refreshes
New version commit hash is visible on menu

Actual

Browser doesn't refresh
Old version commit hash is visible on menu

Can't reliably reproduce this. Should re-open when more specific steps can be established


Support for .NET Core

Hi,
is there any support for .net core? We are migrating existing solution to ASP.NET 5? Our requirement is to host application on other OS than Windows

Hi,
At the moment, no, time-wise I'm a little constrained to do it, but if you want to go for a Pull request with it in, it would be greatly received!! :)

Is anyone looking into this? I would be willing to give this a start but wanted to check first not to duplicate the same work.

Hey @tugberkugurlu, I'm not actively looking into this at the moment, feel free to go for it, and if there is anything I can do to help let me know!

@cskardon great, I will give it a go and open a PR as soon as I have something viable.

PS issue #120 is the same... So I can close this one and leave the other, or vice versus, whichever you'd like!

@tugberkugurlu That is Amazeballs thank you!

This one seems better (judging from the title :smile:) because what needs to be done here is to support dotnet5.4 and net45 (if they will not change this again, sigh!), not dnxcore50. So, it will make it possible to reference this from a project which targets dotent5.4, dnxcore50, dnx451, net45 or above.

10-4  - I'll close the other one pointing to this...

I recently added support for .net core to Shouldly, I suggest you don't use the DNX tooling to actually do this, unless you don't want to run tests against .net 4.5 and only run your tests against dnx using the dnx runner.
Instead create a Portable class library (profile 259) and use a Shared Project to share the code between the full .net projects and the pcl library. This way you can create .net 45 and dnx test projects to verify things work on both platforms. You then use https://github.com/onovotny/ReferenceGenerator and hook it into your PCL library to update the nuspec with the dnx references, then copy the pcl dlls into lib/dotnet in your nuget package.
https://github.com/shouldly/shouldly/pull/341 and https://github.com/shouldly/shouldly/pull/346 are the PR's which implemented this change.
Hope that helps.

I started here: https://github.com/tugberkugurlu/Neo4jClient/tree/dotnet-core Will open a PR when it reaches a stable{ish} state to discuss/review/comment/etc.

Any ETA on this?

+1

Another +1 :) Neo4j is the only library now stopping me from moving to ASP.NET Core and utilising Docker in my application. Looking at #140, it looks like there's a lot of work involved! Such a shame that so much work is required just to move libraries to the next version of .NET and be xplat :-/ Great work so far @tugberkugurlu and @cskardon!! Do you think it might be quite a while before it's ready? I'm trying to make a decision of which way to go with my project - eg. switch to REST API for Neo4j; or stay with not using Docker for this bit of my app, and wait for Neo4jClient to support .NET Core. If it's around the corner, then I'll wait - otherwise I'll probably have to switch to the REST API unfortunately.
Thanks in advance.

@dracan there are a few missing stuff which seems like @cskardon is happy for it to re-implemented in a manual fashion or work around it in any other cases. These are the remaining things: https://github.com/Readify/Neo4jClient/pull/140#issue-124983574
Also, RC2 is a drastic change (and can even be considered as the new beta1). So, any work that will be done should be on rc2 stuff.

I don't want to sideline this ticket particularly, but I've been playing with a spike where I've done as @JakeGinnivan suggested and created a PCL - this leaves the TX stuff in place for full users - and (admittedly - this is the poo bit) removes it from the Core CLR version - but would give a quicker time to get a core version out.
I agree with the RC2 wait - and that's the main thing preventing me from trying out a proper core solution.
PCL Version
On the positive there is minimal change to the code, in essence aside from converting a few Reflection class uses, the code is the same. The 'Full-fat' version still has the TX code, and the core version can have it added in, with a view to maybe joining the two implementations together later on. This minimises changes for existing users, and mitigates conversion risks. Some people utilise the TransactionScope benefits across MSTDC and this allows them to continue to do so.
On the negative - Tx implementation for core would not be there - this is because TransactionScope does not exist in core. So core = no MSTDC. The other major negative for me is wasted time (in particular yours @tugberkugurlu ) and that sucks hugely, it's never been my intention to do so.
Core Version
This gets around the headache of maintaining two (albeit small) separate projects. The code would be consistent and all subsequent changes would be core compatible.
But we would lose the TransactionScope support - due to this the Tx code would have to be re-written, and that's quite a big task in and of itself. In practical terms - this needs to be done for the PCL version as well - but not straight away.
We could end up having a 1.1x version which maintains the full version + bug fixes and a 2.x version which is core, and I'm not sure what is easier to manage, though I would probably go the PCL route as it can all be in one solution.
So - here's the thing - I'm not totally up to speed with the core stuff, so I can't say if either way is better or worse from that POV, but I'd like to get there sooner rather than later as I want to put the Neo4j 3.0 Bolt code in, and that's a big change that merge wise seems impractical to do before core is done.
Any thoughts would be gratefully received, and apologies to anyone (well @tugberkugurlu) :/

The other major negative for me is wasted time (in particular yours @tugberkugurlu ) and that sucks hugely, it's never been my intention to do so.

Don't worry about it at all. Whatever works best here is all OK for me. I just wantted to kick start this as early as possible and pull request was helpful to visualize. So, all OK for me for this to be taken to any direction that you see fit :+1:

So - here's the thing - I'm not totally up to speed with the core stuff, so I can't say if either way is better or worse from that POV, but I'd like to get there sooner rather than later as I want to put the Neo4j 3.0 Bolt code in, and that's a big change that merge wise seems impractical to do before core is done.

I would say next milestone would be a better start. It's still not certain it will not change but I suspect there will be a lot more changes. The good side of getting a early start and pushing a pre-release would give people a chance to test it out in the wild and have a more stable release when everything hits prod.
Neo4j Bolt library also doesn't support .NET Core today but they are planning to get there: https://github.com/neo4j/neo4j-dotnet-driver/issues/52

@tugberkugurlu I spoke w/ their team on phone, they said 3.1 timeframe is when we could expect core support.
@cskardon don't know if you've seen this article regarding current state of affairs on rc2 - https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

Please give it a whirl -> I fully expect there to be issues - it's pre-release after all.
TX DOES NOT WORK IN CORE
https://www.myget.org/feed/neo4jclient-tx/package/nuget/Neo4jClient

@cskardon Hi just trying that new Core library, where is the source that's backing it? I'd be more than happy to patch up things as I find them.

@TheRubble I'll shift the source into this repo shortly - probably tomorrow or thursday (remind me if I have forgotten) - I've just moved house - currently awaiting BT to actually get me connected to the internet.

@TheRubble I sneaked some WiFi - have a look at: https://github.com/Readify/Neo4jClient/tree/DotNetCore

@cskardon Love it :+1: Sneakt Wifi

Just pushed core3 update to the myget - this is using the RTM versions of the core codebase, I've left Neo4jClient as pre-release for now.

So.
I'm holding off on going rtm with the core version as I was planning to put transactions in.
The unfortunate thing is that core doesn't support System.Transactions and Neo4jClient currently uses that for it's Tx management.
Recently (today-ish) the core team have started to look into getting System.Transactions into core for 1.1  (see https://github.com/dotnet/corefx/issues/2949).
This leads to 2 options in my view -

Redo the Tx code for Core now
Wait and see if core 1.1 will work with the current Tx code.

Both have risks - doing (1) means potential errors introduced and potentially managing two tx frameworks for a while. (2) means no Tx support for the core version for a while, and potentially having to do (1) later on down the road regardless.
I'm leaning towards (2) at the moment, as whilst I personally don't use DTC - I assume some people do - and I don't want to pull the rug on those and limit them to 1.1.x versions only.
Any thoughts on this would be greatly received.
PS. If anyone has tried / is using the core version in a project, feedback on it's general workiness would be great!

@cskardon Hi,
I'm currently using this in a project and have had absolutely zero issues so far. I think it's a upfront decision that transactions aren't supported and therefore solutions can be designed with this constraint in mind.
Once this functionality is available I'll refactor the project.
Thanks for all your work really appreciated made my life easier.

Hallo!
I'm going to close this now, as the Core version (2.0.0) is on Nuget - remember - no transactions in core.
I've opened issue #199 to cover that when Core 1.1 is available.


Update registry build/push to work with other container registries

Default to quay.io instead of dockerhub

This is for #2.
Not specifying 'fixes' yet because we won't know after this merges


Rethink class structure

While working to implement things like concat, I've noticed a few (potential) issues with the current design that may bite us in the future. I'll lay them out here. Feel free to ignore, I'm very new to working with this codebase and may be missing reasons for the existing layout.
Current Structure

A DataFrame contains:

A dictionary of columns to series
An index

A Series contains:

A buffer
A "mask" representing missingness
An implemenation depending on the dtype.

An index could be many things, but the generic one just wraps a series.

A numeric implementation contains:

A dtype

A categorical implementation contains:

A dtype
A codes dtype
A numerical implementation for the codes dtype
A set of categories
Whether the categories have an order

This structure results in a few odd things:

A DataFrame and each of its series all contain references to the same index. This currently isn't checked, but must be true for correctness.
The numeric implementation contains no data, but the categorical implementation does. This makes figuring out where to put methods kind of confusing.

Proposed new structure

A DataFrame contains:

a dictionary of column names to data objects
an index

A series contains:

a data object
an index

A data object contains:

a dtype
a mask
all methods for working with that dtype

An Index is basically the same as before, but contains a data object instead of a series.

This new layout is nicer because:

A dataframe only has one index reference. A new series is created each time it's indexed out of that dataframe, but this is cheap since it's just a new python object wrapping an existing (not copied) buffer.

def __getitem__(self, key):
    return Series(self._columns[key], index=self.index)

Internally many algorithms are working with data objects instead of series. This makes keeping consistent dtypes, dealing with masks, and extra state from categoricals a lot easier. No longer does the categorical implementation object have to match the data buffer that's passed along inside a series. Correctly implementing concat becomes easier, as all necessary state is located on the same object.

Potential Example Class Hierarchy
class Data(object):
   pass

class NumericData(Data):
    def __init__(self, buffer, mask, dtype):
        pass

class CategoricalData(Data):
    def __init__(self, codes : NumericData, categories, ordered=False):
        pass

class Series(object):
    def __init__(self, data, index=None):
        pass

class DataFrame(object):
    def __init__(self, cols_and_data, index=None):
        pass

I don't think rearranging this would be that tricky. It basically amounts to moving the buffer storage into the implementation classes, and fixing existing code as necessary.

A DataFrame and each of its series all contain references to the same index. This currently isn't checked, but must be true for correctness.

It is checked at https://github.com/gpuopenanalytics/pygdf/blob/f3330612316e2f40fb0bda205ee2ad6ad212bc62/pygdf/dataframe.py#L286.  Series' index must be equivalent to the dataframe index..

The numeric implementation contains no data, but the categorical implementation does. This makes figuring out where to put methods kind of confusing.

The categorical impl doesn't contain data.  I think _categories and _ordered are metadata.
All SeriesImpl subclasses do not contain data.  They are the delegates.  When a type-specialized operation is invoked, a Series calls a SeriesImpl to handle the operation.  In SeriesImpl, the methods always take the "calling" series as one of the arguments.
To add new type-specialized methods, the actual implementation goes to SeriesImpl.  The Series will have a small wrapper to delegate the work.
However, I have been lazy sometimes and the actual implementation is put directly to Series.  That's okay for now.

As for the proposed class hierarchy, the only difference I see would be where the data is.  In SeriesImpl, the data is always passed as an arg of Series type.  Whereas is in the new Data class, it will be under self.  I would prefer not to couple the data and the type-specialized operation.

Series' index must be equivalent to the dataframe index..

The categorical impl doesn't contain data. I think _categories and _ordered are metadata.

Ah, you are correct in both cases. Ignore my gripes there :).

As for the proposed class hierarchy, the only difference I see would be where the data is. In SeriesImpl, the data is always passed as an arg of Series type. Whereas is in the new Data class, it will be under self. I would prefer not to couple the data and the type-specialized operation.

My only remaining issue is that I'm finding myself frequently using Series where an array would suffice. For example, GenericIndex is backed by a series (which also has an index). Concat is another example - to avoid repeatedly concatenating the same index arrays I had to do a kludgy hack in #40. With array like objects (that understand categoricals), concat could work on the arrays, and then wrap the final output in a series/dataframe with a concatenated index.
I think it would be nice to build operations on a generic data container without an index. Since categorical data has metadata (categories and ordered) at least the categorical data container would have to be a step higher than a gpu array. This is similar to pandas - pd.Series are either backed by numpy arrays or pd.Categorical.
Again, feel free to ignore, I'm still figuring things out. I think the differences between this project and pandas are tripping me up and that's leading to confusion on my part.

I agree that the GenericIndex design has issues.  I hacked it up to make progress.  It's backed by a Series just because Series has a lot of features.  But, the Series in GenericIndex should always have the basic RangeIndex as to not recursively containing more Series.

My only remaining issue is that I'm finding myself frequently using Series where an array would suffice.

That's true.  Sadly, the underlying numba gpu array is not as feature-rich.
Now, I think it make sense to introduce the Data classes.
So the Buffer class will be the physical layer.  The Data class will be the logical layer.

Closing due to #54


python311Packages.canals: 0.8.1 -> 0.9.0

Diff: https://github.com/deepset-ai/canals/compare/refs/tags/v0.8.1...v0.9.0
Changelog: https://github.com/deepset-ai/canals/releases/tag/v0.9.0
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 265342 at 2eb15c29 run on x86_64-linux 1

2 packages built successfully:

python310Packages.canals
python311Packages.canals

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

4 packages built:

python310Packages.canals
python310Packages.canals.dist
python311Packages.canals
python311Packages.canals.dist