To clarify, #84735 is NOT a proper solution. I started that PR so we can at least avoid similar failures in torchbench. But there's probably some sharp corner in our tracing that we should get it properly fixed.


I still think y'all should be using TorchRefsMode to do decompositions...


hahaha, you are probably right from the beginning. But I don't know enough to comment on this, I'll let @IvanYashchuk make the right call~~


Here's what really happens:

py
import torch
from torch._prims.context import TorchRefsMode
a = torch.randn(3, 3, device='cuda')
b = torch.randn(3, 3, device='cuda')

def func(a, b):
 return a.to(b)
with TorchRefsMode():
 func(a, b)

py
RuntimeError: prims::convert_element_type() Expected a value of type 'int' for argument 'dtype' but instead found type 'Tensor'.
Position: 1
Value: tensor([[-0.0440, -0.6463, -1.2029],
 [ 0.8581, -0.1144, -0.2697],
 [ 0.3353, 0.1361, -1.8018]], device='cuda:0')
Declaration: prims::convert_element_type(Tensor a, int dtype) -> Tensor
Cast error details: Unable to cast Python instance to C++ type (#define PYBIND11_DETAILED_ERROR_MESSAGES or compile in debug mode for details)

It's not a problem with `TorchRefsMode()` it's a problem with `torch._refs.to`. There are tests that are supposed to verify calling `tensor.to(tensor)`:
 URL
And there's an issue for implementing this: URL

Closing as duplicate.


This is the log from the first TX I saw in the logs: URL

Its about 400 lines. Not sure which part of this is helpful for debugging in the normal case, beyond `txhash, stdout, stderr`. We can get the remainder of events & log from querying the txhash, but I don't see how this helps the standard case


I also am suspicious that this is where the big speedup will come from, vs block time changes

Its a bit hard to see right now due to #2653 , but my recollection from before was that the time from traces looked to mostly be in waiting for blocks to occur.


@kevinstephano The majority of decomps could be applied via the decompositions table that proxy tensor tracing respects (or you can apply yourself in a TorchDispatchMode). The key is that the decomposition happens later; instead of forcing yourself to accurately handle all Python frontend quirks, you can decompose after it's gotten through the Python arg parser and gotten normalized.


PrimTorch targets implementing references for all Python frontend quirks. And we are working towards supporting PrimTorch.

There's a nice feature that for operations that overlap in ATen and Python's PyTorch it's possible to register the reference implementations to the decomposition table of `torch._decomp`. So that TorchDispatchMode users can benefit from increased PrimTorch coverage of references.
 URL

The requirement to support aten->refs mapping is a temporary workaround because backward rules are not yet implemented for prims and AOT Autograd produces a graph with `torch.ops.aten` calls by default. Soon when prims gain backward support we won't need aten->refs mapping.

Thank you, I've heard multiple times how targeting internal ATen CompositeExplicitAutograd functions is great. I will stick with PrimTorch though, supporting Python's user-facing interface, and I will not pivot towards making "ATen CompositeExplicitAutograd" (`torch._decomp.decomposition_table`) the primary target for nvFuser execution.


Yes, this is not useful at all for regular cases. However, the goal here is to log so that we can see the reasons for failure _when it fails_

This is exactly the problem - it is hard to tell when a transaction is successful and when it is not **in a general way**

Off the top of my head, the problems are:
- success is sometimes logged to stdout, other times in stderr
- Some CLI commands log "error" to the output when they are successful so it is non-trivial to do some regex/pattern matching.

I'm open to investigating identifying the tx fails more. However, from my previous attempts, there are quite a few edge cases to work around. I can try looking into this again after v12


Looks like there's some example of how `var.X` overloads are handled in refs. I'll follow that pattern and get overloads of Tensor.to plumbed through.


From Slack: @frankmcsherry notes that a good litmus test for `pgwired` is whether it allows us to efficiently support Fivetran ingest. The gist is that Fivetran ingest would require handling many large `COPY FROM`, `INSERT`, and `SELECT` statements. See URL for details.


Noting that performance of Fivetran ingest will be bottlenecked on `environmentd` until we tackle #14568.


Once we have the tasks system, all other domains should not have any kind of background processing implemented, they should delegate ALL of that functionality into the tasks system.


As mentioned, 5 days ago, I re-created the secret value, but the error was still showing, and the app was failing. The app continued to fail until this morning when it started working.
I don't know what to say but thank you for your help!


With URL done, we can simplify our build process to add more components easier.


@jeffhoerle discussed at *9_12_22 8am workflow* with @lzim

@jeffhoerle - @lzim is wondering if you can help us troubleshoot this bug. We could use 2pm workflow meeting to discuss or we can resolve asynchronously.

@dlkibbe we moved this bug to the research bug tracker (issue num)


The commit that introduced 16.17 into nodejs is 6e2536f1b09863e984f0479ea4b162e4fe86493d.

To use it, one must use `nodejs-16_x` as `nodejs` will be `18.9.0` which may have some major differences.

I'm going to try the latest master commit and see how we go. This will impact all of the nix-derived dependencies.


The task management is ready. However integration into discovery and nodes domains is being done in #445.

Priority management is static, we won't bother with dynamic priority in URL before we see it be a problem.

Issue description here is still relevant to #445, since it contains notes on how best to refactor the discovery system.


Seems like a good first issue to try.
Do you mean moving the values for the key `tests_results` or `historical_test_results` if values exist under the first nesting level (`Main`, `Community`, `Extensions`, etc)?


@mman Could you open a PR from your `spm` branch, so others can see the diffs you had to do to get it work and build upon it?


With the introduction of `allowed-chars-pattern` ( URL we could, instead of removing `setPreventInvalidInput`, re-define it to toggle the usage of an allowed-chars pattern pre-populated with chars valid in an email address. That way the Email Field would prevent users from entering characters that are invalid in emails when `setPreventInvalidInput` is true.


@kbrandwijk @trevordunn @solarisn @Jigalag @hasunperera
Same issue here on expo-cli 6.0.5

expo prebuild --clean
Warning! Your git working tree is dirty.
It's recommended to commit all your changes before proceeding, so you can revert the changes made by this command if necessary.

✔ Would you like to proceed? … yes

✔ Cleared android, ios code
✔ Created native projects | gitignore already synced
⚠ Skipped Metro config updates:
› Existing Metro config found; not overwriting.
› You will need to extend the default @expo/metro-config in your Metro config.
 Learn more: URL

✔ Updated package.json and added index.js entry point for iOS and Android
y🧶 Using Yarn to install packages. Pass --npm to use npm instead.
✔ Installed JavaScript dependencies 1557ms
✖ Config sync failed
[ios.dangerous]: withIosDangerousBaseMod: Could not locate a valid AppDelegate at root: "/Users/XXX/Documents/projects/project"
Please report this as an issue on URL
UnexpectedError: [ios.dangerous]: withIosDangerousBaseMod: Could not locate a valid AppDelegate at root: "/Users/XXX/Documents/projects/project"
Please report this as an issue on URL
 at getAppDelegateFilePath (/Users/XXX/Documents/projects/project/node_modules/expo-screen-orientation/node_modules/@expo/config-plugins/src/ios/Paths.ts:26:11)
 at Object.getAppDelegate (/Users/XXX/Documents/projects/project/node_modules/expo-screen-orientation/node_modules/@expo/config-plugins/src/ios/Paths.ts:63:20)
 at /Users/XXX/Documents/projects/project/node_modules/expo-screen-orientation/plugin/build/withScreenOrientation.js:39:63
 at action (/Users/XXX/Documents/projects/project/node_modules/expo-screen-orientation/node_modules/@expo/config-plugins/src/plugins/withMod.ts:214:29)
 at interceptingMod (/Users/XXX/Documents/projects/project/node_modules/expo-screen-orientation/node_modules/@expo/config-plugins/src/plugins/withMod.ts:100:27)
 at action (/usr/local/lib/node_modules/expo-cli/node_modules/@expo/config-plugins/src/plugins/withMod.ts:228:14)
 at interceptingMod (/usr/local/lib/node_modules/expo-cli/node_modules/@expo/config-plugins/src/plugins/withMod.ts:108:21)
 at interceptingMod (/usr/local/lib/node_modules/expo-cli/node_modules/@expo/config-plugins/src/plugins/withMod.ts:108:21)
 at action (/usr/local/lib/node_modules/expo-cli/node_modules/@expo/config-plugins/src/plugins/createBaseMod.ts:82:21)
 at interceptingMod (/usr/local/lib/node_modules/expo-cli/node_modules/@expo/config-plugins/src/plugins/withMod.ts:108:21)


ForgeRock is seeking clarification. This article URL states that:

"As described, the DH would allow the request but accept the client registration with the subset of scopes the DH supports per RFC7591"

However, this RFC does not state that subsets of scopes should be supported during Dynamic Client Registration. It states:

"The semantics of values in this list are service specific. If omitted, an authorization server MAY register a client with a default set of scopes."

This comment appears to indicate that either a precise set of scopes be requested during DCR, or none at all.

RFC7591 does point to RFC6749 [ URL which allows subsets, but as RFC6749 pertains to authorization, not registration, this is seen by ForgeRock as irrelevant.

Question
Has this change proposal been backed by the OAuth2.0 standard? (and could you please point me to the document, or perhaps point out any misunderstanding of the above document/s?) Or has CDR requested a change to the standard to allow vendors to enable our customers to support the approach?


I've got this issue too, on 2.5.5. Hour recording is about 2m50s out.
@kurjajuur666 did you simply install 2.5.4 using the script, or use a fresh OS install?


Thanks, if you find some time, could you resolve the conflicts, so that these show the latest state compared to the target branches?


@dhruvshettty Hey! Thank you for interest in this issue!

I mean remove `historical_test_results` field from `members.json` and move it to separate file. Probably separate file structure will be something like

json
{
 "1": {
 "repo_url": ...,
 "historical_test_results": [...]
 }
}


That's interesting and a good lead. Thanks for letting us known, I'll forward that internally.


`Boolean('ontouchstart' in window || window.TouchEvent || window.DocumentTouch && document instanceof DocumentTouch)` returns true in the current Chrome (Version 105.0.5195.125) on my old MacBook Pro, which doesn't have a touch screen. The new behavior is unacceptable to me, so I will have to stay on v4.2.2. 😕


Hi everyone, @ricky641b will give it a shot to add full SPM support.

Luckily he can build on the PRs and investigations already done by you.

Let's support him with whatever questions he may have, to get this over the finish line - thanks especially to @mman, @drdaz!


@WPringle, I have a technical question. Why is the Courant number calculation in the referenced text from OceanMesh2D calculated with an additional $\sqrt{g H}$? Is this some kind of *corrected* Courant number for shallow water equation?


Yes. Courant number can be calculated from the characteristic velocity: |u| + sqrt(gh). Here, u is the particle velocity which is unknown but from linear wave theory can be approximated as H*sqrt(g/h), where H is wave height. Now here we just assume wave height of 1 m, but that this could be different. However, generally have found this restriction to work pretty well. Now overland we use a 1 m minimum depth (h). In doing so we have 1*sqrt(g/h) = sqrt(gh) = sqrt(g), i.e., a Froude number (=u/sqrt(gh)) of 1 is the restriction. Perhaps a Froude number of two could be a more conservative restriction for overland flow in which case setting H=2 would work well.


I'm taking a look at the changes in #15149 - I'll let you know if I can figure out the cause. The difference seems to be surprisingly larger.

@mokazemi thanks for reproducing on the demo server - I'll be able to grab the data and logs from your meeting to help debug.

One of the changes made in #15149 was switching from using the "movie" filter input to read video files to using separate inputs to the ffmpeg command. My current theory is that a mistake was made in this conversion, and the seek point calculation is not being done correctly.


I have reprocessed the recording URL with the fix from #15702 manually applied on the test server. If you clear your browser cache and reload, you'll see that the correct portion of the screenshare video is now showing.


Notes:

- cocoapods and carthage support can (or even should) be dropped when implementing SPM support. We are implementing SPM support because they actually don't work anymore in some scenarios. SPM solves this. Removing carthage & cocoapods should also make it easier for you to implement SPM, because it reduces the code base.

- The ParseFacebookUtils are required. The SPM implementation must make it optional to install it though, since not everyone may need it. Same with ParseTwitterUtils.


We'd need to update `update_collection_metadata` to either:

1. Just set a new `publication_policy` field
2. Store the entire response from Pelican, so that we don't need to re-process old collections to get additional metadata


From Housecroft 'Introduction to Molecular Symmetry'
image

A quick look at other sources confirms that you are right and the table in pyscf is wrong.


Had the issue using vercel.

Removed `yarn.lock`, `package-lock.json` and used yarn. Dependencies fetching is now working.


Any updates on that? It seems like #843 is related to this.
We are more interesting in query params right now, will a PR will be accepted here?


I am getting this error on RN v0.70.1 with new architecture and fabric enabled. I have installed `3.0.0-rc.2` version of reanimated. Tried re-install node_modules, and pods. Also tried deleting pod lock file and cleaning build from XCode, but didn't help. @tomekzaw


@fawad-khalil Can you try removing `ios/build` folder of your app?


we also have the delay Problem since 2.5.5. Sometimes it happens in meetings with only two users and some times with more.


@kepstin, @mokazemi is the mentioned fix only for the building process of the recording or would it also fix the audio/video delay problem during the video conference? Since 2.5.5. we are facing delay problems during video conferences. Video is behind audio.


If I'm not mistaken, BBB deletes raw files of the recordings after 14 days, but for recordings in the last two weeks, you can rebuilt them again after applying the fix.
I don't have any ideas for recordings older than that (Maybe repairing by a video editing software to sync with audio)


yes rebuilt would work for recordings. The other problem we have is during video conferences. After one time the video and audio of a user is getting out of sync. There is a issue reported also here: URL
My hope was, that the above fix would be also the solution for the delay issue during meetings.


We also had that problem but it didn't happen again after:
- syncing the server time (Based on what discussed in #8815)
- Setting these values to `60:120:20` instead of `120` (based ot a suggestion discussed in #15172 But I don't know how it's effective)


@mokazemi Would you be able to do some more testing on your end to see if the audio is out of sync before you make either of those two changes (server time or `60:120:20`, then make one of the changes, and test again.

We would be very interested if you can do a specific before/after comparison of making only those these changes.


I found a workaround for query params:

{{ .MatchContext.URL.Query.Get \"a\" }}

No code change is requires in oathkeeper to support it, just the power of Go templates 💪


Do other cores that read mouse input from RA behave the same? (Like PUAE.)


@TPCollings, can you please get the `feature/cflconstraint` branch and test the newly added functionality? I added some basic tests, but I didn't really test it on a large model. Please let me know if you see any issues so that I can fix before merging. Thanks!
Please see: URL and URL for the new methods. Also you can look at the tests added at URL


@WPringle if you have time at some point can you please take a look at the functions implemented here to see if everything seems right for CFL constraint:
 URL


I'll close this ticket since the other two created (#25 & #26) are going to cover what was discussed here


- HBase should be allowed to use only SQL92, but such unit tests have never existed, nor have antlr4 files that deal with Hbase's proprietary syntax.

- I think this issue is blocked by URL . If you're happy to submit some PRs to push for better unit tests, it may be resolved sooner.


I do not understand the principle of ShardingSphere. May I ask whether using ShardingSphere can achieve seamless interception of agents directly from the bottom layer, or do I need to change the service configuration or code to access the agent layer?


- For a general RDBMS, ShardingSphere Proxy will virtualize a data source, and whether it uses the MySQL dialect or the PostgreSQL dialect depends on your choice. ShardingSphere JDBC does the same, but the dialect used depends on the connected database.

- For HBase, I have the impression that the master branch never existed unit tests. For Apache Phoenix unit tests, everything with NoSQL is a bit unknown.


@kbrandwijk @trevordunn @solarisn @Jigalag @hasunperera Any update on this? we are stuck here.


@IceKhan13 yes please, I'd like to take this up.

This is the format I'm thinking of:

{
 "1": {
 "repo_url": "...",
 "tier": "Community",
 "historical_test_results": [...],
 }
}

I'm choosing to keep the `tier` key since that would help us identify the structure of the JSON. And the number is just a unique ID. If this works, I'll get on with it, else please let me know if there are changes required.


I am also following this issue, because we have these problems in some conferences. We were able to find out that people suffering from high delay, at some time in the conference have had very short connection issues (e.g. high ping or high packet loss). This often was due to an unstable wifi connection. It made us curious, why the problems did not happen with 2.4, but with 2.5.x only.

What was the exact intention of URL

The documentation ( URL states: "The jitter buffer has three params that control its behavior: length, max length, and max drift. Length is the initial size of the jitter buffer in milliseconds. Max length is the upper bound for how big the jitter buffer can grow. [...]"

In the referenced commit, @ffdixon changed the JitterBuffer params from "60:120" (Initial: 60ms, Max: 120ms) to "120" (Initial: 120). Then max is not specified and can grow as big as it wants, or am I wrong? So my understanding is, that when there is no upper bound for the jitter buffer, everything works as expected. But when a client has a temporary problem with its network connection (e.g. wifi unstable), then the jitterbuffer might be increased so much, that there is a huuuge delay.

Thus, I do not understand, why the changes to the jitterbuffer have been made....


Simplest thing to do here is change the default value of the select box and add more emphasis to the consequence of selecting a particular value:

<img width="702" alt="Screenshot 2022-09-21 at 14 38 53" src=" URL

<img width="685" alt="Screenshot 2022-09-21 at 14 38 59" src=" URL


Would need to consider interaction with URL / URL Just-created requests should have the same mechanics as just-published requests.


Would the workaround described here solve/close this issue?
 URL


@dhruvshettty assigned to you! Thank you for jumping on this! You rock! 😄


Thanks for letting me know, for some reason I can't copy my browser version from the settings 😅


Hello. @ffdixon Today I did some experiments on what discussed here.

Here's my investigations:

**1. jitter buffer on `120` vs `60:120:20`**

 a) When it's set to `60:120:20` audio is a little bit cracky in case of packet loss, but there's much unusual delay.

 b) When it's set to `120` everything is normal for good connection. **But when there's packet loss**, There would be much **delay** in sending audio. Such when you make a sound, and after two or three seconds the name is indicated at the top of the screen and it receives to the other side. But the video receives without any delay. So it would be out of sync. consequently, people start interrupting each other.

* NOTE: I wasn't able to simulate packet loss. But it sounds the delay gradually appears in bad connections.
_________
**2. Server clock out of sync**
- First disable ntp with `timedatectl set-ntp no`
- Then change the time a few seconds with `sudo timedatectl set-time`
- Record something!
- Don't forget to enable ntp after experiment with `timedatectl set-ntp yes`

**Result:**
**There was nothing out of sync in the recording.** I'm not sure what was the problem before. Maybe the problem described here has been something else. I'll try to make more investigations if it happened again.


This is exactly what I wrote above. And it all makes sense regarding the issue.

Jitterbuffer will always add a delay, because it is a buffer that can be used when there are very short connection issues.
So you generally want the jitterbuffer to be as small as possible, but as long as it needs to be to overcome connectivity issues. Now, jitterbuffers may be dynamically increased by the application, so people with good connections have low latency, and people with bad connection have higher latency but uninterrupted audio/video.

Problem is: There has to be an upper bound for the jitterbuffer size. It does not make much sense to have a jitterbuffer (= delay) of 4 seconds in real-time communication. Instead, one would accept crackling audio sometimes (especially, if the connectivity issues are only very short, because of wifi or whatever)

So this is why I asked above, why @ffdixon changed the setting with "improving audio" as a commit message. It does not make any sense in my understanding.


I also noticed the delay gets shorter gradually when the connections become stable.
So I think that's somehow a correct behavior. But in some other applications (Like Google Meet) the audio plays slower in bad connection (instead of becoming cracky) and the delay disappears right after the connection becomes stable by playing audio a bit faster.


I opened a pull request to set a maximum jitterbuffer again. We are using "100:250" (100ms default, 250ms max) and it works well. These params are increased compared to the original ones @ffdixon changed (60:120).

Basically, if a client has a bad internet connection, the client will gradually increase the jitterbuffer value to be prepared for future connection problems. Jitterbuffers will always add delay.
This issue here is about people suffering from very sporadic connection problems: Not specifiying a maximum results in huge delays, even if a client has just a very short connection issue.


Hello @lastares

This is a translating issue from the Eclipse side: URL

Probably, we need to find or create a ticket on the Eclipse bug tracker.


Hi @SorooshMani-NOAA, I've got a workshop till friday and am away till Wednesday next week but will do it by the end of next week if that's okay? Thanks again for your help.

Cheers,

Tom


I can confirm that the problem occurs for users with packet loss. During a test meeting where it happened we checked the connection status and saw packet loss at the affected user.


Hi @TPCollings, there's no rush for merge, please take your time :)


You can easily reproduce it with simple loop like:

C++
for (;;)
{
 auto timer = asio::steady_timer{ executor, std::chrono::milliseconds{ 10 } };
 co_await (connection.async_run(endpoint, asio::use_awaitable) || timer.async_wait(asio::use_awaitable));
}


I think traefik can reload it's config more gracefully than that?


It can, via a `watch` parameter. The reload is reasonably graceful, and doesn't need to be churned (unlike nginx).

This PR is pretty old, but could be resurrected easily enough and pretty much completes this.


Thanks for reporting. Aedis was designed to provide built-in timeouts. The call to

co_await (connection.async_run(endpoint, asio::use_awaitable) || timer.async_wait(asio::use_awaitable));

is probably messing around with the internal operations in a way I did not test before. I am considering disabling this type of cancellation unless there is a reason for not doing so. I want to avoid every user implementing timeouts on their side over and over again. For all possible timeouts see URL


Timeout here is just for demonstration, I'm not using timers like that I just cancel the connection for other reasons.
Point is that async_run is not can cancellable properly.


How are you cancelling, with `connection::cancel(operation::run)`? Do you observe the same behaviour if you cancel like this

timer.async_wait(&{conn.cancel(operation::run)})

I will investigate this issue on the weekend.


Haven't test that, but because I am using it in coroutines, it needs to be cancellable because even if I use current coroutines cancellation slot it will get overwritten by `co_await conn.async_run(...)`


@realnc No, PUAE works perfectly well on that regard, only dosbox-core seems to be affected.


We can confirm, that issues appeared directly after switching from 2.4 to 2.5.4. So we did a check on what changed and came across your jitterbuffer change. We reverted to 60:120 and the problem did not occur anymore. Thus, we had a look at the exact documentation and thought, that it might be a good idea to have the jitterbuffer increased to 100:250, so we are accepting a quarter of a second delay on bad connections. But we do not accept it to grow any further. In worst case this means that there will be crackling audio or some short interruptions. But it turned out that for the majority of the users the connection problems are very very short. So after the connection is OK again, there will be no big delay. This is more satisfying for the users.

Edit: I at first wrote with my personal account. This is why I deleted my first message here.


@emilymetcalf114 & @lzim
Discussed at **hq_workflow** 09/22/22

#adjucate_memo
Discussed how much time this took for our **IIR Aim 3 Costing**

@dlkibbe & @jwklocek
_How much time do you think this bug took you two work on (thank you 🙏🏽 !)?_

We want to track your effort for @claradismuke 's work on costing.


My estimated time is 1.25 hours from first discovery to my email last night.


#adjudicate_memo
@emilymetcalf114 and @lzim discussed at **hq_workflow 9/22**
adjusted the effort to 9 story points divided between the facilitate team. support_workflow story points tracked on #430.


good to see this crazy conversation still going after 2 years

its amazing to me that something so basic as module resolution continues to be one of the most frustrating things about the nodejs ecosystem

I cannot wait for deno to gain more traction and put this issue to bed by enforcing esm

to the TS team, listen to your users and add a compiler flag


@MCUdude

Now that you have access to the ATxmega256A3BU Xplained board, please take a look at this one and #404 when you got a chance. Thanks.


@kbrandwijk yes, but it was causing the same issue, but I was able to fix the error by following these steps, not sure which step fixed it though,
1.) Upgraded MacOS to the latest version (MacOS Monterey 12.6)
2.) Completely removed Xcode and all the other files
3.) Restarted the machine
4.) Installed latest Xcode 14.0 from app store
5.) Installed other dependencies from the Xcode app (Xcode 14.0 command line tools)
6.) Upgraded expo-cli to latest (version 6.0.5)
6.) Restarted the machine
After following these steps, above error disappeared and was able to run the expo build for IOS successfully. (expo run:ios) @trevordunn @solarisn @Jigalag


