MMDevice property manipulation functionality for NAudio

Key changes:

PropVariant fields now publicly alterable
Updates PropertyKeys dictionary with new PropertyKey static fields
MMDevice::GetPropertyInformation method now public and allows for access mode change
Implemented SetValue and Commit methods for PropertyStore class.

Changes listed above are targeted to allow user to modify MMDevice properties dynamically e.g: endpoint's displayed name.
Example code:
PropertyKey propKey = PropertyKeys.PKEY_Device_DeviceDesc;
IntPtr pointer = Marshal.StringToHGlobalAuto("hello world");
PropVariant value = new PropVariant()
{
    vt = (short)VarEnum.VT_LPWSTR,
    pointerValue = pointer
};

// deviceId string, enumerator MMDeviceEnumerator
MMDevice device = enumerator.GetDevice(deviceId);

// by default, read-only flag is used which causes Access Denied exception to occur
device.GetPropertyInformation(StorageAccessMode.ReadWrite);

PropertyStore store = device.Properties;
store.SetValue(propKey, value);
store.Commit();
// free memory
Marshal.FreeHGlobal(pointer);

thanks for this contribution - seems like it will be useful. It doesn't compile due to missing XML documentation for new public properties. In NAudio, all public types and members must have XML docs. If you can fix this, I will get it tested

Appended new XML documentation for public members as asked.


tms option ignored in 1.0?

I'm using custom tiles generated by gdal. In 1.0, the tiles are being reversed in the y-axis after zoom-in. I tried toggling tms from true to false, but it had no effect. I also tried the new {-y} feature (with the tms option removed), but it throws a "No value provided for variable {-y}" error.
After fiddling around for awhile I referenced 0.6.4 instead of 1.0 and everything works.
Btw, the cdn link to 0.7.7 seems down: http://cdn.leafletjs.com/leaflet-0.7.7/leaflet.js
Linking against<EMAIL_ADDRESS>for 1.0
var map = L.map('map', {
            crs: L.CRS.Simple,
            center: L.latLng(-128, 128),
            zoom: -2
        });
        L.tileLayer('/map/{z}/{x}/{y}.png', {
            noWrap: true,
            attribution: 'WW',
            detectRetina: false,
            bounds: L.latLngBounds(
                L.latLng(-256, 0),
                L.latLng(0, 256)
            ),
            tms: true,
            minZoom: 0,
            maxZoom: 4
        }).addTo(map);

Works for me, see http://playground-leaflet.rhcloud.com/bahu/edit?html,output
Next time, check the WMS/TMS tutorial, which contains working examples of TMS, and formulate a bug report like an actual bug report.

Right, I had already read that (and all the tutorials), but that doesn't really apply to custom tiles in conjunction with TMS. The closest tutorial is http://leafletjs.com/examples/crs-simple/crs-simple.html. Being somewhat of an esoteric topic, I was hoping for guidance. I will ask on Stackoverflow next time, my bad.
For anyone else trying to get CRS.Simple working with tiling generated by GDAL, the issue seems to be caused by this block of code
if (this._map && !this._map.options.crs.infinite) {
			var invertedY = this._globalTileRange.max.y - coords.y;
			if (this.options.tms) {
				data['y'] = invertedY;
			}
			data['-y'] = invertedY;
		}

The y will never invert because infinite is set to true in CRS.Simple. Creating a custom copy of CRS.Simple with infinite = false did the trick for my situation.

See https://github.com/Leaflet/Leaflet/issues/4338.


Question: business rules

Hello,
saw that you @nodh  added some code to store the business rules as Json, is there gonna be an interoperability between this library and https://github.com/ehn-dcc-development/dgc-business-rules ? Since hcert-kotlin already contains data and valueSets, it could technically generate data structure that can be used with the business rules.

You're right, we could add a data class to actually hold a business rule, i.e. one that deserializes the JSON strings we're storing. Unfortunately, this is not on our roadmap in the near future.


Different OS on Sandbox possible?

Even if it's not, having an FAQ for things that are NOT possible can be just as helpful (Because it can help you end your quest -- I'm currently stuck trying to find an answer to that question... and even our official page doesn't have it. :(

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

ID: 8c06f3ef-5946-862a-ae14-f897fdb518ca
Version Independent ID: cd6a8b99-b1e9-dff5-f174-a15840b304f0
Content: Windows Sandbox - Windows security
Content Source: windows/security/threat-protection/windows-sandbox/windows-sandbox-overview.md
Product: w10
GitHub Login: @Dansimp
Microsoft Alias: dansimp

@msheets1 . Mention all the questions those are araised in your mind. Any of Our expert person will answer your questions.

@msheets1 It's not possible to have a different OS on Windows Sandbox because Windows Sandbox is built upon the Windows 10 OS running on the machine. More details here.

Dynamically generated Image
At its core Windows Sandbox is a lightweight virtual machine, so it needs an operating system image to boot from. One of the key enhancements we have made for Windows Sandbox is the ability to use a copy of the Windows 10 installed on your computer, instead of downloading a new VHD image as you would have to do with an ordinary virtual machine.

@msheets1 Please let us know if you still have any question regarding the issue you have raised initially.
The issue is being closed since your question seems to be answered. Feel free to re-open this issue if you feel that it hasn't been answered or that there are further suggestions to improve the documentation itself.
Thanks.


Tests on php 5.6 are very slow on master

I think some of us have noticed.
Possible cause may be performance lost by garbage collection being forced to repeatedly kick in nearing memory allocation limit? I can't even complete the php56 tests locally (without adjusting my ini memory allocation to over 128M). Maybe a memory leak?
Tests seem to really start slowing down around the 30% mark (at which point memory allocated to the process is at ~80MB and counting up), which is quite far away from the allocation limit – so possibly that doesn't support this theory.
In contrast, php71 peaks at around 65MB as it completes the final tests (about half the amount of memory php56 tests need) – possibly (and maybe even likely) that's to do with various improvements in php7 over 5 though.
Maybe there is another cause to the slowness than memory usage, just thought I'd provide some observations in addition to starting a discussion on the general issue of the completion times.

Maybe we could do a test on Travis to up the memory limit for 5.6 to see if it has effect?
When you locally up'ped the limit did it speed up or was it "only" possible to finish the test?

When you locally up'ped the limit did it speed up or was it "only" possible to finish the test?

Hmm... it probably would have been a good idea to test that 😉
I set it to 1G and tests are still slow, so this doesn't look to be memory related.

Thanks for the details and looking forward to the results/observations :)
Will we used to profile and optimize for 5.x line but since our focus has shifted to 7.x, this does not mean that any perfs for 5.x are not welcome, more like a FYI.

My main motivation to have a look into it is to keep the travis tests under 20mins ;) (affects those of us that don't use 5.x daily too!)
That said, there are probably other ways of shortening that time if the focus on 5.x is dying down.

The focus for 5.x support shouldn't have go down, just stating what happened ;)
Would really like to see the time to test go down!

@aidantwoods how long tests took for your php 5.6 if you set up SKIP_LINT_TEST_CASES=1 ? if it's fairly fast, issue is not memory but php5-based linting, which is hell slower than under php7.

With SKIP_LINT_TEST_CASES=1 it's about 5x faster locally

damn that is high factor :)
not sure we can do without linting...

not sure we can do without linting...

Additional CI for lint tests? This could tie in nicely with #2893 😉
Since OSX tests will likely pass on linux and vice versa – can be fairly confident of result from linux if we're seeing pass/failure, and then just wait for OSX builds to finish to be sure.

@aidantwoods then you proved it's slow not because of memory leaks or anything. it's just that slow. that's why we introduced php-7 specific linter.
no, we cant skip linting on 5.x line.
@aidantwoods , if you want, you could play with https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/2.2/src/Linter/ProcessLinter.php#L145 to store tmp file not in cwd, but in /tmp (only if it's available !).
If not, fine for me as well.
Closing due to discussion.


loader problem after new love2d version

since the new love2d version, I get these error:
Error: lib/Cargo/cargo.lua:62: bad argument #2 to 'loader' (string expected, got no value)
If did hat hotfix:
local asset = nil
if extension ~= "wav" then
asset = loader(file)
else
asset = loader(file,"static")
end
since I only have png's and wav's
best regards
þorN

@bjornbytes The issue is that the SourceType argument in love.audio.newSource is now mandatory, and you can't specify that through cargo

Maybe we could have a heuristic where big files are loaded as stream and small files are loaded as static?  We could also just default to stream like in previous versions of LÖVE.

The heuristic sounds cool... having stream as default for a hotfix would be simple to do

Sounds good. Would be great to have a hotfix, since I plan to use cargo as an submodule in my library, and otherwise I have to do a fork with the nasty but working hardcoding.

Alright, the latest commit should fix this.  It loads the source as 'static' if it's less than 500kb in size, otherwise it uses 'stream'.


Broken nested file download URLs in registrations API

The OSF API returns files embedded in registrations. These files include links for specific actions ("download", "move", "upload", "delete"). At least the "download" link does not seem to work.
For example, consider the response JSON snippet (from the command http get https://api.osf.io/v2/registrations/aurjt/ | jq .data.attributes.registered_meta.q19.value.uploader.extra[0]):
{
  "nodeId": "knm7u",
  "viewUrl": "/project/aurjt/files/osfstorage/58484e239ad5a102024869d6/",
  "selectedFileName": "Paul_AnalysisCode_113016.Rmd",
  "sha256": "d3ffc031da185bb862c577e5f599453401f98bdc0b3d3328a8f8bc69080fbe6f",
  "data": {
    "nodeUrl": "/knm7u/",
    "kind": "file",
    "resource": "knm7u",
    "name": "Paul_AnalysisCode_113016.Rmd",
    "links": {
      "download": "https://files.osf.io/v1/resources/knm7u/providers/osfstorage/5844691c9ad5a100475fe678",
      "move": "https://files.osf.io/v1/resources/knm7u/providers/osfstorage/5844691c9ad5a100475fe678",
      "upload": "https://files.osf.io/v1/resources/knm7u/providers/osfstorage/5844691c9ad5a100475fe678?kind=file",
      "delete": "https://files.osf.io/v1/resources/knm7u/providers/osfstorage/5844691c9ad5a100475fe678"
    },
    "extra": {
      "downloads": 0,
      "guid": "",
      "checkout": "",
      "hashes": {
        "sha256": "d3ffc031da185bb862c577e5f599453401f98bdc0b3d3328a8f8bc69080fbe6f",
        "md5": "f251810ad2c222498c927b48ad09f156"
      },
      "version": 1
    },
    "materialized": "/Experiment 1/Analysis Code/Paul_AnalysisCode_113016.Rmd",
    "size": 9638,
    "nodeId": "knm7u",
    "accept": {
      "acceptedFiles": true,
      "maxSize": 5120
    },
    "modified": "2016-12-04T19:06:04",
    "etag": "bcbaf35bc3c52dda4b254911941482197e8344f6f38074953f2817c248e4cf3d",
    "provider": "osfstorage",
    "contentType": "application/octet-stream",
    "path": "/5844691c9ad5a100475fe678",
    "permissions": {
      "edit": true,
      "view": true
    },
    "type": "files",
    "id": "osfstorage/5844691c9ad5a100475fe678",
    "modified_utc": "2016-12-04T19:06:04+00:00",
    "nodeApiUrl": "/api/v1/project/knm7u/"
  },
  "fileId": "595e3"
}

The "download" link https://files.osf.io/v1/resources/knm7u/providers/osfstorage/5844691c9ad5a100475fe678 is an HTTP 404 ("Page not found"). A working direct download link can be cobbled together from the viewUrl, provider, and version as: https://files.osf.io/v1/resources/aurjt/providers/osfstorage/58484e239ad5a102024869d6?action=download&version=1&direct
which works (HTTP 200 and file is returned).

Hi @bnewbold - we've identified the issue and will work on the fix in an upcoming sprint. Thanks for the report!


Faster Aim UI: Experiment selection header

When using the Aim UI, there is currently no convenient way to "stay" in a given experiment when browsing to the various explorer tabs (Metrics, Runs, Params, and Scatters). The user needs to add something like run.experiment == "My experiment" to the search query every time. When the user does no do that, they end up with all of their runs for all of their experiments, which is rarely what they want.
It would be better to always have an experiment selection header at the top each of those sections, allowing the user to quickly switch from one experiment to another. Here is a screenshot of the existing selection header when in the experiments section:

The implementation goal would be to have this same header available in the other sections, and add the right experiment selection to the search query implicitly, a bit like what is done when a metric is selected. This will probably need to be stored in browser local storage in the same way that Aim already does for the various explorer tabs (to be researched).

Just a small update for my progress:
The search queries don't seem to handle filtering by experiment, so I'm implementing internal filtering with the newly obtained runs (which contain experiment data). I might need to figure out a way to integrate this with #863 so that filtering is not required.


[sw, dif_rstmgr] Add control and read APIs for alert info crash dump

This change is a part of DIF Reset Manager follow-up changes described in #3454.
I will add the corresponding unit tests in the follow-up when the API for this change has been approved.

I am not sure that the following is a good idea, what do you guys think?
dif_rstmgr.h:
...
/**
 * The maximal size of the alert crash info dump.
 *
 * Note: must match the autogenerated register definition.
 */
#define DIF_RSTMGR_ALERT_INFO_MAX_SIZE 0xf
...
/**
 * Reset Manager possible reset information enumeration.
 *
 * Invariants are used to extract information encoded in
 * `dif_rstmgr_reset_info_bitfield_t`, which means that the values must
 * correspond
 * to the individual bits (0x1, 0x2, 0x4, ..., 0x80000000).
 *
 * Note: these must match the autogenerated register definitions.
 */
typedef enum dif_rstmgr_reset_info {
  /**
   * Device has reset due to power up.
   */
  kDifRstmgrResetInfoPor = 0x1,
  /**
   * Device has reset due to lowe power exit.
   */
  kDifRstmgrResetInfoLowPowerExit = (0x1 << 1),
  /**
   * Device has reset due to non-debug-module request.
   */
  kDifRstmgrResetInfoNdm = (0x1 << 2),
  /**
   * Device has reset due to a peripheral request. This can be an alert
   * escalation, watchdog or anything else.
   */
  kDifRstmgrResetInfoHwReq = (0x1 << 3),
  /**
   * \internal used to catch missing `_Static_assert` for public variants.
   */
  kDifRstmgrResetInfoLast = kDifRstmgrResetInfoHwReq,
} dif_rstmgr_reset_info_t;
...

dif_rstmgr.c:
// This macro simplifies the `_Static_assert` check to make sure that the
// public reset info register bitfield matches register bits.
#define RSTMGR_RESET_INFO_CHECK(pub_name, priv_name)                      \
  _Static_assert(                                                         \
      kDifRstmgrResetInfo##pub_name == (0x1 << RSTMGR_RESET_##priv_name), \
      "kDifRstmgrResetInfo" #pub_name " must match the register definition!")

RSTMGR_RESET_INFO_CHECK(Por, INFO_POR);
RSTMGR_RESET_INFO_CHECK(LowPowerExit, INFO_LOW_POWER_EXIT);
RSTMGR_RESET_INFO_CHECK(Ndm, INFO_NDM_RESET);
RSTMGR_RESET_INFO_CHECK(HwReq, INFO_HW_REQ);
...
_Static_assert(
    DIF_RSTMGR_ALERT_INFO_MAX_SIZE == RSTMGR_ALERT_INFO_CTRL_INDEX_MASK,
    "Alert info dump max size has grown, please update the public define!");
...

I was on board with this @lenary suggestion, but now I have some doubts. These seem to me like something that can be parameterized differently between the chips (at the moment only EarlGrey), in which case the assertions will fail for on of the instantiations.
What do you think?

Added unittests - dif_rstmgr_alert_info_dump_read for now.

I think I might actually prefer result_t dif_rstmgr_alert_info_dump_read(... *handle, ... *buffer, buffer_len, size_t *words_written), that means that I would need to resurrect ...get_size. Please see the  comment above. Yes, this interface is not foolproof, however the caller is in full control of what to pass to the function. The DIF can then return an error if the buffer is not big enough for the entire dump.
I am just double weary now on tying private (definitions that can potentially be parameterized) with the public side of the API (@gkelly @lenary @alphan @mcy @jon-flatley ). What are your thoughts?

These seem to me like something that can be parameterized differently between the chips (at the moment only EarlGrey), in which case the assertions will fail for on of the instantiations.
What do you think?

IMHO it all depends on the actual differences between the chips. For _dump_read I don't see a big difference between the two approaches since both of them expect the clients to allocate a fixed size buffer, right? Size of that buffer is currently hard-coded in the DIF header but if we want to generalize it to multiple chips that information must come from somewhere else. Will it be passed to _init as a literal or will it come from another auto-generated header? We can also completely decouple the destination buffer size from the hardware but it would require tracking the state of the read operation, which means additional complexity. All of this also depends on how this library will be built for different chips. I think, personally, I would lean towards simplicity unless we have a clear idea about which parts of the hardware can be different and how we want to deal with such changes in all DIFs.

I think I might actually prefer result_t dif_rstmgr_alert_info_dump_read(... *handle, ... *buffer, buffer_len, size_t *words_written), that means that I would need to resurrect ...get_size. Please see the comment above. Yes, this interface is not foolproof, however the caller is in full control of what to pass to the function. The DIF can then return an error if the buffer is not big enough for the entire dump.
I am just double weary now on tying private (definitions that can potentially be parameterized) with the public side of the API (@gkelly @lenary @alphan @mcy @jon-flatley ). What are your thoughts?

It seems like the core of the problem is that we've used a #define because we want to use the reset manager buffer size in type definitions, so we don't dynamically allocate. We use a #define because we can't use a const global variable, which would allow us to hide the value away from the header. This issue is hit in USBDev as well.
I think my approach would be this:

We should move to alphan's API as proposed above, for this DIF. This is safer today, and looks like the API we want when we come to parameterize this DIF's implementation against the hardware instance in a more complete manner than we currently do.
We should avoid, as much as possible, #defines in DIF headers, and almost certainly global variables are also a problem when we come to parameterize the hardware - in the long term, we should be doing these queries with functions which take in a DIF instance handle, so the function can query handle.params.
We need to think about the dynamic buffer allocation issue, which we have so-far been punting on by using #defines (which can be used in types, e.g. for array sizes, unlike global variables).

I think this comes under the "parameterize the difs" issue we've thought about before. I'll take a look through the current DIFs to highlight which have problematic defines or global variables, and collect those into an issue so we don't lose track of them.
Parameterising only becomes an issue when we have multiple chips - but we want the APIs reasonably stable for shipping the Mask ROM, so we should ensure we're not painting ourselves into a corner with the first API.
Does this sound reasonable?

^ sounds reasonable to me. I think the current consensus from the offline chat was that we will try to avoid implementing an allocator, but will try to generate relevant defines in the top_earlgrey.h so that the DIF consumers could allocate the buffers statically. This are the thought from a quick offline chat, and has not been explored further in detail!

In the end to simplify the implementation and avoid implementing additional functionality that we might not need, I have decided to disallow partial dump read, and return an error if the full dump cannot be read.
I have added unittests.

I think there's a question here about using general errors for such a specific error result when there's not enough space

I have added this to my TODOs issue.
Merging now, I think I have addressed all the comments, and this change had enough exposure.


Automated Package Upgrade

:tada: This PR is included in version 2.0.7 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


HTTP2 server does not respond

var http2 = require('http2');
var Koa = require('koa');

var app = new Koa();

app.use(async (ctx) => {
    ctx.body = 'Hello World';
});

http2.createServer(app.callback()).listen(3000);

try to hit the server in browser http://localhost:3000 and get error:
The localhost site sent an invalid response. ERR_INVALID_HTTP_RESPONSE

node: v14.13.0
koa: 2.13.0

No browser supports unencrypted HTTP/2. You need to use http2.createSecureServer and provide cert and key.


"The inferred type of X cannot be named without a reference to Y" (TS2742)

npm_link_package labels in data and deps attributes in ts_project is causing typescript to issue portability errors.
Here is a reproduction and more info in the README:
https://github.com/tinganho/transitive-deps-bug

This might be an issue with symlinks and not only rules_ts? See https://github.com/microsoft/TypeScript/issues/29808#issuecomment-581795107

Yup. Looks like this is a Typescript + symlinked node_modules structure issue and not specific to rules_js or Bazel.
https://github.com/microsoft/TypeScript/issues/47663
@mrmeku has a repro outside of Bazel with pnpm, which also uses a symlinked node_modules structure like rules_js: https://github.com/mrmeku/portable_types_repro (from https://github.com/microsoft/TypeScript/issues/47663#issuecomment-1267631748)

One of the work-arounds in https://github.com/microsoft/TypeScript/issues/47663 is to import type {} from "transitive": https://github.com/microsoft/TypeScript/issues/47663#issuecomment-1270716220.
I was able to get this reproduction to work by doing that for the transitive closure with this change:
$ git diff
diff --git a/packages/a/BUILD.bazel b/packages/a/BUILD.bazel
index 0744ca1..9be754c 100644
--- a/packages/a/BUILD.bazel
+++ b/packages/a/BUILD.bazel
@@ -5,5 +5,8 @@ package(default_visibility = ["//visibility:public"])
 ts_test(
     name = "a",
     srcs = ["foo.ts"],
-    deps = ["//packages/b:b"]
+    deps = [
+        "//packages/b:b",
+        "//packages/c:c",
+    ]
 )
\ No newline at end of file
diff --git a/packages/a/foo.ts b/packages/a/foo.ts
index faf0838..c227a19 100644
--- a/packages/a/foo.ts
+++ b/packages/a/foo.ts
@@ -1,4 +1,6 @@
 import { Foo } from '@myorg/b/bar';
+import type {} from '@myorg/b/bar';
+import type {} from '@myorg/c/qux';

 export interface Offline {
     pluginRegistry: Foo | undefined;
diff --git a/packages/b/bar.ts b/packages/b/bar.ts
index 44d3558..d8e7756 100644
--- a/packages/b/bar.ts
+++ b/packages/b/bar.ts
@@ -1,4 +1,5 @@
 import { Bar } from '@myorg/c/qux';
+import type {} from '@myorg/c/qux';

 export interface Foo {
     bar: Bar[];

Until the underlying problem with Typescript and the symlinked node_modules structure is fixed, a work-around will be needed.

@gregmagolan I think in an ideal world, you shouldn't have to add transitive dependency packages/c:c in order for it to work? At least, when you do that, then it is linked directly under node_modules folder. Shouldn't ts_project be able to resolve deep transitive deps?

Seems like indeed it is a TypeScript bug. Described more in here:

You get this error any time the declaration emitter can't synthesize a workable specifier for a module which it needs to name a type from. For example, if it appears that the only legal path is ../../other_module/foo via some file that's in <>/whatever, then that's not likely to work because the disk layout of the produced artifacts don't really have implicit dependencies on what peer directories of the output directory have.
The logic to synthesize these specifiers starts with the easy route of "Has this already been imported?", in which case re-use is easy and fine. Immediately past that lie many dragons and it's easy to get into a novel corner case where there is a speakable name to a module but TS just can't figure it out. Adding the import yourself is the easiest way to resolve the situation.

https://github.com/microsoft/TypeScript/issues/48212#issuecomment-1205888829

@gregmagolan I had closer look at the the minimum reproducible project today. I noticed the symlink structure is not exactly described in PNPM:
Note, that under node_modules/.aspect_rules_js/@myorg+b@0.0.0/node_modules/@myorg the symlink c is not pointing to node_modules/.aspect_rules_js/@myorg+c@0.0.0/node_modules/@myorg/c:

The project is under sandbox/darwin-sandbox/3 but the symlink target has a common ancestor 3 levels higher?
Note the c package is stored node_modules/.aspect_rules_js/@myorg+c@0.0.0/node_modules/@myorg/c, which the b package doesn't symlink to?

I'm thinking if the symlink target is being kept in the project's subtree. It might fix the issue?

That is an issue with Bazel controls how symlinks are layed out on disk and historically the sandbox and runfiles trees created symlinks as absolute paths pointing out of the trees instead of relative within the trees.
However, this problem is now resolved in Bazel 6 with some help from the community. Bazel 6 is currently at 6.0.0rc1. If you use the latest rules_js with Bazel 6.0.0rc1 and set the --allow_experimental_unresolves_symlinks flag in your .bazelrc then the symlinks should be layed out on disk correctly by Bazel.

The bug still appears, although now inside the project subtree

The inferred type of 'Offline' cannot be named without a reference to '.aspect_rules_js/@myorg+c@0.0.0/node_modules/@myorg/c/qux'. This is likely not portable. A type annotation is necessary.

@gregmagolan  I'm still having this problem. And --allow_experimental_unresolves_symlinks is unrecognized by Bazel.

@gregmagolan could you provide more details for --allow_experimental_unresolves_symlinks? Adding it to .bazelrc doesn't fix the issue for me.
Is there any plan to get this fixed?

@flolu Bazel  6 the feature is on by default so it is only with Bazel 5 that --experimental_allow_unresolved_symlinks needs to be set explicitly. What version of Bazel are you using?

@gregmagolan I'm using Bazel 6:
Bazelisk version: v1.13.2
Build label: 6.0.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Dec 19 15:52:35 2022<PHONE_NUMBER>)
Build timestamp:<PHONE_NUMBER>
Build timestamp as int:<PHONE_NUMBER>

You can reproduce the issue like this:
git clone https://github.com/flolu/aspect-typescript
git checkout inferred-type-error
pnpm i
bazelisk test ...

It throws:
app/app.ts(4,7): error TS2742: The inferred type of 'app' cannot be named without a reference to '.aspect_rules_js/@types+express@4.17.17/node_modules/@types/express-serve-static-core'. This is likely not portable. A type annotation is necessary.

The underlying with Typescript and the symlinked node_modules structure is still open https://github.com/microsoft/TypeScript/issues/47663, although it looks like the discussion is still active and someone has proposed a set of patches. The issue has also been reported on the pnpm repo 4 days ago https://github.com/pnpm/pnpm/issues/6089 since pnpm also uses a symlinked node_modules structure.
For now a work-around is needed for this issue both with rules_js and pnpm. https://github.com/pnpm/pnpm/issues/6089#issuecomment-1433207437

@gregmagolan allright, thanks!

Same issue here


Gas fee & Distribution of rewards

[x] Erc20 token replacement
[x] Add  token price service for GasPriceOracle #28
[x] Distribution of Tss rewards

too old


liburcu: 0.12.1 -> 0.12.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/liburcu/versions.
meta.description for liburcu is: "Userspace RCU (read-copy-update) library"
meta.homepage for liburcu is: "https://lttng.org/urcu"
meta.changelog for liburcu is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 0.12.2 with grep in /nix/store/pxnbsjsc4cdvssbdzsqlwp6lpc0k6jlw-liburcu-0.12.2

directory tree listing: https://gist.github.com/1f47726e757fb7834481a662e34e6f23

du listing: https://gist.github.com/0493fa32bbae6ae5eac2181764686ce9

Rebuild report (if merged into master) (click to expand)

105 total rebuild path(s)

46 package rebuild(s)

46 x86_64-linux rebuild(s)
23 i686-linux rebuild(s)
9 x86_64-darwin rebuild(s)
27 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
appgate-sdp
aws-workspaces
bareos
bcachefs-tools
ceph
ceph-client
ceph-dev
codeql
coreclr
glusterfs
knot-dns
knot-resolver
libceph
liburcu
libvmi
lttng-tools
lttng-ust
multipath-tools
netsniff-ng
nfs-ganesha
ntirpc
osu-lazer
powershell
qemu_full
qemu_xen
qemu_xen-light
qemu_xen_4_10
qemu_xen_4_10-light
qubes-core-vchan-xen
samba4Full
sambaFull
vscode-extensions.ms-python.python
vscode-extensions.ms-vsliveshare.vsliveshare
xen
xen-light
xen-slim
xenPackages.xen-light
xenPackages.xen-slim
xenPackages.xen-vanilla
xenPackages.xen_4_10-light
xenPackages.xen_4_10-slim
xenPackages.xen_4_10-vanilla
xen_4_10
xen_4_10-light
xen_4_10-slim
zoxide

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/pxnbsjsc4cdvssbdzsqlwp6lpc0k6jlw-liburcu-0.12.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A liburcu https://github.com/r-ryantm/nixpkgs/archive/af3185cdf18dea307f76a0550436c9e29b45f628.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/pxnbsjsc4cdvssbdzsqlwp6lpc0k6jlw-liburcu-0.12.2
ls -la /nix/store/pxnbsjsc4cdvssbdzsqlwp6lpc0k6jlw-liburcu-0.12.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages marked as broken and skipped:

bareos
samba4Full

8 packages failed to build:

coreclr
libvmi
qemu_xen (qemu_xen_4_10)
qemu_xen-light (qemu_xen_4_10-light)
qubes-core-vchan-xen
xen
xen-light
xen-slim

23 packages built:

appgate-sdp
aws-workspaces
bcachefs-tools
ceph
ceph-client
codeql
glusterfs
knot-dns
knot-resolver
libceph
liburcu
lttngTools (lttng-tools)
lttngUst (lttng-ust)
multipath-tools (multipath_tools)
netsniff-ng
nfs-ganesha
ntirpc
osu-lazer
powershell
qemu_full
vscode-extensions.ms-python.python
vscode-extensions.ms-vsliveshare.vsliveshare
zoxide

Maintainer pings
cc @bjornfor for testing.

nixpkgs-review successful on macos 10.14


micropython

My guess is that, like me, the majority of RP2040 users are coding newbies who've had a splash in the micropython pool but haven't ventured into the murky water that is C++.
A micropython version of a 1.3mA sleep mode that wakes itself from an internal timer would broaden the scope & appeal of this ingenious bit of detective work considerably.

Hi @kjm1102 thanks for having a look at the code.
I've had a quick look at this, I couldn't find anything for micopython around this after an initial look ( for waking from the real time clock, see the last part of this post for GPIO wakeup), that's not to say it hasn't been implemented. I did stumble upon this however:
https://github.com/adafruit/circuitpython/pull/4816/files
It appears that someone has done the work to get deep sleeping working for circuit python. It's fairly similar to micropython in that you just upload a uf2 file to your pico and then drop python files onto it, which it will then run for you.
Some other links around this are:
https://circuitpython.readthedocs.io/en/latest/shared-bindings/alarm/index.html#alarm.exit_and_deep_sleep_until_alarms
https://learn.adafruit.com/deep-sleep-with-circuitpython/alarms-and-sleep#timealarm-deep-sleep-3078700-7
I tried with this code:
import alarm
import board
import time
import digitalio

print("Waking up")

led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT

# Flash the led
led.value = True
time.sleep(2)
led.value = False
# Set an alarm for 60 seconds from now.
time_alarm = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + 60)

print("Sleeping")
# Deep sleep until the alarm goes off. Then restart the program.
alarm.exit_and_deep_sleep_until_alarms(time_alarm)

You can then upload this as code.py onto the pico board and it will run it. At least for me it seems to work. However I have not measured the power consumption. Certainly from a brief look at the PR above they are using dormant mode to sleep.
Unfortunately there is no main loop here, so each time the program restarts. However if you want to accomplish some work and then sleep, after which the program wakes up again from the beginning, this is certainly a way to do that.
I also found this https://github.com/tomjorquera/pico-micropython-lowpower-workaround
Which appears to be a way for the pico to sleep and be woken from a GPIO pin using micropython. Very similar to this post https://ghubcoder.github.io/posts/waking-the-pico-external-trigger/
So my using an external RTC you could wake the pico by listening for a pin to go high. I haven't tested this however.

Hi and thanks for creating this code. I ran it to execute calls to a Cricket Wifi module and it certainly slashes the power consumption on the Pico.
I did find though that if the timer interval is set to values above 1024 the picosleep call seems to lose the expected interval and begins to cycle at shorter intervals than expected. For example using an interval of 3600 seconds starts a sleep that appears to last about 20 seconds. I wonder if there might be an overflow condition occurring on the input parameter?

@capnf which code are you getting that with? Is that with the micropython uf2 file?

Hello,
I downloaded a uf2 file - micropython-pico-deepsleep-1-0.uf2 - and loaded that onto the Pico.
David F
From: ghubcoder @.>
Sent: 06 November 2021 12:13
To: ghubcoder/PicoSleepDemo @.>
Cc: capnf @.>; Mention @.>
Subject: Re: [ghubcoder/PicoSleepDemo] micropython (#2)
@capnf https://github.com/capnf  which code are you getting that with? Is that with the micropython uf2 file?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/ghubcoder/PicoSleepDemo/issues/2#issuecomment-962442658 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AWL2F3OU6442SNKEXONXNWTUKULT3ANCNFSM5FNN3XPQ .
Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675  or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .   https://github.com/notifications/beacon/AWL2F3MAGAMJB467QBEYK6LUKULT3A5CNFSM5FNN3XP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHFO3LIQ.gif

Great thanks @capnf I will take a look at what might be going on there.

@capnf I've uploaded a new release which should fix that here

That's terrific - thank you. I've downloaded and am testing now. Will get back with results later today.

I've run tests at various timer intervals from 60 seconds up to 1500 secs and all worked correctly, whereas previously it began to misbehave at the upper end of that range. Obviously it will take longer to check what happens when much longer intervals are selected, but I'll keep running the tests and let you know. Looks as though it's fixed though - good work and super fast response :)

It works at 3600secs also, so looks like the fix is good.

Brilliant, thanks for checking.
You were right with your hunch, it was overflowing. The type used was int8_t, max value 127.
Now it's using uint32_t, max value 4,294,967,295 which I hope should be plenty.

haha!. Debugging by hunch 👍   - I was 35 years in the IT business, and have never coded in C or Python, but some issues smell the same no matter what the language. I calculate that your new counter will be good for intervals up to the year 2157, and as I've already been around quite a lot of years I doubt I'll have to worry about what happens from then on :)
I'm planning to use your new module in a remote monitoring system for my boat. I want to rig up a system that sleeps on minimum power, then fires up a mifi router periodically, sniffs the temperature and the service battery voltages, and then reports back via a Cricket wifi module and a Pipedream workflow, before going to sleep again. I can't use the main service batteries to power this because the boatyards insist that everything is disconnected in Winter due to the fire risk.  Your code will, I hope, let me use a pretty small standalone battery that will last all winter - I wouldn't have been able to do this without your help.

That's really good to hear you know 🙂  I'm glad this little experiment has been useful for someone else and will be put to good use.
Thanks for raising the issue!

I'm a tad off topic with this question but I'm going to ask it anyway because, after a month of trying stuff,  I've run out of ideas. Your uf2 works great & my test program with picosleep.seconds(300) works the same as time.sleep(300), the only difference being the greatly reduced power consumption during the 300s of dormancy in the case of the former.
So next I connected the pico to to a simcom7020 4G modem via uart0. Yes, this is the off topic part. This modem 4G network
attaches automatically, but you have to tell it to 4G network connect. Here's the rub! If the pico has slept I can command the modem to connect no probs, but if the pico has been dormant no dice. It's bizarre, like the modem somehow knows which sleep mode I've used. The only way I can get the modem to connect is if I do a machine.reset() after the dormancy is finished. This is not the end of the world but it bugs me because I loose all my variables in RAM. Initially I thought the dormancy must have subtly effected uart0 but the modem responds to all other AT cmds normally, just won't 4g connect.
Since the 2 uart0 lines & 0v are the only 3 wires the modem & pico share I can't figure out how the modem knows when I've used dormancy Vs sleep. From your understanding of what goes happens to the various timers when dormant do you have any thoughts on what machine.reset() is fixing that allows the modem to carry out the connect command.

I finally got to the bottom of this. The dormancy leaves the pico with a uart unable to send or receive more than 32 chrs. So when the modem returns
b'at+cgcontrdp\r\r\n+CGCONTRDP: 1,5,"telstra.internet","<IP_ADDRESS>.<IP_ADDRESS>",,"<IP_ADDRESS>","<IP_ADDRESS>",,,,,1500 for the connect cmd the pico sees only
b'at+cgcontrdp\r\r\n+CGCONTRDP: 1,5,

Very strange @kjm1102.
I've tested with two picos connected together via UART 0. Pico 1 sends a long string every 5 seconds. Pico 2 runs the micropython deep sleep uf2 with the following:
import machine
uart = machine.UART(0)
from machine import Pin
led = Pin(25, Pin.OUT)
import time
import picosleep

def flash(times,sleep):
    num = 0
    while num < times:
        led.toggle()
        time.sleep_ms(sleep)
        num=num+1

while True:
    try:
        if uart.any():
            rxData = uart.read()
            string = rxData.decode("ascii")
            if "UART0 with debug with very very long string to see if it is cut" in string:
                flash(4,500)
                picosleep.seconds(2)

    except UnicodeError as e:
        print(e)
        continue

I added in the UnicodeError exception handler as sometimes when it starts up it fails with that error.
I also had to remove all print() statements as this seems to hang the pico after a while when sleeping. This is whilst connected via usb. There are definitely issues with usb communication after deep sleeping, I haven't been able to get to the bottom of that. Another issue was raised here https://github.com/ghubcoder/PicoSleepDemo/issues/1
However with the above code it will loop and flash indicating it has received the long string that is being sent after sleeping. That is more than 32 chars.......
Seems like there was someone else with your issue though a while back:
https://forum.micropython.org/viewtopic.php?t=9913

On Mon, 3 Jan 2022 at 00:40, ghubcoder @.***> wrote:

Very strange @kjm1102 https://github.com/kjm1102.
I've tested with two picos connected together via UART 0. Pico 1 sends a
long string every 5 seconds. Pico 2 runs the micropython deep sleep uf2
with the following:
import machine
uart = machine.UART(0)
from machine import Pin
led = Pin(25, Pin.OUT)
import time
import picosleep
def flash(times,sleep):
num = 0
while num < times:
led.toggle()
time.sleep_ms(sleep)
num=num+1
while True:
try:
if uart.any():
rxData = uart.read()
string = rxData.decode("ascii")
if "UART0 with debug with very very long string to see if it is cut" in string:
flash(4,500)
picosleep.seconds(2)
except UnicodeError as e:
    print(e)
    continue

Interesting squire! I ran a tweaked version of your code where I query the
modem for a response that has more than 32 chrs (looks
like  'at+cclk?\r\r\n+CCLK: 22/01/03,11:07:33+44\r\n\r\nOK\r\n')

while True:
try:
f=open('log', 'w'); f.close()
uart.write('at+cclk?\r\n')
if uart.any():
rxData = uart.read()
string = rxData.decode("ascii")
if "OK" in string:
flash(4,500)
picosleep.seconds(2)
time.sleep(2)
else: f=open('log', 'a'); f.write(repr(string)+'\n'); f.close()
except UnicodeError as e:
print(e)
continue
So you'd expect the modem response to get the same post dormant treatment
as your pico2 reply? But no, when I check the log file for 'OK'less
responses I get just the 1st 32 chars of the reply.

'at+cclk?\r\r\n+CCLK: 22/01/03,11:27'
'at+cclk?\r\r\n+CCLK: 22/01/03,11:27'
'at+cclk?\r\r\n+CCLK: 22/01/03,11:27'
'at+cclk?\r\r\n+CCLK: 22/01/03,11:27'
Are you using the uart0 on the default GP0/GP1 pins same as me? Maybe my
writing to uart0 post dormancy is the problem? Do you still get all of your
pico2 reply if you've previously written to the pico1 uart?
Seems like there was someone else with your issue though a while back:
https://forum.micropython.org/viewtopic.php?t=9913
Unreal, hemberg is using a modem from the same manufacturer. It seems from
that thread that the 32 chr uart brick wall was fixed in the April 2021
UF2. So why it's back for me & not for you is baffling.Message ID:
@.***>

I rewrote my code so that pico2 would send data to pico1, and then pico1 would reply.
Using your code I was able to reproduce the issue where it would only ever receive 32 chars after sleeping, by checking the contents of the log file.
The fix for me is to reinitialise uart0 immediately once we wake up:
picosleep.seconds(2)
uart = machine.UART(0, 115200)

Full code looks like:
import machine
uart = machine.UART(0)
from machine import Pin
led = Pin(25, Pin.OUT)
import time
import picosleep

def flash(times,sleep):
    num = 0
    while num < times:
        led.toggle()
        time.sleep_ms(sleep)
        num=num+1

while True:
    time.sleep(2)
    uart.write('send\n')
    try:
        while uart.any():
            rxData = uart.read()
            string = rxData.decode("ascii")
            #print(string)
            if "UART0 with debug with very very long string to see if it is cut" in string:
                flash(4,500)
                picosleep.seconds(2)
                uart = machine.UART(0, 115200)
            else:
                f=open('log', 'a'); f.write(repr(string)+'\n'); f.close()

    except UnicodeError as e:
        continue

This isn't great, sleeping must reset something which is breaking this. But for me this does appear to work around the issue.
Hopefully this will work for you as well 🤞

Nice fix, works for me too. Mercifully, dormancy seems to leave I2C
unscathed so I'm using an oled for diagnostics instead of print over USB to
the repl.
There must be a uart that handles the usb too right, uart-1? If we reset it
too after dormancy do you think print over USB to the repl might keep
working?
On Mon, 3 Jan 2022 at 20:54, ghubcoder @.***> wrote:

I rewrote my code so that pico2 would send data to pico1, and then pico1
would reply.
Using your code I was able to reproduce the issue where it would only ever
receive 32 chars after sleeping, by checking the contents of the log file.
The fix for me is to reinitialise uart0 immediately once we wake up:
picosleep.seconds(2)
uart = machine.UART(0, 115200)
Full code looks like:
import machine
uart = machine.UART(0)
from machine import Pin
led = Pin(25, Pin.OUT)
import time
import picosleep
def flash(times,sleep):
num = 0

while num < times:

    led.toggle()

    time.sleep_ms(sleep)

    num=num+1

while True:
time.sleep(2)

uart.write('send\n')

try:

    while uart.any():

        rxData = uart.read()

        string = rxData.decode("ascii")

        #print(string)

        if "UART0 with debug with very very long string to see if it is cut" in string:

            flash(4,500)

            picosleep.seconds(2)

            uart = machine.UART(0, 115200)

        else:

            f=open('log', 'a'); f.write(repr(string)+'\n'); f.close()

except UnicodeError as e:

    continue

This isn't great, sleeping must reset something which is breaking this.
But for me this does appear to work around the issue.
Hopefully this will work for you as well 🤞
—
Reply to this email directly, view it on GitHub
https://github.com/ghubcoder/PicoSleepDemo/issues/2#issuecomment-1003978394,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AV562MYRCNVYFZRJAMT7BYTUUFW7BANCNFSM5FNN3XPQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

I was trying to use the deep sleep function. I uploaded the new picosleep firmware to my board. I have a dc motor which is being powered with the help of a transistor. My objective is to toggle the motor at an interval of 5 seconds. In between the intervals the pico should go in deepsleep mode. The problem is the nothing happens. This is my code
from machine import Pin
import picosleep

motor = Pin(1, Pin.OUT)

while True:
    motor.value(1)
    picosleep.seconds(5)
    motor.value(0)
    picosleep.seconds(5)

If I replace the picosleep.seconds() with the utime.sleep() (and of course import the utime module as well) then everything works as expected

Define 'nothing happens', the motor fails to start before the first dormancy? Have you tried;

Using the pico led instead of gpio1 so you can eyeball what's happening
putting a utime.sleep(.1) before the picosleep in case the picosleep fires before the motor gpio has finished toggling?

I did exactly what you suggested and the led indeed toggled at an interval of 5 seconds.
After this I disconnected my pico, attached a multimeter and reconnected it, I couldn't however, measure the current consumption as the pico wouldn't connect. Everytime I connect it with the IDE, It logs this error in loop
Unable to connect to COM8: Cannot configure port, something went wrong. Original message: PermissionError(13, 'A device attached to the system is not functioning.', None, 31)

If you have serial connection to the device from another program, then disconnect it there first.

Process ended with exit code 1.

I noticed that this error went away when I boot the pico and upload the standard micropython uf2 firmware. But it comes back again after reupload the pico sleep micropython uf2 firmware. Any possible solution to fix this?

Okay so I uploaded a flash nuke to the pico which I got online while looking for a solution for this error that is mentioned above. I found out that I need to do this everytime I need to save the code in pico. It temporarily fixes the issue.
As I said earlier that this code (given below) works fine
from machine import Pin
import picosleep
import utime

led= Pin(25, Pin.OUT)

while True:
    led.value(1)
    utime.sleep(1)
    picosleep.seconds(5)
    led.value(0)
    picosleep.seconds(5)

However, as soon as I change the pin number to GPIO 1, To which the motor is connected, things start to go south. The motor starts but it stops running after 1-2 seconds. And from then nothing happens. No motor movement or anything.
from machine import Pin
import picosleep
import utime

motor = Pin(1, Pin.OUT)

while True:
    motor.value(1)
    utime.sleep(1)
    # Motor stops whenever pico reaches the next line, and from then onwards nothing happens, no motor movement at all
    picosleep.seconds(5)
    motor.value(0) # Motor should stop at this line after the 5 second deep sleep
    picosleep.seconds(5)

ghubcoder did well to get dormancy working but it's fragile, print statements break it & it seems to have issues with the uart0 pins (gpio 0 & 1). gpio2 seems to work OK as a motor driver with picosleep.
Not sure what's wrong with your IDE, I've found Atom & Thonny work OK but are sensitive to other programs that might be running on your PC, Cura for example will hog the serial ports on a Windows machine & stop them connecting to the pico.
Maybe try a 'for i in range (5)' instead of 'while True' while testing so the program can quit with the IDE connection still working.

I have fixed the issue with the help of some workarounds. Thank you for your help


Insecure Transport for OAuth2 Authentication

2024-11-30T16:02:48+0000:INFO:session_manager:Could not use token from file /tmp/weconnect.token ([Errno 2] No such file or directory: '/tmp/weconnect.token')
Traceback (most recent call last):
  File "/opt/venv/bin/vwsfriend", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/opt/venv/lib/python3.12/site-packages/vwsfriend/vwsfriend_base.py", line 329, in main
    weConnect = weconnect.WeConnect(username=weConnectUsername, password=weConnectPassword, spin=weConnectSpin, tokenfile=tokenfile,
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.12/site-packages/weconnect/weconnect.py", line 114, in __init__
    self.__session.login()
  File "/opt/venv/lib/python3.12/site-packages/weconnect/auth/we_connect_session.py", line 76, in login
    response = self.doWebAuth(authorizationUrl)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.12/site-packages/weconnect/auth/we_connect_session.py", line 253, in doWebAuth
    afterLoginResponse = self.get(afterLoginUrl, allow_redirects=False, access_type=AccessType.NONE)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.12/site-packages/requests/sessions.py", line 602, in get
    return self.request("GET", url, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.12/site-packages/weconnect/auth/we_connect_session.py", line 69, in request
    return super(WeConnectSession, self).request(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/venv/lib/python3.12/site-packages/weconnect/auth/openid_session.py", line 188, in request
    raise InsecureTransportError()
oauthlib.oauth2.rfc6749.errors.InsecureTransportError: (insecure_transport) OAuth 2 MUST utilize https.

Same as #701
Bitte einmal in der App ausloggen und wieder einloggen und die neuen Terms akzeptieren.

Same as #701
Bitte einmal in der App ausloggen und wieder einloggen und die neuen Terms akzeptieren.

This work for me. Thanks!

Please, could you elaborate a bit and if possible answer in english too. I have the same issue and I did not quite catch the comment.

Please logout and in in the Volkswagen app to accept the terms and conditions again.

Even after accept of new terms on login, still this error message.

Restarting the container doesn't help ?
On Fri, Dec 6, 2024, 07:26 AndreasNoj @.***> wrote:

Even after accept of new terms on login, still this error message.
—
Reply to this email directly, view it on GitHub
https://github.com/tillsteinbach/VWsFriend/issues/702#issuecomment-2522316098,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMRTQPKNF5K54LFYJVBGVEL2EFGS7AVCNFSM6AAAAABSYVGRZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRSGMYTMMBZHA
.
You are receiving this because you authored the thread.Message ID:
@.***>

No same issue - when loggin in on the app and on VW website, now always get the screen where I have to accept the "Term and Privacy"

Same issue here. The website and app always ask me to accept the "Terms and Privacy" during the login process, even though I clicked "Accept" the last time I logged in.

I was able to fix it by doing this trick on the VW website:

Change my country to Germany
Log out, then log in again and accept the "Terms and Privacy" (at this point "weconnect-cli" started working again)
Changed my country back to Switzerland
:partying_face: :tada:

I'm not able to change to Germany - the option is greyed out and only UK is available.
Unable to start my vwsfriend container as a result (or at least it starts, but never presents a page)

Same here, I can not change it from Netherlands to any other country.


site is broken

Just to expand on this, and to add some more detail other than "site is broken", it seems that the scraping stopped on or after 27 January 2024.

@KanchiMoe Thank you for explaining the issue, @GDjkhp please when opening an issue, provide the problem description, that helps a lot.
Regarding the issue, it does not seem to have stopped the scrapping

I'll keep an eye on your profiles to see if it pauses again.

It does seem to have started working again (or at least updating the heatmap) within the last day or so. So the issue is resolved now for the most part.

It does seem to have started working again (or at least updating the heatmap) within the last day or so. So the issue is resolved now for the most part.

Well I did some changes here to possible culprits, I hope that helps, working on more reliability 🤞


Automatically generate outlines

This PR is just for comments.  Assuming you like the idea / interface / impl, I can add tests.

This is a great addition. One or two comments about style but with a few tests I'd be happy to merge this in

OK, I'll make that change and write a couple tests.  You may see the author change, since I was mistakenly using my work email.

OK, PR updated.  One change I made to support my use case is to handle arrays of different lengths.  You should decide whether this behavior will break existing usage.  The previous behavior was

Throw an IndexError if the data array was shorter than the outline spec
Silently ignore elements if the data array was longer than the outline spec

I changed the behavior of case 1 to return None; case 2 remains the same.
Also, I have not tested with Python 3.

I think you're correct with the IndexError not making sense. I never really used that functionality so your additions make sense.
Thanks for the contributions and tests. I haven't tested this on Python 3 either. For now it's fine, if someone requests it, I'll look into the issues that might arise.


Related tags

Updates to support related tags display via both the Java and Node tiers.

I'm a bit suspicious of this PR because it changes 40 files. Was this built with up-to-date node_modules?

Or alternatively, @wooldridge can you confirm these changes are all intentional? Maybe that's how many files go into making related tags work, just seems like a lot, but perhaps I'm being naive.

I can claim half of them on the Java + database side.
I'm not sure about the static directory, but it makes sense that these would change when the browser does.

Yeah, I guess there's a reason for all of these changes/additions. :)

Are the java tests not failing for anyone else? Is it just me?

com.marklogic.samplestack.integration.service.RelatedTagsIT > testRelatedTags FAILED
    java.lang.AssertionError at RelatedTagsIT.java:71

No, you are correct, there is a test failure.
I let in a test that was non deterministic with regard to dbload.  I've submitted a commit that disables this test pending the work needed to properly account for empty and full database.

Looks like travis is now happy, yay travis

Re: the large number of files, this includes all the code to make related tags work in the UI (including the popup). This meant updating the explore view and the facetTags directive and creating a new relatedTags directive, and all those file updates get duplicated in the static directory. Looks right to me.

Travis doesn't run Java tests on PRs b/c most of them require ML which isn't available to PRs.  :)

Weren't we discussing making the related tags window bigger? Or was it concluded not to do that?

I'll merge this now and if we want to worry about window size we can do so in a later commit.

Merged as of 10073e03bde78d909cd2d0df01ee9557430db2f5


Invalid URL 'None': No scheme supplied. Perhaps you meant https://None?

Expected Behaviour
When calling enable_organizations_trusted_access like in https://github.com/superwerker/superwerker/blob/main/templates/backup.yaml#L505 the trusted access should be enabled automatically.
Actual Behaviour
Currently the call in https://github.com/superwerker/superwerker/blob/main/templates/backup.yaml#L505 fails with the named error.
I was able to hunt it down to the following:
[DEBUG]	2023-07-21T11:21:05.264Z	1e2e9abc-bb04-418c-b8fd-c86193146098	Getting url :None with arguments : {'url': None, 'headers': {'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8', 'Accept-Encoding': 'gzip, deflate, br', 'Accept-Language': 'en-US,en;q=0.5', 'Connection': 'keep-alive', 'Upgrade-Insecure-Requests': '1', 'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:73.0) Gecko/20100101 Firefox/73.0', 'Cookie': 'aws-account-data=%7B%22marketplaceGroup%22%3A%22AWS%22%7D; ....., 'allow_redirects': False}
Also it was possible to extract the URL before and I assume the problem is to extract the headers from oauth at https://github.com/schubergphilis/awsapilib/blob/main/awsapilib/authentication/authentication.py#L456
Current Workaround
None

Hi @CptMo , thanks for reporting!  Many things have changed from aws side and I have fixed all the high level authentications on a working branch. Stack sets are also fundamentaly changed and I need to implement the new x-amz cookies also which is a work in progress. I will fix this but it takes some time since I cannot invest too much of focus time on this. I will keep this issue up to date with progress.

It seems that aws implemented the activation and deactivation of trusted access via Organizations for boto3.
See here:

https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cloudformation/client/activate_organizations_access.html
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cloudformation/client/deactivate_organizations_access.html

This would make this feature obsolete I assume?

As mentioned by @aperovic-idealo this issue is resolved by using boto3. Thanks @costastf for digging into it anyway 💯


Import Error: couldn't import GaussianNoise from stochastic.noise

Bugs: import Error:
couldn't import GaussianNoise from stochastic.noise
stochastic has change its package structures, for the new version, we need to import like this:
from stochastic.processes.noise import GaussianNoise
from stochastic.processes.continuous import FractionalBrownianMotion

i think that can close this


Category change for SlackBridge

I think that right category is "Integration" not "Import".

Also adding info about Jira integration.
PS: Sorry for spam.

Still no review??

@marceloschmidt as most familiar with slackbridge, can you take a look?

Actually disregard.  The bulk of this is Jira which looks fine.
The slack re-categorization idk if I agree with.  It's currently not in Rocket.Chat treated as an integration.  Its more of an import / export as it's importing messages into rocket.chat

@geekgonecrazy  Okey, I revert category change for Slack-bridge.


gitfile api

GitFile can use query string? my gitlab only work in ?file_path=

Not sure if I understand your issue. The GetFile method is a GET call that uses query strings. See here for more info...

Closing this issue due to a lack of response...