I can't reproduce the crash with this

#include
#include

#include
#include
#include
#include

namespace net = boost::asio;
using namespace net::experimental::awaitable_operators;
using aedis::endpoint;
using connection = aedis::connection<>;

net::awaitable reconnect(std::shared_ptr db)
{
 net::steady_timer timer{co_await net::this_coro::executor};
 for (;;) {
 timer.expires_after(std::chrono::milliseconds{10});
 endpoint ep{"127.0.0.1", "6379"};
 co_await (
 db->async_run(ep, net::use_awaitable) ||
 timer.async_wait(net::use_awaitable)
 );
 std::cout (ioc);
 net::co_spawn(ioc, reconnect(db), net::detached);
 ioc.run();
}


The crash on line `: ~/third_party/aedis/include/aedis/detail/connection_ops.hpp:536` is not possible on a normal cancellation. I am afraid this is indicating a buffer overflow somewhere in your program. Can you please enable sanitizers? For example, I get a crash if I use

 co_await (
 db->async_run({"127.0.0.1", "6379"}, net::use_awaitable) ||
 timer.async_wait(net::use_awaitable)
 );

instead of

 endpoint ep{"127.0.0.1", "6379"};
 co_await (
 db->async_run(ep, net::use_awaitable) ||
 timer.async_wait(net::use_awaitable)
 );


I compiled xboot for ATxmega256A3BU, and I'm able to communicate with Avrdude using the bootloader:

$ ./avrdude -cavr109 -p atxmega256a3bu -b 115200 -P /dev/cu.usbserial-1410

Connecting to programmer: .
Found programmer: Id = "XBoot++"; type = S
 Software Version = 1.7; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=512 bytes.

Programmer supports the following devices:
 Device code: 0x7b

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9843 (probably x256a3bu)

avrdude done. Thank you.

I can also read from flash:

$ ./avrdude -cavr109 -p atxmega256a3bu -b 115200 -P /dev/cu.usbserial-1410 -Uflash:r:-:I

Connecting to programmer: .
Found programmer: Id = "XBoot++"; type = S
 Software Version = 1.7; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=512 bytes.

Programmer supports the following devices:
 Device code: 0x7b

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9843 (probably x256a3bu)
avrdude: NOTE: Programmer supports page erase for Xmega devices.
 Each page will be erased before programming it, but no chip erase is performed.
 To disable page erases, specify the -D option; for a chip-erase, use the -e option.
avrdude: reading flash memory ...

Reading | ################################################## | 100% 26.46s

avrdude: flash is empty, resulting file has no contents
avrdude: writing output file
:00000001FF

avrdude done. Thank you.

However, I'm not able to write:

$ ./avrdude -cavr109 -p atxmega256a3bu -b 115200 -P /dev/cu.usbserial-1410 -Uflash:w:/Users/hans/Downloads/XMEGA_A3BU_XPLAINED_DEMO1.hex:i

Connecting to programmer: .
Found programmer: Id = "XBoot++"; type = S
 Software Version = 1.7; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=512 bytes.

Programmer supports the following devices:
 Device code: 0x7b

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9843 (probably x256a3bu)
avrdude: NOTE: Programmer supports page erase for Xmega devices.
 Each page will be erased before programming it, but no chip erase is performed.
 To disable page erases, specify the -D option; for a chip-erase, use the -e option.
avrdude: reading input file /Users/hans/Downloads/XMEGA_A3BU_XPLAINED_DEMO1.hex for flash
avrdude: writing 35062 bytes flash ...

Writing | # | 1% 0.00s ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;

...

 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
 ***failed;
Writing | ################################################## | 100% 0.10s

avrdude: 35062 bytes of flash written
avrdude: verifying flash memory against /Users/hans/Downloads/XMEGA_A3BU_XPLAINED_DEMO1.hex

Reading | ################################################## | 100% 3.46s

avrdude: verification error, first mismatch at byte 0x0000
 0xff != 0xec
avrdude: verification error; content mismatch

avrdude done. Thank you.


Hi @timharek and @mrlinuxfish, thank you for your reports.

Is it possible a popped out window of the extension was open or Bitwarden was open in the Firefox sidebar? If one of those were the case then this has previously been reported with URL

If not, then it's possibly a duplicate of URL

Please close this issue, if its a duplicate to one of the mentioned issues.


It turns out that I forgot to add the `-e` flag. Now I can get the bootloader to work. I'll try with a bigger file soon.

$ ./avrdude -cavr109 -p atxmega256a3bu -b 115200 -P /dev/cu.usbserial-1410 -e -Uflash:w:/Users/hans/Downloads/XMEGA_A3BU_XPLAINED_DEMO1.hex:i

Connecting to programmer: .
Found programmer: Id = "XBoot++"; type = S
 Software Version = 1.7; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=512 bytes.

Programmer supports the following devices:
 Device code: 0x7b

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9843 (probably x256a3bu)
avrdude: erasing chip
avrdude: reading input file /Users/hans/Downloads/XMEGA_A3BU_XPLAINED_DEMO1.hex for flash
avrdude: writing 35062 bytes flash ...

Writing | ################################################## | 100% 4.29s

avrdude: 35062 bytes of flash written
avrdude: verifying flash memory against /Users/hans/Downloads/XMEGA_A3BU_XPLAINED_DEMO1.hex

Reading | ################################################## | 100% 3.46s

avrdude: 35062 bytes of flash verified

avrdude done. Thank you.


@mcuee I can confirm that there's an issue writing to addresses above 128kiB.

$ ./avrdude -cavr109 -p atxmega256a3bu -b 115200 -P /dev/cu.usbserial-1410 -e -Uflash:w:0x55_256kib.hex

Connecting to programmer: .
Found programmer: Id = "XBoot++"; type = S
 Software Version = 1.7; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=512 bytes.

Programmer supports the following devices:
 Device code: 0x7b

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9843 (probably x256a3bu)
avrdude: erasing chip
avrdude: reading input file 0x55_256kib.hex for flash
avrdude: writing 262143 bytes flash ...

Writing | ################################################## | 100% 31.83s

avrdude: 262143 bytes of flash written
avrdude: verifying flash memory against 0x55_256kib.hex

Reading | ################################################## | 100% 25.66s

avrdude: verification error, first mismatch at byte 0x1ffff
 0xff != 0x55
avrdude: verification error; content mismatch

avrdude done. Thank you.


Thanks for the reply!

No, I regularly quit my browser and this happens every time now. It may be a duplicate of #3274, but I don't know for sure.


So any solution so far making Reanimated to work with Fabric?

screenshot


Hey, Reanimated works with Fabric. If it doesn't work for you in your app, this is probably an issue with your configuration or setup.

@shahmeer-ali Have you tried any steps that worked for other people?
- URL
- URL


I can reproduce the with your code here, it takes a lite time to happen (most of the times under 60 sec). some times it leads to that assertion fail some times dead lock.
Try change the time form 10ms to 6ms it happens faster.
And of course make sure you are in debug build.
Changing timer to something low like 1ms leads to a new assertion fail:
`test: ~/third_party/aedis/include/aedis/detail/net.hpp:101: void aedis::detail::resolve_op , boost::asio::basic_waitable_timer >::operator()(Self &, std::array , boost::system::error_code, boost::asio::ip::tcp::resolver::results_type, boost::system::error_code) [Resolver = boost::asio::ip::basic_resolver , Timer = boost::asio::basic_waitable_timer , Self = boost::asio::detail::composed_op , boost::asio::basic_waitable_timer >, boost::asio::detail::composed_work , boost::asio::detail::composed_op >, boost::asio::detail::composed_work , boost::asio::detail::composed_op >, boost::asio::detail::composed_work , boost::asio::detail::awaitable_handler , void (boost::system::error_code)>, void (boost::system::error_code)>, void (boost::system::error_code, boost::asio::ip::basic_resolver_results )>]: Assertion (!ec2)&&("resolve_op: Incompatible state.")' failed.`


@realnc Also, I have been playing around with all core-specific options related to mouse handling, and they make no difference: mouse seems to be trapped inside certain regions.
Do you have a Wayland system you can test this on?


The second assertion you found is something I thought was impossible to happen but does not represent a pre condition for my code to work. I will remove it since it can indeed happen. Thanks again for reporting.


This commit URL fixes the problems I could reproduce so far. There is still a problem though if use very short timeouts like 1ms, in this case it seems that the cancellation gets lost. I will have to investigate more.


@djsmith85 I have closed my browser a few times and I definitely don't have bitwarden open in the sidebar or a floating window


Are you using the same commit that I mentioned in first comment?
here is another assertion fail:
`
test: ~/third_party/aedis/include/aedis/resp3/detail/exec.hpp:133: void aedis::resp3::detail::exec_with_timeout_op , boost::asio::basic_waitable_timer , aedis::adapter::detail::general_aggregate >>, boost::asio::dynamic_string_buffer , std::allocator >>::operator()(Self &, std::array , boost::system::error_code, std::size_t, boost::system::error_code) [AsyncStream = boost::asio::basic_stream_socket , Timer = boost::asio::basic_waitable_timer , Adapter = aedis::adapter::detail::general_aggregate >>, DynamicBuffer = boost::asio::dynamic_string_buffer , std::allocator >, Self = boost::asio::detail::composed_op , boost::asio::basic_waitable_timer , aedis::adapter::detail::general_aggregate >>, boost::asio::dynamic_string_buffer , std::allocator >>, boost::asio::detail::composed_work , boost::asio::detail::composed_op >, boost::asio::detail::composed_work , boost::asio::detail::awaitable_handler , void (boost::system::error_code)>, void (boost::system::error_code, unsigned long)>]: Assertion (!ec2)&&("exec_with_timeout_op: Unexpected completion order.")' failed.
`

Maybe using the following code helps to reproduce it faster:

C++

#include
#include

#include
#include
#include
#include

namespace net = boost::asio;
using namespace net::experimental::awaitable_operators;
using aedis::endpoint;
using connection = aedis::connection<>;

net::awaitable
reconnect()
{
 auto executor = co_await net::this_coro::executor;
 auto db1 = connection{ executor };
 auto db2 = connection{ executor };
 auto db3 = connection{ executor };
 auto db4 = connection{ executor };
 auto timer = net::steady_timer{ executor };
 for (int i = 0;; i++)
 {
 timer.expires_after(std::chrono::milliseconds{ 10 });
 endpoint ep{ "127.0.0.1", "6379" };
 co_await (db1.async_run(ep, net::use_awaitable) || db2.async_run(ep, net::use_awaitable) ||
 db3.async_run(ep, net::use_awaitable) || db4.async_run(ep, net::use_awaitable) ||
 timer.async_wait(net::use_awaitable));
 std::cout << i << std::endl;
 }
}

int
main()
{
 net::io_context ioc;
 net::co_spawn(ioc, reconnect(), net::detached);
 ioc.run();
}


if someone is using yarn monorepo I suggest adding it to the main package.json file


If someone is using yarn workspaces I suggest adding it to the main package.json file. The children package.json files did not work for me.


The feature is supported by commits: 5ab59ef592826f91b59484a86072cc35b2e8d699, 357e7d37961f589278159cc9bff6fe9369cf4db7.


Renamed the title of this issue, it was created a long time ago when our understanding of JetBrains Gateway was just forming. We can see now the opportunity to focus on Maven for the time being to get the Prebuilds and opening IDE experience working really well. I'll scope this issue down now to just Maven. However, we'll come back and open a companion issue for Gradle also in time. Learnings from integrating Maven fully with Gitpod will then also carry over.


It looks like the frontend is updated to vue as well in v18.2.0


Thanks for the report.
I have no clue yet. Does it happen on Windows or Linux (X11, Wayland / Gnome or another WM)?


Ah, sorry, forgot to add.

`Linux`, `X11`, `i3-wm`, built from latest `master`.


When we tried to look for /run/.containerenv in Nieves' toolboxes, we could not find it, so there may be some unreliability in what podman does. The documentation sounds like the file may depend on the --privileged flag. That might be another reason for having our own marker file that is always there.


We do already have an empty `/run/.toolboxenv` to identify Toolbx containers that sits next to the more generic `/run/.containerenv` added by Podman.

If it's only a matter of filtering Toolbxes from other Podman containers, then `/run/.toolboxenv` should work. eg., it's already used in `/etc/profile.d/toolbox.sh`.

Currently, `/run/.containerenv` inside a Toolbx container looks like:

engine="podman-4.2.0"
name="fedora-toolbox-36"
id="f030bfbfa089c191ab617f12d66a407e712b0e2b0c5a2f8dc5bced1dc0fbd1e2"
image="registry.fedoraproject.org/fedora-toolbox:36"
imageid="a68a838b182ac44d4d53330bbe3aa49f9a7239f420bea22a8650f765ac4c1a9c"
rootless=1
graphRootMounted=1

Do we only need a way to identify a Toolbx? Or do we need some more information? We could request Podman to add some more metadata bits to that file.


That's odd.

What about the `Annotations` and `CreateCommand` in the `podman inspect --type container ` JSON? Do they contain `privileged`?

I have:

$ podman inspect --type container fedora-toolbox-36 | grep privileged
 "io.podman.annotations.privileged": "TRUE",
 "--privileged",

A `/run/.containerenv` file should always be there, regardless of whether the container was created with `--privileged` or not. The `--privileged` flag decides whether the file would be empty or have some metadata in it. That's because people were worried about potential security problems caused by the information leaking out through the `/run/.containerenv` file.

Toolbx containers are always created with `--privileged`, so they should always have a non-empty `/run/.containerenv`.


By the way, the `/run/.toolboxenv` file is mentioned in the `podman-create(1)` manual under *Container Configuration*.

There's also the `com.github.containers.toolbox` label for identifying Toolbxes from the host, which is used by `toolbox list`.


Thanks, I'll ask Christian Hergert to chime in here with what, if anything, would be useful for him.


I think toolbox is the easier of situations to solve, at least when it comes to sysprof symbol decoding. If we know we can rely on access to the file-system, symbol resolving can mostly be a "add this prefix to symbol paths to find the real .so/binary on the host".


@chergert Is other information about the toolbox setup that would be useful to you, that could be included in /run/.toolboxenv ?


Perhaps the location where the host system is mounted, so that we don't hard code things? But honestly, I'm fine with hard coding.

I think I'll know more once we have a prototype to fix symbol resolving though.


I also can't print the layout on OSX and getting the red error message `Error encountered while printing.` without any information why 🤷


This can be added as an optional parameter, yes. I never found it useful personally because I know which channels are sinks and can simply exclude them from the sources (and they usually have less than 50% outbound). The rest rarely move themselves so their fees are more like random rewards I don't count on much. Setting zero fee on those channels doesn't help moving them at all so I just leave it small.


This appears to only be an issue when Organizr and Pi-hole are installed on different hosts. When they're on the same host, and particularly if installed in Docker containers, the TableData JSON errors disappear and so does the problem with the perpetual login screen -- so there's no need to disable the password.

This leaves only the need to change the X-Frame-Options in a way that survives updates, which for Docker installations is addressed here:

 URL


This is a Feature Request.

We receive a high number of requests, but as a free open-source project run by volunteers we have very limited resources.
Please, we ask that you open your Feature Requests at our Discourse Forum.

Thank you for your understanding.

---

**Pi-hole links:**
- Discourse Forum: URL
- Documentation: URL
- Feature Requests: URL


At the moment, it should be fine to hard code `/run/host` as the location where the host filesystem is bind mounted inside the container.

Flatpak has a similar location, but I have heard that `/host` is used in the world of OpenShift.

Regardless, `/run/host` is crucial for Toolbx at the moment. It's even embedded inside the `toolbox` binary.


Thanks!

I think it's probably fine to close this issue now until we have concrete needs for Sysprof/Builder/etc.


Check if the max fee displayed is correct for you. Manually calculate the target channel future income (as `(base_fee + amount * fee_ppm) * econ_ratio`), subtract the source channel fee (as `base_fee + amount * fee_ppm`).


This is really hard to diagnose so can you install flutter and run the app in debug mode? If it still crashes this should give you some error output.


I've got a react app that's being bundled with webpack, and a pure typescript server. The 2 projects share some model classes.

If I import my classes using the standard Typescript syntax `import MyClass from "./model/MyClass"`, I get the "cannot find module ... imported from ..." error.

Alright, fine, I can simply add the ".js": `import MyClass from "./model/MyClass.js"`

... This causes webpack errors "Module not found: Error: Can't resolve './MyClass.js' in "...""

This is infuriating


I have created a new issue to improve cancellation support, see #32 so I will continue there. AFAICS, this ticket can be closed as the crashes have been fixed.


What was the max fee reported for the route? Does it match the formula here? Are you sure you specified the options correctly? Currently unknown options are ignored, I think it should be fixed to prevent mistakes.

The default liquidity limit is 50%, does your source channel have more than 50% balance on your side considering the amount that will be deducted after successful rebalance? If you want to use it no matter what you should specify `--pfrom=100` (or any target above 50) and `--allow-unbalance-from`.


I'm sure I'm missing something... heres an example.

config file is:

{
 "macaroon_dir": "/home/regolancer/.lnd/data/chain/bitcoin/mainnet/",
 "macaroon_filename": "admin.macaroon",
 "network": "mainnet",
 "tlscert": "/home/regolancer/.lnd/tls.cert",
 "econ_ratio": 0.2,
 "amount": 10000,
 "min_amount": 5000,
 "probe_steps": 5,
 "pfrom": 10,
 "pto": 30,
 "stat": "stats.csv",
 "lost_profit": true,
 "exclude_channels_in": [
 ],
 "exclude_channels_out": [
 ],
 "exclude_channels": [
 ],
 "exclude_nodes": [
 ]
}

$ go/bin/regolancer -f /home/regolancer/config.json

2022/10/02 06:53:59 Attempt #2, amount: 10000 (max fee: 0)
Total fee: 1
826396237984169984 [allyourbankarebelongtous|75ch|2.96,267,124sat|035fed4182fbd0725264f8a0018cabb6b25514dd231291162ac8dd63afb278e9e8]
825335209304981506 1000 [Xolotl ⚡ LND|47ch|3.82,000,000sat|033b277b17cf7c70fd4de5cbe8dcaeda0cd63d44fcd680f82f76dcac2ebad10c2f]
825424269808435201 10 [Stone Of Jordan|135ch|13.04,996,386sat|02bce4f7ae5b2d51c18575b3f277e296d9df800a54d749d7a3145c9e40237e4011]
815450599751221249 0 [zero fee routing | CLN|1387ch|84.74,988,554sat|038fe1bd966b5cb0545963490c631eaa1924e2c4c0ea4e7dcb5d4582a1e7f2f1a5]
811015169933639681 0 [Thrash.at|134ch|3.77,192,869sat|03ac61c971d146787a036f75e80a9fbede238a75d0c396f1fe996def00f0ac5dbe]
816899756183846912 251 [Milky*Cilia|230ch|25.15,165,870sat|022a03c83e94ab037a64dd71e54f1796db185f21b1d88ceea5486a274ec257e995]

2022/10/02 06:54:13 Success! Paid 1 in fees

... telegram bot reports I paid 126 ppm to rebalance from allyourbanks (currently I charge 50ppm) to Thrash.at (currently I charge 30ppm)


Yeah, that looks wrong. Do you use the latest version from master? #5 was fixed, when the max fee becomes negative lnd simply ignores this restriction and uses whatever route it finds. In your case it says 0 but if the actual fee is less than 1 sat (and more than -1 sat) it could've been rounded up to zero.


Got it.. Not as familiar w the workings of github, branches/etc… followed this guide with exception of changing version to 1.2.0

 URL

On Sun, Oct 2, 2022 at 7:19 AM, rkfg ***@***.***> wrote:


Yep, could be confusing. Maybe it's better to install with `go install github.com/rkfg/regolancer@master` instead of `@latest`. I'm not good at versioning admittedly 😅. Btw cool guide, I didn't expect someone to write it for my software! Feels extremely rewarding, thanks!


Will give it a try - satsHive did the guide for raspibolt. Thank you

On Sun, Oct 2, 2022 at 7:27 AM, rkfg ***@***.***> wrote:


@master worked! Thank you

Using your suggestions above I also tried -pfrom and --allow-unbalance-from in an attempt to force a rebalance with a max ppm as:

$ go/bin/regolancer -f /home/regolancer/config.json pfrom=100 --allow-unbalance-from --fee-limit-ppm=25 --from=828274203871412225

however it still says no source channels exist... that particular channel has about 50% outbound currently. Am I missing any other required flags/attributes? Thank again


Disregard .... needed --pfrom=100

It works; crazy fast thank you! Will continue experimenting with this


Glad it worked, I also added displaying msat fees, hopefully everywhere they're shown. They look like `0.350` and such, I tried `350msat` but it was lowkey ugly and confusing. And unknown flags should result in descriptive errors now.


I've hit a similar issue on Linux trying to print the layout cards. Hitting `ctrl-P` crashes Chrysalis with:

Crashing due to FD ownership violation:
#0 0x55c46cb0ba93
#1 0x55c46cbb919c
#2 0x55c46cbb9161
#3 0x7fb467d51ef3
Trace/breakpoint trap

- OS: Ubuntu GNU/Linux 22.04 kernel 5.15
- Chrysalis version 0.11.5


So basically, what I think would make sense here:

An optional argument, per consumer, to turn path-prefix-stripping on and off. It should take whatever path prefix it is using for that route and add it to the middleware's list of path's to strip. As an example:

- Jon is instantiating the traefik consumer in his `zinc-k8s` charm.
- Jon is, either implicitly or explicitly, setting the `strip_path_prefix` argument to `True`.
- Traefik adds a route, with the path prefix `/jons-cool-model-zinc-k8s`, resulting in the full routable URL ` URL
- Traefik also adds a strip path prefix middleware for `/jons-cool-model-zinc-k8s`.
- The workload app will no longer have to know that it is being reverse proxied and will continue to work, as long as all of the links it renders are relative.


@TPCollings, I was wondering if you had the chance to test the updates? If not, I can merge them to the `main` branch and you can just test it there whenever you get the chance to.


Hi Soroosh,

Sorry I still haven't had a chance to test this! Yeah probably best to
merge it and I can let you know if there's an issue. Cheers
---------------------------------------------------------------
*Thomas Collings* | *Fathom™*
Developer | www.fathom.global | @fathom_global

wrote:


I never had a locking issue and I can't reproduce.
image
image


In case charms other than 'yourself' are using your address should the 'this address has had its prefix stripped' also be published back to the consumers from the traefik side?

i.e. should traefik publish something like:

-urls:
 unit-0:
 - url: foo.com
 - prefix-is-stripped: false
 unit-1:
 - url: foo.com
 - prefix-is-stripped: true

I guess it's not a use case that different units of the same app have different settings when it comes to prefix-strip, right?

My new nightmare:

python
self.ipu=IPUProvider(self, strip_prefix = bool(int(self.unit.name[-1]) % 2))

Because if not, then this is a non-issue: other applications can't see the addresses traefik is publishing to you.
If yes, then other units might get confused as to how to reach their peers. Or maybe I'm overcomplicating it. Is there a scenario in which this is a problem?


My presumption would be that the charm requesting it be stripped (via a constructor) would "know", and it would be flagged either via a config value or just globally, depending on the charm, so different units with different configs wouldn't be a supported configuration.

In general, the use case here is that a lot of "modern" applications using, say, `net/http` from Go just set up a handler at whatever the path is.

Right now, if an IPU relation is established and the `PathPrefix` is _not_ stripped, it comes into `foo-2` as `/bar-model-foo-2/request`, and the handler says "I don't know about that path, here's a 404" unless each application is also configured with some parameter (depending on the application) specifying what the webroot should be.

Setting _that_ root, though, also means that in-cluster or in-namespace traffic which isn't going through the ingress at all (or even checking some readiness API endpoint on `localhost`) must also have the root appended, and it's a snarl.

This sort-of leads to the entire "ingress isn't ready yet" case, but also means that `foo/0` which is related to IPU and has a metrics endpoint at `/metrics` must immediately reconfigure itself, restart the entire application (probably), update Prometheus with a new path with the IPU prefix prepended, and so on. That kind of cascade effect applies to any application whatsoever conducting HTTP traffic, even traffic which never leads the cluster, and is a potential cascading event storm as long as leaving the prefix is the default.


@luddaniel sorry for the slow response. I'm trying to understand what you're up to. 😄

Does the field have to be custom? Are you simply saying, "I want to know which datasets are not using field x?"

(By "no files" I assume you mean "no documents". Solr calls results "documents".)

If you're concerned about performance, please try querying Solr directly to see if it's faster. The Dataverse Search API does (sadly) add some overhead but I'm not sure how much.

If the SQL queries are working for you perhaps you can make a pull request to make an API endpoint.

What is this tool you've built? 😄 You've piqued my curiosity. 😄

Maybe we can chat in real time at URL some day. You're welcome to join!


I tried again with Chrysalis version 0.11.6 using the print button, unfortunately the issue is still present. The OS print dialogue briefly appears, then the application crashes.


Do anybody care about this issue?
Right now it is not possible to use Async Commands for buttons because the visual state of the button (from CanExecute) may be not correct after showing a DisplayAlert. A showstopper in the moment for MAUI on Windows.....


Hey folks, wanted to give a quick update (as many have asked!). Firstly, thanks so much to all our users who have given feedback in the community for our JetBrains integration. Please continue to do so, we're learning a lot from you and we're able to refine the experience based on your input.

If you're late to the party, I wanted to give a little background and context into Gitpod IDE support and why we've not yet released full support of the IDEs just yet. For background, we have a partnership with JetBrains. In real terms is that we have conversations with the friendly JetBrains people to help input on the future of JetBrains Gateway as a whole and help create a really great remote dev experience with JetBrains in Gitpod and beyond!

Opening up an IDE is only one step in the process to bringing a great developer experience in Gitpod. Whilst a lot of the Gitpod functionality is shared across the JetBrains IDEs, such as prebuild support, integration of Gitpod task terminals, port forwarding and port behaviours. There are also lots of language specific product changes that need to be made in both Gitpod and JetBrains.

**For example:**
* Ensuring coverage of plugins / VS Code extensions for the language - see recently added Oracle support in OpenVSX
* Our documentation support is good - see recently updated Java page
* Integration with build tools for the language - we are working on Maven right now, etc).

For that reason we've been a bit deliberate in how (and when) we roll out other IDE support. We don't want to open up an IDE for our Gitpod users to go try the integration, but then be dissapointed (let's say if some aspect of the integration is not up to the standard they expect, some plugin doesn't work, etc).

**In simpler terms: The quality of the experience is really important to us.**

We just opened up WebStorm and RubyMine (yet to be announced). So hopefully we will get to the remaining IDEs in the coming weeks ! Come join us on Discord, chat about your experience and give us your feedback (we are listening!). We're super excited for what's to come with JetBrains + Gitpod 🙏


same issue from wallet connect modules on my github actions.


did anyone figure out how to fix this when you're on a vercel env, where you can't easily add an .ssh key?
my dependency is coming from wagmi.sh

which i have updated to the latest:

$ yarn why ethereumjs-abi
yarn why v1.22.19
[1/4] 🤔 Why do we have the module "ethereumjs-abi"...?
[2/4] 🚚 Initialising dependency graph...
[3/4] 🔍 Finding dependency...
[4/4] 🚡 Calculating file sizes...
=> Found "ethereumjs-abi@0.6.8"
info Reasons this module exists
 - "wagmi#@coinbase#wallet-sdk#eth-json-rpc-filters#eth-json-rpc-middleware#eth-sig-util" depends on it
 - Hoisted from "wagmi#@coinbase#wallet-sdk#eth-json-rpc-filters#eth-json-rpc-middleware#eth-sig-util#ethereumjs-abi"
info Disk size without dependencies: "456KB"
info Disk size with unique dependencies: "780KB"
info Disk size with transitive dependencies: "13.48MB"
info Number of shared dependencies: 19
✨ Done in 0.22s.


ok so the solution of deleting the git+ssh entry and manually hacking the yarn.lock and reinstalling seems to work.
but how fragile is this?
what are the cases that will cause the yarn.lock to be completely rebuilt?


also, what can we recommend upstream packages to do that depend on this? even tho this package is deprecated as of a year ago, it seems very recent other modules still depend on it.

my deps path:

 - "wagmi#@coinbase#wallet-sdk#eth-json-rpc-filters#eth-json-rpc-middleware#eth-sig-util" depends on it

this issue says in fact that `coinbase/wallet` is the RIGHT thing to use...

 URL


Hi there,
we are very open to do a quick bugfix release on our side if this helps, even if this package is deprecated, I just haven't identified if we can do something on our side.

If you follow-up the dependency path and find the right place where to post the issue "on the other side" feel free to mention me, then we can coordinate on how to fix this and see if we can also do something from the EthereumJS side of things.


thanks @holgerd77 someone tracked the deps tree here for wagmi.
not sure how you could fix it at this end - can you replace the module/version and replace the git with https?

 URL


@tuandq2711
Can you elaborate on the use case you are trying to achieve and current limitation you are facing ?


@darshankawar
Currently on android or ios there is a Ground Overlays section to be able to draw images on the map. But on google_maps_flutter I don't see any to use. I can't add that part by myself so I hope you guys can help me add it.


Quick update PixelFX designed a small flex to fix this issue. I tested it and it work great.
PXL_20220927_000325996

I'll update this issue once info on how to get it is available.


@darthcloud Is this fix the same for both HW1 and HW2? ie for both external and internal (with detection) installs?


@darthcloud If I'm reading correctly, you prefer Dan's flex cable fix to your 74AHCT125N buffer method for electrical reasons?


They are both using 125 buffer, it's same thing except flex look nicer


The benchmark results in #446 means that we do need webcrypto and due to iOS issues, we cannot use wasm. So we have moved to libsodium instead, and the benchmarks show that libsodium is 10x to 50x faster than webcrypto.

We are also going with native `Buffer`, and future usage will just use the `Buffer` polyfill.

There remains 2 uses of webcrypto:

1. bip39 recovery code
2. x509 signing

The first can be replaced with our own KDF mechanism. In that sense, we would no longer use bip39.

The second is a bit more difficult, it may be easier to create a webcrypto shim backed off libsodium and only for ed25519 signing.


Closing this as duplicate of URL Please follow-up in it for further updates.


You can do that if you memoize the selector function. For example `proxy-memoize` does it for you.

js
import memoize from 'proxy-memoize';

const selector = memoize(({ v1, v2, v3 }) => ({ v1, v2, v3 }));

const Component = () => {
 const { v1, v2, v3 } = useContextSelector(Ctx, selector);
 // ...
};


Thx for this quick answer! I must be missing something but, why should I use memoization? Aren't both patterns eqs?


Hi Dong-Ha,

I am sorry for that, just fixed the issue (I assigned updated chrome names to the wrong fields...) URL

Now they are correct.

- Bogdan


Thanks, Bogdan, for the quick response.

Is there anything else updated since July 6th, 2022, other than the renaming of sequence IDs?

 Dong-Ha


Because

js
const { v1, v2, v3 } = useContextSelector(({ v1, v2, v3 }) => ({ v1, v2, v3 }))

will trigger re-renders for any changes (like `v4`).

So, "one call, one value" pattern is the rule we follow. You might be interested in reading #19 discussion.


Hmmm... I'm not sure to perfectly understand why, but I'll be looking for some infos within the linked discussion :+1: Thx a lot @dai-shi !


Assuming you are not talking about custom equality function, `const { v1, v2, v3 } = useContextSelector(({ v1, v2, v3 }) => ({ v1, v2, v3 }))` is not technically easy.
It's not impossible though, and that's what `react-tracked` does.

js
const { v1, v2, v3 } = useTrackedState()

`react-tracked` uses `use-context-selector` under the hood. So, they do different jobs.


I don't use NetworkManager so I wouldn't know, but in the case of systemd-networkd there are relevant options under `systemd.network.wait-online`: `anyInterface` and `ignoredInterfaces`. I recommend at least setting the former to `true` on laptops.

Warning about failed units is pretty much the last thing that the activation script does, so it's probably fine (but the failure should be fixed, of course).


BTW I've "fixed" this by setting

nix
# udev 250 doesn't reliably reinitialize devices after restart
systemd.services.systemd-udevd.restartIfChanged = false;

But this is really an upstream systemd bug.


Hi, we also experienced the delay problem since we upgraded into 2.5.6. I hope URL will be included on 2.5.x soon.


Hi @thibaudcolas I was wondering if this is still open for anyone to work on?


Closed as duplicate of URL

This is the bug from the Eclipse site


This was another issue that caused by the change of behaviour on diff 3.8. I opend a new issue #293 for this.


My vault is also permantly unlocked despite having a vault timeout of "1 minute", and vault timeout action of "Lock". Even pressing on the "Lock Now" does nothing. Wonderful security.

OS: macOS Monterey 12.4
Browser: Firefox 104.0.2
Extension: 2022.9.1


It works for me on (I will edit my message later to add the version of the browser on windows):
Firefox 105.0 + Ubuntu 20.04.5 LTS
Firefox + Windows 10
Edge + Windows 10

Be careful, being arrogant like this may make people not want to help anymore.
Have you tried re-installing the extension?
What about logout as a timeout action, does it work?


Restarting the browser entirely has solved the issue for me. However if its possible to put the extension in this state it seems like a siginificany security vulnerability (hence my sarcastic comment, I apologise for this it was inappropriate).


I had some similar problems before. If I used the browser with a memory-intensive site for a while (sites with unending feeds), my vault wouldn't time-out, the lock-now didn't work, the folders disappeared, etc. After I removed the extension, and reinstalled, all the said problems went away and haven't happened again. Hope this help.


Hello there, is there also a fix planned for UltraHDMI users? I updated to the latest firmware and now the system does not detect the controller at all anymore


Thanks, Bogdan, for responding quickly. I have already submitted a round of runs using genomes renamed ("." -> "__") manually. I will test this fix in the next round and close the ticket when it goes through.

Dong-Ha


@Tipoff4317 thanks for reporting this. Although I haven't noticed my vault in FF _not_ locking for a little while now, I went ahead and uninstalled BW and reinstalled it as suggested. It won't hurt. I'll report back if I see it again. Please do the same. Cheers.


We (3467) are also experiencing the same issue, Windows 11 22H2. Can you post more specific instructions on how to grab the debug info you need?


Follow these instructions: URL

Make sure you use `flutter run` to run in debug mode. I'm assuming this is an issue with the 22H2 update messing up some dependency needed to run. Building manually could potentially install these dependencies and work fine. If that doesn't work you could try installing Visual Studio Community (make sure the "Desktop Development with C++" module is installed with it) which might fix it as well. If all that fails then I don't think there's much I can do besides wait for a flutter update to fix the issue.


Some initial searching led me to this issue: URL

Working on building from source now.


It looks like Bitsdojo Window library was removed in May, but there hasn't been a release since March. Is it possible to send a newer Windows binary over? The Flutter setup is taking quite a while.


After running the latest version with `flutter run` this confirmed my suspicions. The issue was likely bitsdojo_window. I'll build a new version for Windows and post it here for anyone still having this problem.


Yeah that sounds right. Here's the one i built that includes some redistributables that some people might not have so its better to use this one. Keep in mind this version might have unknown issues and pathplanner lib doesn't support all of the functionality if you're using the release version.

PathPlanner-windows.zip


Beat me to it! We'll use this one for now. Thanks for your help.


Hi @SlatsFR, the reference in regards to RFC7591 is towards general dynamic client registration requirements.

The reason for DHs ignoring unsupported scopes is due the the way the CDR Register operates. It issues the SSA signed using the Register CA cert incorporating all scopes an ADR is accredited for. The way the CDR Rules are expressed it means that once a data recipient is accredited, they are accredited for all sectors and hence all scopes across those sectors: right now that is banking and energy. In future that will include telecommunications etc.

To ensure that an ADR can successfully manage their client registration with a DH when they present all scopes (noting that the ADR cannot control which scopes the CDR Register generates for it), the DH needs to facilitate the client registration updates without rejecting the request.

Hope that helps.


## Reproduction
After relating a charm to traefik, its metrics endpoint is not updated and prometheus reports `health: down` because it is no longer reachable via the local ip.

1. am, prom, trfk deployed and all in active/idle.
1. juju relate am:self-metrics-endpoint prom
 - curl 10.1.13.182:9090/api/v1/targets | jq '.data.activeTargets'
 - "scrapeUrl": " URL
 - "globalUrl": " URL
 - "health": "up",
1. juju relate am trfk
 - curl 10.1.13.182:9090/api/v1/targets | jq '.data.activeTargets'
 - "scrapeUrl": " URL
 - "globalUrl": " URL
 - "health": "down",
1. juju run-action trfk/0 show-proxied-endpoints --wait
 - proxied-endpoints: '{"am": {"url": " URL

- update-status didn't help because the lib doesn't automatically observe it for sidecars, and alertmanager didn't pass custom refresh events.

## Proposal 1
Users of MetricsEndpointProvider must be instructed to always set custom refresh events

self.metrics = MetricsEndpointProvider(
 # ...
 refresh_event=[ # needed for ingress
 self.ingress.on.ready_for_unit,
 self.ingress.on.revoked_for_unit,
 self.on.update_status,
 ]

## Proposal 2
MetricsEndpointProvider should always observe update-status by default.

## Proposal 3
MetricsEndpointProvider should update relation data every re-init.
I.e. the contructor MetricsEndpointProvider should call `self._set_scrape_job_spec` every instantiation, instead of registring it as an observer.

Ideas? @dstathis @Abuelodelanada @rbarry82


Hi @ForJessicaSake, yep, I don’t think anyone else has worked on this.


Okay great, I’ll work on it can you please assign it to me 😊 thank you!


I think proposal #3 is preferable by far. It's idempotent, users don't have to do anything at all, it doesn't depend on `update-status-interval` or calling other events, and it can easily be removed from the library constructor when `stripPrefix` middleware lands in traefik, which makes this problem more or less disappear entirely (at least from an in-model/cluster perspective, as well as any external targets which have routable endpoints and don't need a path specified by any reverse proxy).


Tested manually and the combination of:
- URL and
- URL (with the modified prom lib)

solves the issue.

With which charm did you experience this @simskij ? You may need to update charm code:
- fetch-lib for prometheus_scrape
- pass `external_url` to MetricsEndpointProvider
- use correct port number for the job `port = urlparse(self._external_url).port or 80`


Additional information: it might coincide with 100% CPU usage.


I have the same problem, here is what I got after running in debug mode.

Launching lib\main.dart on Windows in debug mode...
Building Windows application...
[ERROR:flutter/shell/platform/windows/direct_manipulation.cc(137)] CoCreateInstance(CLSID_DirectManipulationManager, nullptr, CLSCTX_INPROC_SERVER, IID_IDirectManipulationManager, &manager_) failed
Syncing files to device Windows... 518ms

Flutter run key commands.
r Hot reload. 🔥🔥🔥
R Hot restart.
h List all available interactive commands.
d Detach (terminate "flutter run" but leave application running).
c Clear the screen
q Quit (terminate the application on the device).

💪 Running with sound null safety 💪

An Observatory debugger and profiler on Windows is available at: URL
flutter: ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
flutter: │ RangeError (index): Invalid value: Valid value range is empty: 0
flutter: ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
flutter: │ #0 List.[] (dart:core-patch/growable_array.dart:264:36)
flutter: │ #1 Trajectory.calculateVelocity (package:pathplanner/services/generator/trajectory.dart:187:13)
flutter: │ #2 Trajectory.generateSingleTrajectory (package:pathplanner/services/generator/trajectory.dart:87:5)
flutter: │ #3 Trajectory.generateFullTrajectory (package:pathplanner/services/generator/trajectory.dart:67:30)
flutter: │ #4 RobotPath.generateTrajectory. (package:pathplanner/robot_path/robot_path.dart:79:46)
flutter: │ #5 new Future. (dart:async/future.dart:253:37)
flutter: │ #6 _rootRun (dart:async/zone.dart:1383:47)
flutter: │ #7 _CustomZone.run (dart:async/zone.dart:1293:19)
flutter: ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
flutter: │ 08:10:16.131 (+0:00:01.484156)
flutter: ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
flutter: │ ⛔ Dart Error
flutter: └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Lost connection to device.


It's disappointing that diffutils no longer allows us to exploit the signed integer overflow with `-1` context ... do we just pass `65535` (or some other reasonable guess at `MAXINT`) instead and document our limitations?


Quick note: "omission" has but one "m".

And honestly, this comment has waaaaaaaay too much geeky detail. I don't even think it's necessary to mentioned `-1` or the large numbers. Perhaps merely point out that GNU diff doesn't have a way to indicate that we want all the context so we approximate it using a number sufficiently large enough for most files whose diffs anyone might care to see in a web browser yet small enough to avoid crippling performance.


If it's a loki datasource issue then perhaps it's not related to prometheus_scrape?

Maybe we need to manually call `update_source` in loki?
BTW, `update_source` seems very different from `refresh_event`.
@dstathis @rbarry82


`update_source` is just a superset of `_set_unit_details` which also allows passing additional fields, and was added explicitly for consumers to say "I have an ingress now, so update out-of-band in case `GrafanaSourceProvider._source_url` from the constructor is out of date".

Since Loki already uses the property in the constructor, `update_source` would be called when an ingress is added, yes, which allows setting/updating the Grafana relation data immediately after `ingress_ready` rather than waiting for some other event to re-trigger the constructor. We could do the same thing in `grafana_source` as is done here, but it would make sense from Loki's codebase to add it just after `update_endpoint(...)`, since the semantics are the same. The Prometheus libraries have just obsessively avoiding having any public API at all which could be used for this purpose.


Just tried to run the same application since yesterday and can't get it to start nor the version I built, but running with `flutter run` in debug mode starts fine.


Can `flutter run` build the app without an Internet connection?


At first glance of the time of this issue, I think I'm lucky to find a perfect solution. Until scrolling to the bottom then I realize that I'm unlucky. So sad.


@Gameknight77YT it looks like one of your path files is messed up for some reason. Try removing them from your robot project and see if it will launch then.

@ehamwey No idea why it would work in debug mode but not release mode. Only thing I could think of would be to run in debug mode and just don’t close it. I guess worst case you can just connect to a hotspot or Wi-Fi to run it again. Unfortunately flutter checks for dependencies every time you run so you need to be online. There should be a log file in C:/Users/{YOUR USER}/AppData/Roaming/pathplanner something (don’t remember the exact folder) check that after trying to open the built app and maybe it will have something.


Please note that reactivating a user account in this fashion will cause issues when federating with some other ActivityPub implementations.

I reactivated an account on my Mastodon instance using `accounts create` with the `--reattach` flag as described above. The user was unable to interact with users on Pleroma instances that were aware of their account before the deletion. I had to contact the admins of those instances and ask them to manually re-enable the account in their instances, because Pleroma doesn't seem to allow for reactivation of deleted remote accounts.

Unfortunately I'm not ActivityPub-savvy enough to discern whether this kind of user reactivation violates the spec and shouldn't be done, or whether this is a bug in implementations that behave this way.

Another note: the follower/followed counts for the reactivated user were wrong and wouldn't update until I ran `tootctl cache recount accounts`.


It's not a spec violation nor a "bug" per se, but it is an unhandled case. Likely what implementations would need to do is detect somehow that the user has been recreated and invalidate their old cache.


I did that and it is working now. I then readded them one at a time. The problem was one of them had an endpoint that was also a stop point.


I see. Then I'll make a PR with accepting your advice today (in UTC).


Of course, we can't express union or intersection types. Where we said "use the intersection of the supermethods' return types", I think we meant the glb; likewise lub for parameter types, with both being restricted to what we can express.

But we're also limited by what javac will allow: we can't change the base type at all.

I'm not sure we considered a case like this, where the nullness varies for a non-root type. What is the parameter type of `AB.foo`?

java
// null-marked code
interface SuperA { void foo(List bar); }
interface SuperB { void foo(List bar); }
interface AB implements SuperA, SuperB {}

The lub of these two types would be `List `, but we can't do that.

If we are analyzing AB itself, we can say: "please override this method and choose which of the two signatures you want". (Of course, whichever way they choose they'd still get a warning about the other one.)

But what about when AB is a dependency?

One option is: the answer is `List `, with the reasoning that type parameters are *more* likely covariant than contravariant, so we might as well behave as though `? extends` *were* there.

So, throughout all components of parameter types, *except* those that actually use `? super` (which we can handle normally), we would use the "most nullable" of the types. For return types, the least nullable.


@ForJessicaSake we do not assign issues (outside of core team) so feel free to just start on this.


@raphaelgurtner what does setting no content-type header means? Can you please tell me what to write? Here is my code:

await FlutterUploader().enqueue(
 RawUpload(
 url: uploadUrls[i],
 // required: url to upload to
 path: selectedVideos[i].path,
 // required: list of files that you want to upload
 method: UploadMethod.PUT,
 // HTTP method (POST or PUT or PATCH)
 // headers: {"apikey": "api_123456", "userkey": "userkey_123456"},
 tag: 'post video uploading', // custom tag which is returned in result/progress
 ),
 );


@tranice what does setting no content-type header means? Can you please tell me what to write? Here is my code:

await FlutterUploader().enqueue(
 RawUpload(
 url: uploadUrls[i],
 // required: url to upload to
 path: selectedVideos[i].path,
 // required: list of files that you want to upload
 method: UploadMethod.PUT,
 // HTTP method (POST or PUT or PATCH)
 // headers: {"apikey": "api_123456", "userkey": "userkey_123456"},
 tag: 'post video uploading', // custom tag which is returned in result/progress
 ),
 );


In case `hr_intraline = 1`, and diff format is "colored" or "unified", `DiffDescription._get_diff` uses only `get_lines` and it uses `idiff` module to get diffs.

The cause of `TypeError` was get_lines function returns a list of `bytes`, instead of a list of `str`. This will be fixed a patch below:

index 1bccb86a..2bf92475 100644
--- a/lib/viewvc.py
+++ b/lib/viewvc.py
@@ -4021,7 +4021,8 @@ class DiffDescription:
 def _content_lines(self, side, propname):
 f = self.request.repos.openfile(side.path_comp, side.rev, {})[0]
 try:
- lines = f.readlines()
+ lines = [l.decode(self.request.repos.encoding,'surrogateescape')
+ for l in f.readlines()]
 finally:
 f.close()
 return lines
@@ -4033,8 +4034,7 @@ class DiffDescription:

 def _prop_lines(self, side, propname):
 val = side.properties.get(propname, "")
- # FIXME: dirty hack for Python 3: we need bytes as return value
- return val.encode("utf-8", "surrogateescape").splitlines()
+ return val.splitlines()

 def _prop_fp(self, left, right, propname, diff_options):
 fn_left = self._temp_file(left.properties.get(propname))

However, there still exists something wrong. It causes another exception like this.

 File "/home/futatuki/work/viewvc/lib/viewvc.py", line 5539, in main
 request.run_viewvc()
 File "/home/futatuki/work/viewvc/lib/viewvc.py", line 452, in run_viewvc
 self.view_func(self)
 File "/home/futatuki/work/viewvc/lib/viewvc.py", line 4138, in view_diff
 generate_page(request, "diff", data)
 File "/home/futatuki/work/viewvc/lib/viewvc.py", line 1019, in generate_page
 template.generate(server_fp, data)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 347, in generate
 self._execute(self.program, fp, ctx)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 524, in _execute
 method(method_args, fp, ctx, filename, line_number)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 582, in _cmd_if_any
 self._do_if(value, t_section, f_section, fp, ctx)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 615, in _do_if
 self._execute(section, fp, ctx)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 524, in _execute
 method(method_args, fp, ctx, filename, line_number)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 625, in _cmd_for
 self._execute(section, fp, ctx)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 524, in _execute
 method(method_args, fp, ctx, filename, line_number)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 604, in _cmd_is
 self._do_if(value, t_section, f_section, fp, ctx)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 615, in _do_if
 self._execute(section, fp, ctx)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 524, in _execute
 method(method_args, fp, ctx, filename, line_number)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 625, in _cmd_for
 self._execute(section, fp, ctx)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 524, in _execute
 method(method_args, fp, ctx, filename, line_number)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 602, in _cmd_is
 left_value = _get_value(left_ref, ctx, filename, line_number)
 File "/home/futatuki/work/viewvc/lib/ezt.py", line 710, in _get_value
 ob = list[idx]
TypeError: 'generator' object is not subscriptable

I'll continue reading the code....


That probably happened when you deleted another point in the path. I'll make a separate issue to fix that.


Just to state that more directly: for this purpose only, treat wildcardless type arguments as if `? extends` is there. Would that resolve every case?

@cpovirk floated an intriguing alternative: the inherited method gets the parameter type `List `. This seems to make a lot of sense to me: in order to specify it, we needed them to provide an explicit override, and they didn't, so it's unspecified.


Est-ce que dans l'intervalle, il est possible de désactiver l'ajout automatique des sensors dans l'onglet Energie pour que seulement nos entrées manuelles (qui fonctionnent) restent?

J'ai le même problème. J'avais tout cleané hier, mis les bons sensors, puis ce matin plus rien ne marchait et les sensors non fonctionnels étaient revenus.


Yikes! I have just ordered one of the dev kit chip to do an internal install on my UltraHDMI modded N64. Has anyone reported a similar issue bundled with that mod? If so, a new flex cable will have to be developed, and as nice as Marshal is, he's only one guy and has a busy life. The chances of him developing one is slim, unless someone else steps in and develops one of their own. But again, has anyone with a UltraHDMI mod had this problem? Should this deveate into a different thread?


My bad, I saw it in Prometheus too, but it seems to have been resolved now.


I suggest that we close this issue. It was established at the top of the discussion that QUDT is not defining metallurgy tests. QUDT is useful for the units of such tests, but not defining the tests themselves. The continued search for a good metallurgy test vocabulary should continue on trace-vocab, which is where it is needed.

Also, let's make sure to celebrate that this discussion evolved into about QUDT/UNCEFACT vocab alignment which has since been successfully implemented.


I looked into this. QUDT does not have a role to play here; QUDT is focused on units, not which type of measurement is conducted.

I suggest we close this ticket and continue our search for a proper metallurgy tests vocabulary on a fresh issue which isn't premised on QUDT.


Hello @pdurbin :) Thank you for answering

By "no files" I mean "To retrieve Dataset without Datafile".
Maybe my text was mixing too much informations ^^

In other words, I want a SOLR field that tells me this dataset has 32 files. So I can ask Dataverse Search with : `fileCount=0` so I retrieve datasets without files or `fileCount>10` so I retrieve datasets with at least 10 files.

That's what I want to do but I cannot due to lack of 1 SOLR field that could contains informations on datafiles owned by a dataset (1 dataset = 1 solr document)
Ex : fileCount (int type) or fileIDs (array type)

Sadly, I don't have enough time at work to contribute at the moment but our team is thinking about contributing to Dataverse software, someday we will push code for sure !

We created a little python web application to help our support team (non technical persons) of our Dataverse Installation.
It uses Dataverse API Endpoints, SQL queries, Dataverse Search API. At this moment :

1. Shows all datasets without datafile and with empty field alternativeUrl (so we can ask scientists to populate their dataset with data)
2. Import list of email to add them in group (massive user configuration)
3. Help to merge non admin users by selecting in 2 lists of users one to merge and one user to keep.

I will sign in, hope to chat with you soon. It could be easier to exchange using screensharing.
Genuinely, Ludovic.


TODO: check into what javac does with base types; write test-case-like code


@ehamwey when you get a chance can you pull changes for the repo and see if builds you make will run now? I fixed a crash that *may* have been what caused your builds to crash but I'm not sure. If not then I'm really not sure what's going on there unless you can find some error output.


Backporting PR #297 is easy, but backporting PR #296 is troublesome because of `_diff_fp` implementation using `popen` API. Of course, we can backport whole `_diff_fp` implementation using subprocess.Popen, though.


Turning off Optimize Conversion doesn't work for me. I use collection from here: URL


As far as I know, this would only affect when the cell itself is scrolled out of the viewport. This case

when the cursor is out of the viewport but the cell itself is still rendered, should be fine.


In fact, it's not fine: cell will be out of view, too.

I created this issue because I just deleted 2 cells by accident as I described.


Also, IMAO I don't agree it's a feature request, this behaviour can confuse user and cause loss of data; hope you can reconsider its priority. :)


. o O ( We *neeeeeed* to get a 1.3.0 release out the door and call 1.2.x security-fixes-only. )


@OrIdow6 Thanks for reporting this! I've written a test case in #550 illustrating the problem. I don't have a solution yet, but it probably means the `Compression` wrapping of the `PoolReturnRead` needs to inform when it reaches the end.


We had to `flutter pub upgrade` to get the builds working, but once it was built we have an offline version that works. Thanks for your help again. I think I may have moved the Release folder out of the build directory originally which messed with the binary paths.


I'm not sure what I meant to learn from javac. If there's any variation in parameter types at all, it just gives an error -- we knew that! I guess what it does with return types is a bit illustrative:

java
import java.util.*;

class Issue110 {
 interface A { List foo(); }
 interface B { List foo(); }
 interface C extends A, B {}

 static {
 C c = null;
 List list = c.foo();
 }
}

This does compile. In other words, it's happy to go ahead and pick the more specific type. But this is just further argument justifying the *original* decision here from way back when. If I take out all the `? extends` it refuses to compile `C` at all. Again though, we knew this.


Looks like after a reboot the built binary does not run. Any thoughts?


Is there anything in `%AppData%/com.mjansen4857/pathplanner/log.txt`?


Negative - it's empty.
We were getting an error relating to how the built directories were moved, which seemed to have fixed itself once we connected to WiFi? So I'm trying a clean and build in the final destination directory to see if that resolves things, then we're rebooting and testing offline.


Moving the built app shouldn't do anything. Just to confirm, after building you're running the exe in `pathplanner/build/windows/runner/Release` right?


Yep - moving the entire `pathplanner` folder.

Seems like it will run on WiFi, but not with WiFi off.


By WiFi on/off do you mean connected/disconnected from a network or actually turning the WiFi off in the settings?


Never mind, I can reproduce it. This is something, thanks. I'll look into it.


I'm going to try on Flutter 3.3.4, we're currently running 3.5.0 because of the method we installed it by. I don't think that should fix the problem but will try anyway.


Found the issue and fixed it. Was a quirk of how dart try/catch blocks work so checking for PathPlannerLib updates would crash. Pull changes and try again.

I'd definitely use 3.3.4 as well since 3.5 is a beta and I'm currently using 3.3.4.


So assuming that's fixed, I believe the original issue this thread is based on is a problem with the 2022 version that is not present in the main branch. Here's a pre-release build of the main branch for anyone else finding this issue later:
pathplanner-windows.zip

I'll close this after the 2023 version is released.


@OrIdow6 also thanks for taking the time to write such a detailed report. I suspect the MultiGzDecoder only coincidentally fixes this because it will try additional reads after the first gzip stream is done.

In terms of how to fix this: the main problem is that the chunked encoding may have a few more bytes that it hasn't read. Specifically the `0\r\n\r\n` that terminates the response. It's not enough for the `GzDecoder` to say its done; if there are any unread bytes left in the response stream, we cant return it to the pool.

We also don't want to do any syscall-invoking reads in a `Drop` impl, since that could produce surprising hangs.

Proposal: fork chunked_transfer and make it aware of BufRead. When a read is finished, peek at the next 5 bytes in the buffer (if available). If those bytes are `0\r\n\r\n` consume them and set an internal piece of state saying "this stream is done." Expose that state with a `done()` method that can be forwarded by ureq's internal `Done` trait. Implement `Done` for `chunked_transfer::Decoder`. I think we don't actually need to touch the `Compression` layer at all, since all we care about is "did we read all the bytes from the chunked encoding yet."

Note this approach is not perfect: it's possible we could land right on a chunk boundary, with no bytes left in the buffer, but _if_ we read more from the network, the next bytes we would read would be `0\r\n\r\n`. In that case we would fail to recognize we were almost at the end, and would therefore fail to pool the connection. That's probably okay.

Another approach, which would be more perfect: if `chunked_transfer::Decoder` receives a read that ends on a chunk boundary, and there are no more bytes left in the buffer, then it should try to fill the buffer and peek at the next five bytes before returning.


@cdeil are you able to test if this still occurs with the latest master build? We now shutdown the database instance when the last connection is closed


@jsha I pushed a commit URL which potentially fixes the problem without forking anything.

Might be something I haven't thought about, but I think it should be ok.


The fix will be in repo soon. In the meantime, you can recover by editing `/etc/xen/scripts/block` and removing `--direct-io=on` parameter from `losetup` call.


Whoops! I had not considered that at all. Glad this got caught in testing!


we also have massive problems with BBB 2.5 and audio delay getting worse and worse with seconds what makes it unusable...


I did some more thinking and reading about this. What should we do if there is extra garbage after a gzip stream ends? I tested and both curl and Go's net/http generate an error.

According to URL gzip is defined in RFC 1952. In section 2.2:

The GzDecoder docs don't really make it clear, but that decoder only decodes a _single member_. The gzip specification (and therefore HTTP) specify a sequence of members. That's what's implemented by MultiGzDecoder. In other words, MultiGzDecoder is what you want if you actually want to read gzip response bodies, even though its documentation makes it sound like something esoteric.

That plays nicely with our intuition that extra garbage after a gzip member should cause an error. Once you've read a full member, the next thing you read must be either EOF or another fully-valid gzip member. So I take back what I said earlier: it's not really a coincidence that MultiGzDecoder repools, because it will keep reading to EOF.

So, I propose we switch to MultiGzDecoder, which I think should solve this problem in a simple way.


What I've done to fix this on local and CI:
Replace in **package-lock.json**:
`"ethereumjs-abi": "git+ URL
With:
`"ethereumjs-abi": "^0.6.8"`

Replace in **package-lock.json**:
`"resolved": "git+ URL
With:
`"resolved": " URL

`"ethereumjs-abi": {
 "version": "git+ URL
 "from": "ethereumjs-abi@git+ URL
With:
`"ethereumjs-abi": {
 "version": "0.6.8",
 "resolved": " URL


This is fixed in util-linux v2.38+, although we'd also have to pass an explicit `--sector-size=512` argument to ensure that the incompatible case is automatically resolved in favor of turning direct I/O off (as opposed to changing the logical block size).

@SurFlurer did you by any chance manually set up a 4k dm-crypt sector size? The old `cryptsetup` in the R4.1.x installer defaults to 512 byte sectors even on drives with 4k logical sectors, so normally your LVM Thin pool should have arrived at 512 byte sectors as well and avoided this bug.


As mentioned I will write out test cases, but they'll be... long. We'd normally not wait to mark this issue resolved until we do that, unless anyone feels that we don't even understand what we're deciding yet without writing all that out.


By the way, Brotli doesn't have the same convenient property, where streams happen to be terminated by end-of-file. AFAICT the Brotli decoder behaves similarly to how the `GzDecoder` does, and only consumes the compressed part of its input, possibly leaving some extra garbage on the end. So while `MultiGzDecoder` neatly solves this problem for gzip, we still need to solve it for Brotli.

I think we should error if there is extra garbage. One way to do that: wrap `BrotliDecoder` in a `PreciseReader`. The `PreciseReader`, after getting an `Ok(0)` from the `BrotliDecoder`, calls `into_inner()` on it and does a one-byte read on the underlying reader. If that one-byte read produces anything other the `Ok(0)` that means there's extra garbage and `PreciseReader` should return an error (which leads to not pooling the connection).

Some reasons to error on extra garbage:

 - Would prefer not to silently ignore bad input
 - It avoids an obligation to read arbitrarily many bytes during a single read call
 - curl does it :-D


@jsha great thoughts!

I've pushed a revision of #550 that simplifies the impl somewhat and throws an error if we read anything but 0.


I'm not sure how easy it would be for me to reproduce the issue and then build and try the master.
If you or others in the dev team can't easily do that, I could try, let me know.
Or alternatively - when is your next stable release? Could also wait for that and try again.


Sorry if I post this here on the wrong place but I was thinking about contributing to the vue rewrite but it's getting a bit messy here with all the branches and PRs. Which one is the most promising/recent one? And can we coordinate work on that?


What content type is the file you are uploading? You need to match it using `Content-Type`.


@CarlSchwan migrated the admin settings to Vue js already that part is done.
He also took the existing work and cleaned the code a bit, but didn't continue after that probably due to time constraints. You can find a PR with the changes.

@devlinjunker continued the work on the vue-rewrite branch, there are already some commits on that branch, you can find pull requests in his forked repository that are in progress.

That is the latest status.


@rustybird

In fact, I'm using LVM thick pool, because if I choose to use the LVM thin layout in the installer, there will be an error message and no new partition will be created.

Whoops, I forgot to explicitly emphasize that "LVM" is different from LVM-thin.

However, if my memory is correct, the default pool in LVM thin layout is “vm”.


Oh man, I always assumed that dm-crypt with sector_size 512 (the default on R4.1.x) would "shield" the upper storage layers from the 4Kn drive's logical block size. But actually it only works the other way around, which is sector_size 4096 bumping up a physical or logical block size of 512 on the underlying device to 4096 on the dm device.

That explains why this bug was able to affect your system.

General summary: People with 4Kn drives currently can't use lvm_thin pools (#4974), unless they're doing esoteric things like building custom template image files etc. And people who set up 4K dm-crypt on 512e drives have the same problem. But installation layouts compatible with the file-reflink driver are okay: "Btrfs", "Standard Partition", or "LVM" that's not "Thin". The latter two use XFS for the varlibqubes pool and are somewhat less tested, as you noticed :wink: