Are you guys closing down?

Just a few minutes ago I lost access with Heavy (https://enzienaudio.com/) and then found this post on twitter:

Is this true??

Yes unfortunately it's true, though service should be up and running as usual for the next month.

Sad times :(
I really enjoyed using Heavy with Unity experimentation. Hadn’t did anything in a while but was planning on doing lots of stuff in the future with it.

An thanks so much for an amazing product/service Joe, Martin, Rachel and Chris! Best of luck with whatever you are all moving on to.
David

On 1 Aug 2018, at 10:08, Joe White<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Yes unfortunately it's true, though service should be up and running as usual for the next month.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/enzienaudio/heavy/issues/266#issuecomment-409506798, or mute the thread https://github.com/notifications/unsubscribe-auth/AT-_1eoxlt1cFkYzINF3bqpOzoYoxigyks5uMXAKgaJpZM4VpdeK.

Also terribly sad to see you go ;^( Selfishly more so because I'm in the middle of a project using Heavy. I've managed to build the c/c++ code locally as per the instructions in the hvcc folder, but I'm stuck converting the resulting files to the Unity plugins that I need for the project. I see the  -g (generators) build switch is marked as todo. Is this the missing link in the puzzle for generating the platform specific plugins? If so, is there a timeline you're willing to share for having that feature implemented? Thanks so much for your awesome work on Heavy!

@moshang add -g unity to the command and it'll generate a unity folder with xcode/vs2015/linux makefile projects to build the plugin.

Thanks a lot - I'll give that a go.


ASA_win_2.3.271 : Supported windows Platform

Describe the bug
Running ASA on windows2012 R2 but for various collects getting " Collector is not supported for this platform"
To Reproduce
Steps to reproduce the behavior:

Go to '.. machine win 2012 R2.'
Unzip latest ..ASA_win_2.3.271..'
run >Asa.exe collect -a
See error

C:\Surface_Analyzer\ASA_win_2.3.271\ASA_win_2.3.271>Asa.exe collect -a --runid b
eforeinstall
[12:15:41 INF] AttackSurfaceAnalyzer v.2.3.271+414d1d5683
[12:15:45 INF] Begin beforeinstall.
[12:15:45 INF] Starting 14 Collectors.
[12:15:50 INF] Starting FileSystemCollector.
[12:15:50 INF] Scanning root C:
[12:43:06 INF] Scanning root D:
[12:43:06 INF] Completed FileSystemCollector in 00h:27m:15s:819ms.
[12:43:06 INF] Starting OpenPortCollector.
[12:43:07 INF] Completed OpenPortCollector in 00h:00m:00s:981ms.
[12:43:07 INF] Starting ServiceCollector.

[12:43:11 INF] Completed ServiceCollector in 00h:00m:03s:712ms.
[12:43:11 INF] Starting UserAccountCollector.
[12:43:12 WRN] Microsoft.CST.AttackSurfaceAnalyzer.Collectors.UserAccountCollect
or isn't supported on this platform and failed to run. This won't impact results
for other collectors.
[12:43:12 INF] Completed UserAccountCollector in 00h:00m:00s:530ms.
[12:43:12 INF] Starting RegistryCollector.
[12:43:44 INF] Completed RegistryCollector in 00h:00m:32s:250ms.
[12:43:44 INF] Starting CertificateCollector.
[12:43:46 INF] Completed CertificateCollector in 00h:00m:02s:043ms.
[12:43:46 INF] Starting FirewallCollector.
[12:43:47 WRN] Microsoft.CST.AttackSurfaceAnalyzer.Collectors.FirewallCollector
isn't supported on this platform and failed to run. This won't impact results fo
r other collectors.
[12:43:47 INF] Completed FirewallCollector in 00h:00m:01s:227ms.
[12:43:47 INF] Starting ComObjectCollector.
[12:44:07 INF] Completed ComObjectCollector in 00h:00m:19s:915ms.
[12:44:08 INF] Starting EventLogCollector.
[12:44:56 INF] Completed EventLogCollector in 00h:00m:48s:064ms.
[12:44:56 INF] Starting TpmCollector.
[12:44:58 INF] Completed TpmCollector in 00h:00m:01s:834ms.
[12:44:58 INF] Starting CryptographicKeyCollector.
[12:44:58 INF] Completed CryptographicKeyCollector in 00h:00m:00s:012ms.
[12:44:58 INF] Starting ProcessCollector.
[12:45:09 INF] Completed ProcessCollector in 00h:00m:10s:141ms.
[12:45:09 INF] Starting DriverCollector.
[12:45:23 INF] Completed DriverCollector in 00h:00m:14s:596ms.
[12:45:24 INF] Starting WifiCollector.
[12:45:27 INF] Completed WifiCollector in 00h:00m:03s:025ms.

Do you know if this is a regression? Did these collectors previously work on 2012? If so, what was the latest version you know works on 2012?
From examining the code, the firewall collector is likely running into this exception from the WindowsFirewallHelper library:
https://github.com/falahati/WindowsFirewallHelper/blob/3ff11894c12cc76ff1f769577a1ad1697882959f/WindowsFirewallHelper/FirewallManager.cs#L15-37
Similarly, The user account collector uses the System.Management library which I believe is the line throwing this there.

For the Service Collector it appears that the .NET Framework version you have installed on Windows is not new enough. Installing 4.8 might resolve the issues with the Service and User collector.
https://support.microsoft.com/en-us/topic/microsoft-net-framework-4-8-for-windows-server-2012-ffc7ea09-24e4-76ce-648f-290617580544


Document Windows specific refaster command line

Please add some documentation how to invoke refaster on Windows. As a Windows developer it is okay to replace wget and similar shell commands in the example, however I had a very hard time figuring out to replace the colon ":" between the jar file paths by a ";", since path separators are different on Windows and Linux.

Did you figure this out?  Would you have any interest in contributing a PR to fix the documentation at https://github.com/google/error-prone/blob/gh-pages/docs/refaster.md?
None of the Error Prone core developers develop on Windows, so it would be helpful for someone who does to write this documentation.


Update script_get_all_texts.ts

Improved
Error Handling: Added try-catch blocks around the extraction logic to catch potential errors.
Warning messages: Replaced general console.log messages with console.warn for better clarity in non-critical warnings.
Improved readability: Refactored code to improve readability, with consistent naming, and separated concerns within functions.
Additional null checks: Enhanced the checks for DOM existence and element validity.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Please provide a code.ps1 alongside code.cmd and code in bin directory

VSCode Version:
Version 1.1.0
Commit c212f0908f3d29933317bbc3233568fbca7944b1
Date 2016-05-09T12:53:58.929Z
Shell 0.37.6
Renderer 49.0.2623.75
Node 5.10.0

OS Version: Windows 10 Professional

not so much a bug as a feature request. I'd like to see a code.ps1 along with the code.cmd and code scripts.  Here's a skeleton to get started (blatantly copied from code.cmd and translated):
[CmdletBinding()]
    Param
    (
    [parameter(mandatory=$false, position=0, ValueFromRemainingArguments=$true)]$Remaining
    )

Remove-Item env:\VSCODE_DEV
$env:ATOM_SHELL_INTERNAL_RUN_AS_NODE=1
$dp0 = Split-Path -parent $PSCommandPath;
$exePath = [System.Io.Path]::Combine($dp0, "..\code.exe");
Write-Verbose "exePath is $exePath";
$jsPath =  [System.Io.Path]::Combine($dp0, "..\resources\app\out\cli.js");
Write-Verbose "jsPath is $jsPath";
Write-Verbose "remaining is $remaining"
Write-Verbose "command line is [$exePath] [$jsPath] [$remaining]"

&"$exePath" "$jsPath" $remaining

updated powershell example to better handle env changes as well as added some verbose output

Please file this issue in the https://github.com/PowerShell/vscode-powershell
As this is happening in the powershell extension


In-app feedback: modify the behavior of the app to always leave 1-line transclusion template at the top

What is the user problem or growth opportunity you want to see solved?
modify the behavior of the app to always leave line transclusion template at the top

keep the section "Please_help_monitor_this_page" permanently on top? (see: https://commons.wikimedia.org/wiki/Commons:Mobile_app/Feedback#Please_help_monitor_this_page )

How do you know that this problem exists today? Why is this important?
"it is true that we do not monitor it as regularly as we should"
Who will benefit from it?
Ensuring that problems and suggestions reported by users reach the developers.
Anything else you would like to add?
No response

Very true!
We must also create the template/transclusion.


Add Makefile for building for MacOS & Linux👷♂

relates #606

Hi, thanks for the PR.
The linux build seems to work perfectly, but I have some issues with the mac version (compiling from Ubuntu):

Relevant log
Building for MacOS... 🍏
cross build --release --target=x86_64-apple-darwin
   Compiling autocfg v1.0.1
   Compiling libc v0.2.79
   Compiling cfg-if v0.1.10
   Compiling proc-macro2 v1.0.24
   Compiling lazy_static v1.4.0
   Compiling unicode-xid v0.2.1
   Compiling bitflags v1.2.1
   Compiling syn v1.0.42
   Compiling maybe-uninit v2.0.0
   Compiling crc32fast v1.2.0
   Compiling rayon-core v1.8.1
   Compiling scopeguard v1.1.0
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `lazy_static`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error[E0463]: can't find crate for `core`
  |
  = note: the `x86_64-apple-darwin` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: build failed
make[1]: *** [Makefile:16: build-mac] Error 101
make[1]: Leaving directory '/home/al/ws/sic'
make: *** [Makefile:6: build] Error 2

In particular, the x86_64-apple-darwin target doesn't seem to be supported by cross (supported toolchains).
Now there may be some ways to cross compile anyways but I haven't looked into that so far...
Another option would be to build releases on the CI instead of manually (which supports MacOS runners). I've been thinking about doing that for a while now, but haven't given it the necessary attention yet.
What do you think the best option would be?

Soo finished! 🚀
Can be installed on MacOS by:
brew tap tgotwig/sic
brew install tgotwig/sic/sic

Let me create another pull-request to mention this in the README.md 🙂

Feel free to do that in this PR as well :)

That one extra commit regarding image optimizations comes from there:
https://github.com/TGotwig/sic/pull/1

Yeah I'm also not sure about that,
I removed the commit with the image optimizations 👍


Stuck when reloading domain

Hello,
So this might partially be on my side, but from times to times (like 1 out of 6 times), my unity editor is stuck at "Reloading Domain".
If I look for the logs, I see:
Begin MonoManager ReloadAssembly
thread 'tokio-runtime-worker' panicked at yaha_native/src/binding.rs:84:85:
The context has already disposed: on_complete
stack backtrace:
Thread 0x32778f000 may have been prematurely finalized
Thread 0x326807000 may have been prematurely finalized
Thread 0x326e2b000 may have been prematurely finalized
   0:        0x325c55ff4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0524bd1b527203b8
   1:        0x325c71124 - core::fmt::write::h74be1333b0a6ddea
   2:        0x325c53ac8 - std::io::Write::write_fmt::h6c011b665b2d7d4b
   3:        0x325c55e34 - std::sys_common::backtrace::print::he25ff7dac6402434
   4:        0x325c57434 - std::panicking::default_hook::{{closure}}::h41763ba018b93bf7
   5:        0x325c5714c - std::panicking::default_hook::h017c44660373840e
   6:        0x325c57978 - std::panicking::rust_panic_with_hook::h221a0baf52ecd48a
   7:        0x325c57840 - std::panicking::begin_panic_handler::{{closure}}::h18b661cf0f97a414
   8:        0x325c56480 - std::sys_common::backtrace::__rust_end_short_backtrace::h4f4b2ffab2311217
   9:        0x325c575ec - _rust_begin_unwind
  10:        0x325c83a2c - core::panicking::panic_fmt::hd6070cd222575be5
  11:        0x325b2f47c - yaha_native::binding::_sentinel_on_complete::h9d141ccad330d382
  12:        0x325add314 - yaha_native::binding::yaha_request_begin::{{closure}}::h5631ce843d7c5f2a
  13:        0x325adb934 - tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut::h3072105b67f01266
  14:        0x325b3cf2c - tokio::runtime::task::core::Core<T,S>::poll::hab7b4df7609e5b75
  15:        0x325ab8b5c - tokio::runtime::task::harness::Harness<T,S>::poll::hb04bc757ef901abc
  16:        0x325c191e0 - tokio::runtime::scheduler::multi_thread::worker::Context::run_task::habe660f9555d29f0
  17:        0x325c181a0 - tokio::runtime::scheduler::multi_thread::worker::Context::run::h92d568732cff005f
  18:        0x325c31ca8 - tokio::runtime::context::scoped::Scoped<T>::set::h28d62af9fe07fa31
  19:        0x325c31ba0 - tokio::runtime::context::runtime::enter_runtime::h21dc3e6654b89594
  20:        0x325c17d38 - tokio::runtime::scheduler::multi_thread::worker::run::h3240adbe89ca2def
  21:        0x325c1f72c - tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut::h3f7f0a43009caa76
  22:        0x325c34a60 - tokio::runtime::task::core::Core<T,S>::poll::hac538a70219f2b02
  23:        0x325c14dd0 - tokio::runtime::task::harness::Harness<T,S>::poll::he5653619c802c7d6
  24:        0x325c1c41c - std::sys_common::backtrace::__rust_begin_short_backtrace::h2ef7fff63fe86b99
  25:        0x325c26374 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h2509ba3d429991b9
  26:        0x325c5976c - std::sys::unix::thread::Thread::new::thread_start::h07b00985b5bfc467
  27:        0x18a9ba034 - __pthread_joiner_wake
Thread 0x326207000 may have been prematurely finalized

How I create the channel:
GrpcChannelOptions options = new GrpcChannelOptions()
{
    Credentials = Config.ProjectsServiceCredentials,
    DisposeHttpClient = true,
    HttpHandler = new YetAnotherHttpHandler()
    {
        Http2Only = true
    }
};
_grpcChannel = GrpcChannel.ForAddress(Config.ProjectsServiceAddress, options);

How it is disposed:
_grpcChannel
  .ShutdownAsync()
  .ContinueWith(t =>
  {
      if (t.Exception != null)
      {
          UnityEngine.Debug.LogException(t.Exception);
      }
      _grpcChannel.Dispose();
  }, TaskScheduler.FromCurrentSynchronizationContext());

Steps to reproduce:

Click play button, wait until you are connected to the GRPC server
Click the stop button
Click the play button again

=> Expected behavior: it plays again
=> Actual behavior: editor is stuck at "Reloading Domain"

EDIT: If I replace my graceful dispose by just _grpcChannel.Dispose(), the issue still occurs
EDIT2: Same if I don't dispose it, except it is stuck 100% of times
NOTE: I am communicating with 3 GRPC servers and so use 3 YetAnotherHttpHandler

Please tell us a few things so we can investigate in detail:

Is the gRPC connection streaming? If streaming, is the streaming being disposed before the channel is disposed?
When is a channel disposed? OnApplicationQuit event?
Which Unity Editor version and platform?

Hello Mayuki,
I really like your input and I am pretty sure it has something to do with things not being disposed on time on my side.
Indeed I have streaming connections (from 3 to 8 depending on the use case). I just modified my code to be 100% sure they were disposed before disposing the channels but crashes still occurs.
I will keep modifying my code because if it works sometimes it must be possible to make it work every time and I am probably the one at fault here. I might missed a method called without CancellationToken or something just before disposing.
I will get back to you soon!
If that still matters:
The channel is disposed on OnApplicationQuit event.
I am using Unity 2022.3.18f1 on macOS Sonoma v14.2.1 with apple sillicon

I am coming back at you to keep you updated.
I spent quite some time trying to look for asynchronous issues I might be victim of and at some point I realized that I was instantiating 3 YetAnotherHttpHandler.
I thought "maybe deep down it tries to dispose of the same resource twice".
Now my 3 channels are sharing the same YetAnotherHttpHandler instance that I dispose once not needed anymore and I see no more crash.
Not sure if really fixed or if it just drastically reduced occurence. It did not happen in 1000 tests where it took about 4 previously.
I tried to reproduce the error in a minimal Unity Scene and failed to do so.
Might invest some more time in it later.
Thanks again for your input.

Thanks!
I have released v1.0.1. This release includes improvements to the dispose process, so please give it a try.


CSDN support

Hi Jove,
Thanks for sharing.
Please, is there any way to share with us the CSDN posts.
I can not read the articles because CSDN internation people policies.
Thanks in advance.

First of all, thank you for your attention.
In the near future, I will put all my articles on GitHub and create an online document using Read the Docs.
But I have to finish my work first. I'm busy these days.

First of all, thank you for your attention. In the near future, I will put all my articles on GitHub and create an online document using Read the Docs. But I have to finish my work first. I'm busy these days.

Many thanks.
Actually I am trying to find someone from China can sign up CDSN account and send me screenshots of the Gmapping tutorials that you mentioned.

First of all, thank you for your attention. In the near future, I will put all my articles on GitHub and create an online document using Read the Docs. But I have to finish my work first. I'm busy these days.

Many thanks. Actually I am trying to find someone from China can sign up CDSN account and send me screenshots of the Gmapping tutorials that you mentioned.

That's also a good idea. Please contact me if you have any other questions.

Hi Bro,
Finally, I signed up in blog.cdsn.
but, still can not read the articles : (it request subscriptions !)
https://blog.csdn.net/qq_32618327/article/details/121706071
https://blog.csdn.net/qq_32618327/article/details/122110185
https://blog.csdn.net/qq_32618327/article/details/122244370
https://blog.csdn.net/qq_32618327/article/details/122318169
https://blog.csdn.net/qq_32618327/article/details/122330515
https://blog.csdn.net/qq_32618327/article/details/122369165
https://blog.csdn.net/qq_32618327/article/details/122393554
https://blog.csdn.net/qq_32618327/article/details/122393781
https://joveh-h.blog.csdn.net/article/details/98219810


Add log4j.properties file to remove warning message when starting web server

Fixes #1464.

@drostron This should be ready to go now and probably a fast review

Whew, that was exhausting 😉.


Add documentation for testing

Add documentation pages for

Unit testing
End-to-end testing

Add section in the toolbar for Testing under function reference

Converting to draft to prevent merging until we change the base branch.

Please rename the testing.qmd file and then feel free to merge.
The base branch as been changed to rc-v1


Support v2 pages in child to normal page converter

These are the v2 version of the original v1 "child to normal page conversion" pages that support converting both v1 and v2 pages to child pages or back to normal pages.
Aside from converting the pages to api v2, the biggest change was adding logic based on the selected page's api version to:

only display master pages with a matching api version
use the correct xml tags based on the selected api version (skuid__page vs. skuidpage and skuid__pageRegion vs. pageregion)
Assign the correct api version to the new page created at the end of the conversion process

I also added search support to the skuid platform page to make it easier to find the page you want to convert.

I'll test the pages,  but I think you need to make some changes to the ReadMe.

Good call. I imagine we'll eventually want to remove the original v1 pages - is that ok with you @itmightbecody?

@elena-oneil About to test these pages! But I'd say let's not remove the v1 versions for historical purposes, at least for now. As Rob said, let's add some instructions to the README on when to use which page.

@itmightbecody thanks for the good feedback and suggestions. I made the changes and improvements you suggested and it's ready for re-review!


How to convert to int8 model?

Hello, very impressive work! How to trace the model and save its weights as int such as int8? I want to check the model size after quantization. Moreover, is the proposed method applicable to other non-transformer models?

@detectRecog
Hi, thanks for your recognition of our work. We have not provided the interface for storing models and there are two reasons for that. The first reason is that the model conversion and storage are closely related to specific hardware, and our work in that is still in progress. The second reason is to facilitate the experiment. We use FakeQuantization in all places except PTS (layerform) and LIS (softmax) modules.
Despite all this, there are other remedies. If you want to check the quantization value of weights, you can check them out at this line and save out for some layers. And if you want to check the int8 model size, because we quantize all weights to 8-bit, you can just divide the floating-point model size by 4 (same as 32 / 8).
This paper mainly deals with the extreme distribution of LayerNorm and Softmax in vision transformers and we don't find these extreme distributions on non-transformer architectures (such as CNN), so it may be not applicable for them. However, if you are concerned about the quantization for vision transformers, I believe our work will help you!

@detectRecog
Hi, thanks for your recognition of our work. We have not provided the interface for storing models and there are two reasons for that. The first reason is that the model conversion and storage are closely related to specific hardware, and our work in that is still in progress. The second reason is that we use FakeQuantization in all places except PTS (Layerform) and LIS (Softmax) modules in order to facilitate the experiment.
Despite all this, there are other remedies. If you want to check the quantization value of weights, you can check them out at this line and save out for some layers. And if you want to check the int8 model size, because we quantize all weights to 8-bit, you can just divide the floating-point model size by 4 (same as 32 / 8).
This paper mainly deals with the extreme distribution of LayerNorm and Softmax in vision transformers and we don't find these extreme distributions on non-transformer architectures (such as CNN), so it may be not applicable for them. However, if you are concerned about the quantization for vision transformers, I believe our work will help you!


Allow user to run job manually from the dashboard

As a user I should be able to select a task and run a job.

Allow to trigger new job from dashboard
Allow to retry existing job (that is not in process)

Closed via #24


Reset Password

Hi,
how can i replace my login credenticals for incontrol?
I had to change my password and since then hassio was not able anymore to update data.

You need to remove and re-add.  It's a bit of a HA issue I'm afraid. However, when you re-add the entity names should stay the same so all your dashboard stuff should come back (unless you renamed them).

Thank you. I had to rename all entity-names because the cars name was changed in the incontrol app. But it only tooks about 2 minutes, that is okay for me ^^


added missing commas in README

When using the example in the README, I got a syntax error.
This PR adds missing commas in the README to fix these errors.

Thank you for the catch. Proof that despite reading the readme a million times, I'll never catch all of the commas 😆 .


urllib.error.HTTPError: HTTP Error 413: Request Entity Too Large

When I use this tool to get some comments from a video, I got an exception like this.
urllib.error.HTTPError: HTTP Error 413: Request Entity Too Large

The command is
python yttool.py --comments https://www.youtube.com/watch?v=ovJcsL7vyrk

Here is the url which cause the exception, it's too long.

How to solve this issue?

I have tried to skip this url, however, it doesn't make sense because the parameter cc in the following while loop must be updated according to the url.

while cc:
	cmtjson = self.yt.getcomments(cc, self.xsrf)
	if self.args.debug:
		print("============ comment req")
		print(cmtjson.decode('utf-8'))
		print()

	js = json.loads(cmtjson)

	cmtlist, cc = self.extractcomments(js)

	for author, runs, subcc in cmtlist:
		print("---" * (level+1) + ">", author)
		self.printtextrun(runs)
		if subcc:
			self.recursecomments(subcc, level+1)

Seems that the two parameters ctoken and continuation  in the url are the same, is it possible to do some optimization?

This is a problem with youtube, I can make the website give me the same problem when i scroll down far enough.

I solved it by sending only ctoken, and removing the second copy of the token passed in the 'continuation' url query parameter.
youtube seems to be fine with just one token.


refactor(fulltext-search): persist fulltext search term in input field (DSP-1674)

resolves DSP-1674

@kilchenmann you can see it in action by searching for a resource using the fulltext search and then refreshing the results page. If you then make an advanced or expert search, the input field will be cleared. Also if you make a fulltext search and then go to the homepage, the search term will remain in the input field and if you refresh the page, the search term will be cleared (this isn't new though)

@kilchenmann you can see it in action by searching for a resource using the fulltext search and then refreshing the results page. If you then make an advanced or expert search, the input field will be cleared. Also if you make a fulltext search and then go to the homepage, the search term will remain in the input field and if you refresh the page, the search term will be cleared (this isn't new though)

Yes, I saw yesterday in your demonstration. Sounds perfect 👍


Handle case when TaskBarList could not be created

What does the pull request do?
Checks whether TaskBarList successfully created.
What is the current behavior?
Current code assumes TaskBarList is supported on all windows version. On Windows Server Core editions TaskBarList is not supported (no taskbar) and creating a window crashes the application.
What is the updated/expected behavior with this PR?
Applications could start on Windows Server Core. Tested on Windows Server 2016 Core.
Checklist

[ ] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Fixed issues
Fixes #15840

@mojoe-playground,
Please read the following Contributor License Agreement (CLA). If you agree with the CLA, please reply with the following:
@cla-avalonia agree

Contributor License Agreement
Contribution License Agreement
This Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ),
and conveys certain license rights to the AvaloniaUI OÜ ( “AvaloniaUI OÜ” ) for Your contributions to
AvaloniaUI OÜ open source projects. This Agreement is effective as of the latest signature date below.
1. Definitions.
“Code” means the computer software code, whether in human-readable or machine-executable form,
that is delivered by You to AvaloniaUI OÜ under this Agreement.
“Project” means any of the projects owned or managed by AvaloniaUI OÜ and offered under a license
approved by the Open Source Initiative (www.opensource.org).
“Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any
Project, including but not limited to communication on electronic mailing lists, source code control
systems, and issue tracking systems that are managed by, or on behalf of, the Project for the purpose of
discussing and improving that Project, but excluding communication that is conspicuously marked or
otherwise designated in writing by You as “Not a Submission.”
“Submission” means the Code and any other copyrightable material Submitted by You, including any
associated comments and documentation.
2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any
Project. This Agreement covers any and all Submissions that You, now or in the future (except as
described in Section 4 below), Submit to any Project.
3. Originality of Work.  You represent that each of Your Submissions is entirely Your
original work. Should You wish to Submit materials that are not Your original work,
You may Submit them separately to the Project if You (a) retain all copyright and
license information that was in the materials as you received them, (b) in the
description accompanying your Submission, include the phrase "Submission
containing materials of a third party:" followed by the names of the third party and any
licenses or other restrictions of which You are aware, and (c) follow any other
instructions in the Project's written guidelines concerning Submissions.
4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else
for whom You are acting in making Your Submission, e.g. as a contractor, vendor, or agent. If Your
Submission is made in the course of Your work for an employer or Your employer has intellectual
property rights in Your Submission by contract or applicable law, You must secure permission from Your
employer to make the Submission before signing this Agreement. In that case, the term “You” in this
Agreement will refer to You and the employer collectively. If You change employers in the future and
desire to Submit additional Submissions for the new employer, then You agree to sign a new Agreement
and secure permission from the new employer before Submitting those Submissions.
5. Licenses.
a. Copyright License. You grant AvaloniaUI OÜ, and those who receive the Submission directly
or indirectly from AvaloniaUI OÜ, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable
license in the Submission to reproduce, prepare derivative works of, publicly display, publicly perform,
and distribute the Submission and such derivative works, and to sublicense any or all of the foregoing
rights to third parties.
b. Patent License. You grant AvaloniaUI OÜ, and those who receive the Submission directly or
indirectly from AvaloniaUI OÜ, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license
under Your patent claims that are necessarily infringed by the Submission or the combination of the
Submission with the Project to which it was Submitted to make, have made, use, offer to sell, sell and
import or otherwise dispose of the Submission alone or with the Project.
c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement.
No additional licenses or rights whatsoever (including, without limitation, any implied licenses) are
granted by implication, exhaustion, estoppel or otherwise.
6. Representations and Warranties. You represent that You are legally entitled to grant the above
licenses. You represent that each of Your Submissions is entirely Your original work (except as You may
have disclosed under Section 3 ). You represent that You have secured permission from Your employer to
make the Submission in cases where Your Submission is made in the course of Your work for Your
employer or Your employer has intellectual property rights in Your Submission by contract or applicable
law. If You are signing this Agreement on behalf of Your employer, You represent and warrant that You
have the necessary authority to bind the listed employer to the obligations contained in this Agreement.
You are not expected to provide support for Your Submission, unless You choose to do so. UNLESS
REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE WARRANTIES
EXPRESSLY STATED IN SECTIONS 3, 4, AND 6 , THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS
PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF
NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
7. Notice to AvaloniaUI OÜ. You agree to notify AvaloniaUI OÜ in writing of any facts or
circumstances of which You later become aware that would make Your representations in this
Agreement inaccurate in any respect.
8. Information about Submissions. You agree that contributions to Projects and information about
contributions may be maintained indefinitely and disclosed publicly, including Your name and other
information that You submit with Your Submission.
9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the Republic of Estonia, and
the parties consent to exclusive jurisdiction and venue in the courts sitting in Talinn,
Estonia. The parties waive all defenses of lack of personal jurisdiction and forum non-conveniens.
10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and
supersedes any and all prior agreements, understandings or communications, written or oral, between
the parties relating to the subject matter hereof. This Agreement may be assigned by AvaloniaUI OÜ.
AvaloniaUI OÜ dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1.

@cla-avalonia agree


Not able to pull/deploy app with private images in ghcr even after providing login credentials.

acorn version v0.7.0-alpha1-16-g9007dba3+9007dba3
Steps to reproduce the problem:
Login to ghcr.
Try to pull/deploy app with private images in the logged in ghrc account.
acorn login xxx
? Username xxxx
? Password ****************************************
  ✔  Login to xxx as xxx succeeded
sangeethahariharan@Sangeethas-MBP example1 % acorn credentials
SERVER                  USERNAME     LOCAL
ghrc.io                 sangeetest
hub.stg.acornlabs.com   sangeetest   *
sangeethahariharan@Sangeethas-MBP example1 % acorn run -n mytestnew ghcr.io/xxx/myfirstacron:v0.0.1
  ✗  ERROR:  GET https://ghcr.io/token?scope=repository%3Asangeetest%2Fmyfirstacron%3Apull&service=ghcr.io: DENIED: requested access to the resource is denied
sangeethahariharan@Sangeethas-MBP example1 % acorn pull ghcr.io/sangeetest/myfirstacron:v0.0.1
  ✗  ERROR:  websocket: close 1011 (internal server error): [?scope=repository%3Asangeetest%2Fmyfirstacron%3Apull&service=ghcr.io: DENIED: requested access to the resource is denied]

Token I used to log in was the same token I had used to log in to create the image from another project using acorn push
Note - I am able to pull/deploy app with private images in docker hub after providing login credentials.

This is user error. I did not have the right credentials. When logged in with right credentials , i am able to pull and deploy apps using private registry.


Importing annotations without deleting current ones

My actions before raising this issue

[x] Read/searched the docs
[x] Searched past issues

When importing annotations into a task, CVAT deletes current annotations. Is there a way to keep them and have both sets of annotations in the same task?

Im having the same issue. Was it resolved?

Can you describe the problem in more detail like what web browser you're using and what step you took for the issue to occur, also please share images to show the problem better.

Hey @nmanovic, I was also able to replicate the error and would like to have a go at it.

Hey @nmanovic, I was also able to replicate the error and would like to have a go at it.

@OmarHassan2334 , could you please send me an email with a screenshot of debugging of CVAT? I cannot locate it. If you read instructions, only after you confirm that you setup the development environment, I can assign an issue.

Hi @nmanovic, I will take on this other issue to solve it

Hi, I wouldn't call it's an "easy" problem to solve, nor would I call it a bug or an error. It's implemented this way on purpose - so that after importing annotations you had only what you just uploaded. Though I agree, it can be improved by allowing to keep existing annotations. Thus, the nice solution would be:

to add a switch in UI annotation import dialog
to add a server API flag for keeping old annotations on uploading (should be enabled by default)
forward the flag from the API all the way up to this place
add corresponding tests

This should be done both for tasks and jobs as all of them allow annotation uploading.

Hi, thank you for your help, and sorry for taking so long to answer, I've
been sick this past week.
I'm having trouble understanding the complete structure of the project,
could you tell me where the server API flags are located, or provide an
example in the code of their usage?
Thank you very much.
El jue, 4 abr 2024 a las 17:53, Maxim Zhiltsov @.***>)
escribió:

Hi, I wouldn't call it's an "easy" problem to solve, nor would I call it a
bug or an error. It's implemented this way on purpose - so that after
importing annotations you had only what you just uploaded. Though I agree,
it can be improved by allowing to keep existing annotations. Thus, the nice
solution would be:

to add a switch in UI annotation import dialog
to add a server API flag for keeping old annotations on uploading
(should be enabled by default)
forward the flag from the API all the way up to this place
https://github.com/cvat-ai/cvat/blob/ea47d00103f9df8bd31102ea2ae364e32fa20f04/cvat/apps/dataset_manager/task.py#L799
add corresponding tests

This should be done both for tasks and jobs as all of them allow
annotation uploading.
—
Reply to this email directly, view it on GitHub
https://github.com/cvat-ai/cvat/issues/4747#issuecomment-2037582698, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AOCQJZOMNR22PL4TW62ACV3Y3VZOBAVCNFSM53NVNYHKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBTG42TQMRWHE4A
.
You are receiving this because you were assigned.Message ID:
@.***>

@EBayego, I hope you feel better now. For API please check cvat/apps/*/views.py, mostly engine.views. An example of a parameter is conv_mask_to_poly.

@zhiltsov-max
Yes, I'm feeling better now, thank you!
If I'm not mistaken, the parameter is retrieved from a query using request.query_params.get(), but I can't find where it's created. Could you give me a quick guide of how the flow works? I'm sorry for needing this much help. Thank you!

Hi, I'm facing I suppose the last problem. I'm trying to maintain the current annotations by creating new shapes (and probably tags and tasks too) with the same data, but letting django create new ids for them in order to avoid errors. But even with that, I'm getting the following error:

I'm only creating new ids for those who already exists, by checking the list that contains current shapes. models.LabeledShape.objects.values_list('id', flat=True). Any idea on how to deal with this?
Thank you!

Hi,

I'm facing I suppose the last problem. I'm trying to maintain the current annotations by creating new shapes (and probably tags and tasks too) with the same data, but letting django create new ids for them in order to avoid errors.

It's certainly doable this way too, but why did you decide to it like this? Did you try to comment the annotation removal line?
About the error - are you sure it's about annotation ids? It's hard to say for sure without the stack trace, please try to check it via docker logs cvat_worker_import.

It's certainly doable this way too, but why did you decide to it like this? Did you try to comment the annotation removal line?

Yes, you are right, that's the option I tried at first, but I encountered an error which I attempted to resolve in this way. However, I am no longer able to reproduce it in any way, so it was likely my mistake in the import file format or in managing labels or not saving annotations, i don't really know.
Finally, regarding the tests, I simply modified the lines where it calls import_task_annotations by adding a final True corresponding to the new flag I created. Should I create any more tests? Thank you very much for your help and time, I appreciate it!

@EBayego, we're trying to move away from using the django-based tests. Please add a test in the tests/python/rest_api tests.

Okay, in that case, I believe that this existing test, if runs successfully, covers the development I have done, as I have only included a parameter in the internal query, the same case as conv_mask_to_poly. I will prepare the pull request following your documentation. If there are any changes or suggestions, let me know!

I believe that this existing test, if runs successfully, covers the development I have done, as I have only included a parameter in the internal query, the same case as conv_mask_to_poly.

I'm not sure I got what you mean here. In this PR there is a new API option to allow keeping the old annotations during the import. In needs to be tested. There is no way it could be covered by any existing test, as it didn't exist before this PR.

I assumed that this was a parameter with the same functionality as the one you gave me as an example, conv_mask_to_poly. In the Swagger documentation, this parameter does not appear:

And in the code, therefore, it also does not appear as an OpenApiParameter. However, it is taken from the query parameters within the method here. I assumed that either the Swagger documentation had not been updated, or that it was simply an internal parameter relevant only for specific queries, and the parameter was just a part of 'options', which is a list sent along with other options, in this case only conv_mask_to_poly from here.
If it needs to be added to the Swagger documentation, then I imagine the test I need to perform is similar to this one, but adding the part of passing more parameters to the query and not just the file format and the file to import.
Since I don't see direct examples to follow and save time, it will take me more time to figure out how to write the appropriate tests. And given that today, if I'm not mistaken, is the last day to have a PR ready, I will submit the PR to document what I've done so far, and I will continue with the development in the coming days.

In the Swagger documentation, this parameter does not appear

Most of the OpenAPI parameters must be added manually with the decorator, except regular filtering parameters and several others. conv_mask_to_poly was supposed to be a temporary solution, and it can be considered deprecated, so we don't want to advertise it in the API.


[FEATURE] A Chatbot which guides user according to need

Is your feature request related to a problem? Please describe.
A chatbot which will help people to find their solutions more easily
Describe the solution you'd like
The chatbot will have a feature of Natural Language which will easily omit user's grammatical mistakes and spelling mistakes in chat input. The admin can train the chatbot whenever needed in a .json file.
-->The chatbot will have its back end in Python with modules like PyTorch, NumPy, etc. and and a basic front end in CSS and JS and HTML
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

@Vignesh025 hey i would love to make this bot for the campx , can I proceed?

We want to keep this project minimal. Adding features like a chatbot would make it overwhelming, so we won't be adding this feature for now.


some packet loss and other weirdness when running weave in NAT'ed VMs

MongoDB host machine: dell R620 server (40 cores, 128GB ram) Ubuntu 14.04, Docker 1.4.1 uname -a:
Linux london 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Client machine: Ubuntu 14.04 VMWare Fusion 7.1.1 VM  (hardware version 11) (provisioned 12GB RAM + 8 cores), Docker 1.5.0 uname -a:
Linux ubuntu 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:23:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Both are using the latest weave release:
sudo weave version
weave script 0.9.0
weave router 0.9.0
weave DNS 0.9.0
weave tools 0.9.0

The client is able to insert small documents into MongoDB over the weave network, but unable to insert large documents, output from sudo tcpdump -i weave on the client machine shows messages about "need to frag"
Sample server setup (server physical IP is <IP_ADDRESS>):
sudo weave stop
sudo weave reset
sudo weave launch
sudo weave expose <IP_ADDRESS>/24
sudo weave run <IP_ADDRESS>/24 -d -t --name=mongo1 -p :27017:27017 mongo:3.0.0 mongod --storageEngine wiredTiger

Client setup:
sudo weave stop
sudo weave reset
sudo weave launch <IP_ADDRESS>
sudo weave expose <IP_ADDRESS>/24

Small write over weave network from client:
docker run -it --rm mongo:3.0.0 mongo "<IP_ADDRESS>:27017/test" --eval "db.somecollection.insert({ a: 'bc'});"
MongoDB shell version: 3.0.0-rc8
connecting to: <IP_ADDRESS>:27017/test
WriteResult({ "nInserted" : 1 })

Large write over the weave network from client (hangs):
docker run -it --rm mongo:3.0.0 mongo "<IP_ADDRESS>:27017/test" --eval "db.somecollection.insert({ a: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'});"
MongoDB shell version: 3.0.0-rc8
connecting to: <IP_ADDRESS>:27017/test

Same large write over the physical network (works fine):
docker run -it --rm mongo:3.0.0 mongo "<IP_ADDRESS>:27017/test" --eval "db.somecollection.insert({ a: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'});"
MongoDB shell version: 3.0.0-rc8
connecting to: <IP_ADDRESS>:27017/test
WriteResult({ "nInserted" : 1 })

Output from client sudo tcpdump -i weave
listening on weave, link-type EN10MB (Ethernet), capture size 65535 bytes
10:50:55.405307 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
10:50:55.407795 ARP, Reply <IP_ADDRESS> is-at be:1b:9e:e8:24:8e (oui Unknown), length 28
10:50:55.407832 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [S], seq 164960364, win 29200, options [mss 1460,sackOK,TS val 20069498 ecr 0,nop,wscale 7], length 0
10:50:55.409096 IP <IP_ADDRESS>.27017 > <IP_ADDRESS>.47892: Flags [S.], seq<PHONE_NUMBER>, ack 164960365, win 43690, options [mss 65495,sackOK,TS val 15892260 ecr 20069498,nop,wscale 7], length 0
10:50:55.409137 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [.], ack<PHONE_NUMBER>, win 229, options [nop,nop,TS val 20069499 ecr 15892260], length 0
10:50:55.409334 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [P.], seq 0:60, ack 1, win 229, options [nop,nop,TS val 20069499 ecr 15892260], length 60
10:50:55.410562 IP <IP_ADDRESS>.27017 > <IP_ADDRESS>.47892: Flags [.], ack 61, win 342, options [nop,nop,TS val 15892261 ecr 20069499], length 0
10:50:55.411040 IP <IP_ADDRESS>.27017 > <IP_ADDRESS>.47892: Flags [P.], seq 1:80, ack 61, win 342, options [nop,nop,TS val 15892261 ecr 20069499], length 79
10:50:55.411074 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [.], ack 80, win 229, options [nop,nop,TS val 20069499 ecr 15892261], length 0
10:50:55.412388 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [P.], seq 60:122, ack 80, win 229, options [nop,nop,TS val 20069500 ecr 15892261], length 62
10:50:55.414015 IP <IP_ADDRESS>.27017 > <IP_ADDRESS>.47892: Flags [P.], seq 80:274, ack 123, win 342, options [nop,nop,TS val 15892261 ecr 20069500], length 194
10:50:55.416389 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [P.], seq 122:955, ack 274, win 237, options [nop,nop,TS val 20069501 ecr 15892261], length 833
10:50:55.416545 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> unreachable - need to frag (mtu 490), length 36
10:50:55.416597 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [.], seq 122:622, ack 274, win 237, options [nop,nop,TS val 20069501 ecr 15892261], length 500
10:50:55.416602 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [P.], seq 622:955, ack 274, win 237, options [nop,nop,TS val 20069501 ecr 15892261], length 333
10:50:55.416633 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> unreachable - need to frag (mtu 490), length 36
10:50:55.418500 IP <IP_ADDRESS>.27017 > <IP_ADDRESS>.47892: Flags [.], ack 123, win 350, options [nop,nop,TS val 15892263 ecr 20069500,nop,nop,sack 1 {623:956}], length 0
10:50:55.620941 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [.], seq 122:622, ack 274, win 237, options [nop,nop,TS val 20069552 ecr 15892263], length 500
10:50:55.621070 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> unreachable - need to frag (mtu 490), length 36
10:50:56.028061 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [.], seq 122:622, ack 274, win 237, options [nop,nop,TS val 20069654 ecr 15892263], length 500
10:50:56.028278 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> unreachable - need to frag (mtu 490), length 36
10:50:56.845105 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [.], seq 122:622, ack 274, win 237, options [nop,nop,TS val 20069858 ecr 15892263], length 500
10:50:56.845278 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> unreachable - need to frag (mtu 490), length 36
10:50:58.479914 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [.], seq 122:622, ack 274, win 237, options [nop,nop,TS val 20070267 ecr 15892263], length 500
10:50:58.480052 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> unreachable - need to frag (mtu 490), length 36
10:51:01.748340 IP <IP_ADDRESS>.47892 > <IP_ADDRESS>.27017: Flags [.], seq 122:622, ack 274, win 237, options [nop,nop,TS val 20071084 ecr 15892263], length 500
10:51:01.748508 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP <IP_ADDRESS> unreachable - need to frag (mtu 490), length 36

Server docker logs weave output
weave 2015/03/18 14:41:05.486129 Command line options: map[wait:20 iface:ethwe name:7a:46:86:82:f5:92]
weave 2015/03/18 14:41:05.486195 Command line peers: []
weave 2015/03/18 14:41:06.487123 Communication between peers is unencrypted.
weave 2015/03/18 14:41:06.487661 Our name is 7a:46:86:82:f5:92
weave 2015/03/18 14:41:06.518895 Sniffing traffic on &{312 65535 ethwe d6:9e:64:84:78:ca up|broadcast|multicast}
weave 2015/03/18 14:41:06.518944 Discovered our MAC d6:9e:64:84:78:ca
weave 2015/03/18 14:41:06.614431 Discovered local MAC 32:ac:71:ec:0d:24
weave 2015/03/18 14:41:06.990526 Discovered local MAC 7a:46:86:82:f5:92
weave 2015/03/18 14:41:08.091084 ->[<IP_ADDRESS>:51570] connection accepted
weave 2015/03/18 14:41:08.092523 ->[<IP_ADDRESS>:51570] completed handshake with 7a:8a:74:ed:7c:64
weave 2015/03/18 14:41:08.092873 ->[7a:8a:74:ed:7c:64]: connection added
weave 2015/03/18 14:41:08.095855 ->[7a:8a:74:ed:7c:64]: connection fully established
weave 2015/03/18 14:41:08.095909 EMSGSIZE on send, expecting PMTU update (IP packet was 60064 bytes, payload was 60056 bytes)
weave 2015/03/18 14:41:08.095928 ->[7a:8a:74:ed:7c:64]: Effective PMTU set to 1438
weave 2015/03/18 14:41:08.099198 ->[7a:8a:74:ed:7c:64]: Effective PMTU verified at 1438
weave 2015/03/18 14:41:08.735417 Discovered remote MAC 7a:8a:74:ed:7c:64 at 7a:8a:74:ed:7c:64
weave 2015/03/18 14:41:22.966496 Discovered local MAC aa:df:0e:2b:63:f1
weave 2015/03/18 14:41:47.170530 ->[7a:8a:74:ed:7c:64]: connection shutting down due to error: EOF
weave 2015/03/18 14:41:47.170646 Removed unreachable Peer 7a:8a:74:ed:7c:64 (v5) (UID<PHONE_NUMBER>8048737883)
weave 2015/03/18 14:41:47.170690 ->[7a:8a:74:ed:7c:64]: connection deleted
weave 2015/03/18 14:41:49.646219 ->[<IP_ADDRESS>:51585] connection accepted
weave 2015/03/18 14:41:49.647336 ->[<IP_ADDRESS>:51585] completed handshake with 7a:67:a3:ad:5c:1e
weave 2015/03/18 14:41:49.647479 ->[7a:67:a3:ad:5c:1e]: connection added
weave 2015/03/18 14:41:49.657602 ->[7a:67:a3:ad:5c:1e]: connection fully established
weave 2015/03/18 14:41:49.657720 EMSGSIZE on send, expecting PMTU update (IP packet was 60064 bytes, payload was 60056 bytes)
weave 2015/03/18 14:41:49.657740 ->[7a:67:a3:ad:5c:1e]: Effective PMTU set to 1438
weave 2015/03/18 14:41:49.699386 ->[7a:67:a3:ad:5c:1e]: Effective PMTU verified at 1438
weave 2015/03/18 14:41:50.059363 Discovered remote MAC 86:98:15:dd:e4:ef at 7a:67:a3:ad:5c:1e
weave 2015/03/18 14:41:50.311578 Discovered remote MAC 7a:67:a3:ad:5c:1e at 7a:67:a3:ad:5c:1e
weave 2015/03/18 14:46:42.586514 Discovered local MAC be:1b:9e:e8:24:8e
weave 2015/03/18 14:51:06.527351 Expired MAC d6:9e:64:84:78:ca at 7a:46:86:82:f5:92
weave 2015/03/18 14:52:06.527639 Expired MAC 32:ac:71:ec:0d:24 at 7a:46:86:82:f5:92
weave 2015/03/18 14:52:06.527653 Expired MAC 7a:46:86:82:f5:92 at 7a:46:86:82:f5:92
weave 2015/03/18 14:57:06.528694 Expired MAC aa:df:0e:2b:63:f1 at 7a:46:86:82:f5:92

Client docker logs weave output
weave 2015/03/18 14:41:48.704557 Command line options: map[iface:ethwe name:7a:67:a3:ad:5c:1e wait:20]
weave 2015/03/18 14:41:48.704654 Command line peers: [<IP_ADDRESS>]
weave 2015/03/18 14:41:49.705890 Communication between peers is unencrypted.
weave 2015/03/18 14:41:49.706632 Our name is 7a:67:a3:ad:5c:1e
weave 2015/03/18 14:41:49.738252 Sniffing traffic on &{63 65535 ethwe d6:53:0f:08:71:f5 up|broadcast|multicast}
weave 2015/03/18 14:41:49.738280 Discovered our MAC d6:53:0f:08:71:f5
weave 2015/03/18 14:41:49.738620 ->[<IP_ADDRESS>:6783] attempting connection
weave 2015/03/18 14:41:49.741230 ->[<IP_ADDRESS>:6783] completed handshake with 7a:46:86:82:f5:92
weave 2015/03/18 14:41:49.741735 ->[7a:46:86:82:f5:92]: connection added
weave 2015/03/18 14:41:49.749514 ->[7a:46:86:82:f5:92]: connection fully established
weave 2015/03/18 14:41:49.749593 EMSGSIZE on send, expecting PMTU update (IP packet was 60064 bytes, payload was 60056 bytes)
weave 2015/03/18 14:41:49.749608 ->[7a:46:86:82:f5:92]: Effective PMTU set to 1438
weave 2015/03/18 14:41:49.751365 ->[7a:46:86:82:f5:92]: Effective PMTU verified at 1438
weave 2015/03/18 14:41:50.152645 Discovered local MAC 86:98:15:dd:e4:ef
weave 2015/03/18 14:41:50.404767 Discovered local MAC 7a:67:a3:ad:5c:1e
weave 2015/03/18 14:41:53.299722 Discovered remote MAC 7a:46:86:82:f5:92 at 7a:46:86:82:f5:92
weave 2015/03/18 14:41:55.169164 Discovered remote MAC aa:df:0e:2b:63:f1 at 7a:46:86:82:f5:92
weave 2015/03/18 14:42:32.933803 EMSGSIZE on send, expecting PMTU update (IP packet was 927 bytes, payload was 919 bytes)
weave 2015/03/18 14:42:32.933829 ->[7a:46:86:82:f5:92]: Effective PMTU set to 490
weave 2015/03/18 14:42:32.935258 ->[7a:46:86:82:f5:92]: Effective PMTU verified at 490
weave 2015/03/18 14:42:33.135939 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:33.136136 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:33.340041 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:33.748170 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:34.564017 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:36.200074 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:39.476301 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:46.021177 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:55.819624 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:55.819747 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:56.020357 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:56.428777 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:57.244153 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:58.880001 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:59.108630 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:42:59.516569 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:00.332423 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:01.968884 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:02.148167 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:05.236450 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:08.692113 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:09.100339 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:09.916668 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:11.552377 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:11.780143 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:14.820745 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:21.363987 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:24.868180 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:34.468679 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:43:51.044114 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:44:00.645135 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:46:42.686522 Discovered remote MAC be:1b:9e:e8:24:8e at 7a:46:86:82:f5:92
weave 2015/03/18 14:50:55.416498 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:50:55.416623 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:50:55.621037 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:50:56.028239 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:50:56.845245 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:50:58.480026 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:51:01.748469 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:51:08.292302 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:51:21.380276 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:51:47.524948 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:51:49.740238 Expired MAC d6:53:0f:08:71:f5 at 7a:67:a3:ad:5c:1e
weave 2015/03/18 14:52:39.876569 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:52:49.740522 Expired MAC 7a:46:86:82:f5:92 at 7a:46:86:82:f5:92
weave 2015/03/18 14:54:24.580261 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:56:24.644420 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 14:56:49.741403 Expired MAC aa:df:0e:2b:63:f1 at 7a:46:86:82:f5:92
weave 2015/03/18 14:58:24.965048 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 15:00:25.283968 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 15:02:25.604498 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490
weave 2015/03/18 15:04:25.924619 Sending ICMP 3,4 (<IP_ADDRESS> -> <IP_ADDRESS>): PMTU= 490

During some debugging it became apparent that weave may be having issues with MTU discovery.  Between the client and server exists a firewall whose MTU is set to 1460, but weave is somehow choosing to use an MTU of 490.
When the same test is run from a client/server on the same subnet, there is no issue.
Did a raw tcpdump on the weave interface on server and client in this manner:

reset weave everywhere
sudo weave launch (on server)
sudo tcpdump -i weave -w [capture file] (on server)
sudo weave expose <IP_ADDRESS>/24 (on server)
[run mongo db container command]
sudo weave launch (on client)
sudo tcpdump -i weave -w [capture file] (on client)
sudo weave connect <IP_ADDRESS> (on client .. connects weave network to server)
[run mongo client command to insert large document]

this hangs on step 9 as described above
the raw tcpdump captures for the client/server can be accessed here: https://drive.google.com/folderview?id=0Bxv3aLTVo2eKfkhNSUI3Y2JWb1pnM1VTdVBxdzZoQzBUTTZqTzkwbEVPdldIcTFMNVk4dm8&usp=sharing

Thanks for the pcap files.
There's something conspicuously odd in the client-side capture right from the start.  Although its is sending packets to the server at <IP_ADDRESS>, the resulting packets sent by the sent always come back with the source IP address set to <IP_ADDRESS>.  This is probably an address on the docker network bridge.  I don't know for sure that this is connected to the MTU issue, but I'm surprised the client and server are able to communicate at all.
That strange address is probably due to a poor interaction between the NAT that docker does in order to allow containers on the docker bridge to talk to the outside world, and how 'weave expose' is implemented.
It's hard to say whether this is really a bug or not, because the way you are trying to use weave seems strange. As I understand it, you want to run a mongo server in a container, and a mongo client in a container, talking over the weave network.  Why not do this with 'weave run' on both ends?  You already do that on the server side (and there the 'weave expose' and the port mapping option after 'weave run' appear to be redundant).  But on the client you are starting a container with 'docker run' and relying on 'weave expose' to allow it to talk to the server container.  This is unusual: The intended use of 'weave expose' is to allow things that are not in containers to talk to a weave network.
Does this make sense?  Is there a particular reason why you are trying to use 'weave expose' in that way?  If you use 'weave run' for both the client and server containers, do the large requests work?

I'm using weave expose on the hosts just so that I can confirm that the weave network is working easily using ping
Also, regardless if the mongo client is run from within a container or not, it's the same end result.
However your notes on that <IP_ADDRESS> address made me think twice, this is the VMWare VM NAT...
I just re-tested everything with these scenarios with the VM networking setup:

NAT only (VMWare's default mode), gives a NAT ip of 172.x, this exhibits the problems above
NAT + bridged interfaces, gets a NAT of 172.x and a bridged IP on the physical <IP_ADDRESS>/16 network, this exhibits the same problem as described
bridged interface only, IP on physical <IP_ADDRESS>/16, this is working.

So you're right, it's a problem isolated to my VM network configuration (albeit not working with the default VMWare networking setup of NAT)
But that seems logical, how else would the server host know?

The odd thing here is that quite a lot appeared to work, all the way to doing small inserts in mongo. Ideally at least weave should have detected that something isn't well. Even better if it could have coped and got things to work.

Perhaps 'weave should have detected' could apply equally to #416/#417, which had the similar property that a few things would work even though the network configuration was unhelpful.

@alex-sherwin, thanks for your testing.  I'm still very puzzled by this!
Some thoughts:

There's no real evidence that the MTU issue and the <IP_ADDRESS> destination address shown in the client pcap file are related.  Both are strange, so its tempting to think they are connected, but they might not be.

It's also hard to explain why it would work with vmware in bridged mode but not in NAT mode.  Weave is certainly supposed to work with NAT in the way, and we do a lot of development on VMs with NAT (using various VM technologies).  I doubt that the vmware NAT is doing anything special.  If weave breaks when hosts are talking across a vmware NAT, that sounds like a bug in weave.

The NAT + bridged case is strange too. Why wouldn't weave simply use the bridged network interface, and work as it does in the pure bridged case?  And if so, how could the presence of a NATted interface cause problems if it's not being used?

The pcap files from the client and server sides are captured from the weave bridges.  So they should show exactly what appears at the two endpoints of the weave network.  The packets are being modified in transit, but the weave router does not modify packets in this way. Despite the surprising way 'weave expose' was being used on the client side, that can't be the cause of the <IP_ADDRESS> destination address, because it happens on the other side of the weave bridge.  The only thing I can imagine causing the destination address rewriting is an iptables rule on the client.  But nothing mentioned on this issue suggests that such a rule has been created.

@alex-sherwin, if you are able to do some more testing for us, could you record pcap files as before, but in the case with bridged networking, where the large queries across the weave network succeed?  That will indicate whether the destination address rewriting is really related to the problem or not.

@dpw, I've re-run the exact same test when my VM is running with only a bridged interface.  As mentioned before, this all works with no issues.  Here are the pcap files for this scenario:
https://drive.google.com/folderview?id=0Bxv3aLTVo2eKfkVLcGpHU0RfM2paSElkR2FzRzQxS2QtMm9oSUcwRXdqSFdfSU13UTFwMVE&usp=sharing

@dpw, I've re-run the exact same test when my VM is running with only a bridged interface. As mentioned before, this all works with no issues. Here are the pcap files for this scenario:

Thanks!
On the client side, the destination IP address is still being replaced, so that is not directly the cause of the problem.  The difference in this capture is that there are no ICMP "frag needed" packets generated by weave, suggesting that the effective PMTU on the underlying network was not restricted to 490 as before.
So I have a theory about what is happening when it hangs:  The modification of the destination address is not sufficient to prevent the TCP connection operating (surprisingly).  But it is sufficient to prevent the kernel registering the ICMP "frag needed".  When the client sends a packet that is too large (due to the large write), weave drops it and sends a "frag needed" back to the client side, which ignores it, and after a while TCP resends the packet, which gets dropped with another "frag needed", and so on, hence the hang.  This is visible in the client capture where it hanged.
As I mentioned before, the modification of the destination address suggests an iptables rule.  So @alex-sherwin, could you show the output of sudo iptables-save in the client VM? It doesn't matter what kind of networking the client has for this.  Also, are you using any firewall software within the client VM?
The PTMU of 490 when vmware NAT is used seems strangely low, but is allowed.

@dpw, here's the output of iptables-save in the VM
sudo iptables-save
# Generated by iptables-save v1.4.21 on Fri Mar 20 13:23:21 2015
*nat
:PREROUTING ACCEPT [6:468]
:INPUT ACCEPT [6:468]
:OUTPUT ACCEPT [1022:77063]
:POSTROUTING ACCEPT [922:71063]
:DOCKER - [0:0]
:WEAVE - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d <IP_ADDRESS>/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s <IP_ADDRESS>/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -j WEAVE
-A WEAVE ! -s <IP_ADDRESS>/24 -o weave -j MASQUERADE
-A WEAVE -s <IP_ADDRESS>/24 ! -o weave -j MASQUERADE
COMMIT
# Completed on Fri Mar 20 13:23:21 2015
# Generated by iptables-save v1.4.21 on Fri Mar 20 13:23:21 2015
*filter
:INPUT ACCEPT [75982:28474773]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [81854:30034942]
:DOCKER - [0:0]
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j DROP
-A FORWARD -i weave -o weave -j ACCEPT
COMMIT
# Completed on Fri Mar 20 13:23:21 2015

There is no other firewall of any kind in use in the VM or the VM host

Thanks.  I don't see anything obviously wrong there.  One question though:
...
-A POSTROUTING -s <IP_ADDRESS>/16 ! -o docker0 -j MASQUERADE
...

That suggests docker is using the 172.17.x.x address range on its internal bridge.  Earlier, you said that the same address range is being used by the VMware NAT interface.  Could you double-check that?

I must have looked too quickly.. tey are close but different subnets.  VMWare NAT is 172.16 and docker bridge is 172.17
docker0   Link encap:Ethernet  HWaddr 56:84:7a:fe:97:99
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::5484:7aff:fefe:9799/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:38 errors:0 dropped:0 overruns:0 frame:0
          TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2568 (2.5 KB)  TX bytes:11810 (11.8 KB)

eth0      Link encap:Ethernet  HWaddr 00:0c:29:39:54:c1
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::20c:29ff:fe39:54c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:381947 errors:0 dropped:0 overruns:0 frame:0
          TX packets:221838 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:508118046 (508.1 MB)  TX bytes:19471935 (19.4 MB)

So, I had been trying to reproduce the 172.17.x.x destination addresses from your capture files, without success: tcpdump on the client-side weave bridge just showed 10.0.x.x addresses.  But I was using a Fedora 21 test VM I had lying around to act as the client side.
So today tried with a fresh Ubuntu 14.04 VM.  And it does show the 172.17.x.x destination addresses on the client side!  In exactly the same test scenarios that fedora didn't.  The iptables rules look the same, so I my guess is that a kernel change or patch in one of the distros is responsible, but I haven't looked into that yet (I have docker 1.5 in both cases).
I haven't been able to reproduce the hangs yet.  The PMTU between my weave routers is 1500, so I have to make the "large write" case even large to trigger a "frag needed".  But the write still seems to complete successfully.  I'll work more on this, constraining the MTU to 490 in case that matters.
One thing I didn't appreciate until late yesterday is that the 'weave expose' on the client side is significant.  Without the 'weave expose', if you use 'weave run' for the client container, what happens is that the mongo client tries the request before 'weave run' has had time to set up the ethwe interface, and so the mongo client's attempt to connect to the server simply fails.  With 'weave expose', the ethwe interface still isn't set up in time, so the connection attempt goes to the container's eth0, over the docker bridge onto the host (being masqueraded in the process), and then onto the weave bridge and across the weave network.  I don't think this convoluted path is really anticipated to work, and while it doesn't explain the destination address rewriting, it certainly seems like ample opportunity for odd things like that to happen.  And so, another approach to fixing the hangs might be to run the client under 'weave run' but with a delay so that it does use the ethwe interface.  But I'm going to try to reproduce the hangs before I resort to that.

another approach to fixing the hangs might be to run the client under 'weave run' but with a delay so that it does use the ethwe interface

Instead of a simple delay, the recommended approach is to loop (with a delay) until the interface comes up.

Instead of a simple delay, the recommended approach is to loop (with a delay) until the interface comes up.

Yes, but I imagine that could be hard to achieve in the context of a stripped-down mongodb container.  Whereas it looks like a simple delay is expressible in the mongo shell.

I have found the cause of the hang: although the minimum IPv4 MTU is 68, Linux has a minimum limit on the PMTU of 552: http://cschramm.blogspot.co.uk/2012/12/why-does-linux-enforce-minimum-mtu-of.html
You can change this limit.  So @alex-sherwin, if you do
echo 200 >/proc/sys/net/ipv4/route/min_pmtu

in your client VM, your hang should go away.
I'm still trying to get my head around why Linux sets this limit.
It also goes some way to explaining where the "Effective PMTU set to 490" comes from: effectiveOverhead() = 28 + 6 + (6 + 6 + 2) + 16 = 62.  552 - 62 = 490.
The whole destination address modification thing seems to be a red herring.  If I tcpdump on the weave router containers ethwe interface, I don't see that rewriting.  And if I tcpdump on the docker0 bridge, everything is fully NATted.  tcpdumping on the weave bridge seems to show things in a strange halfway state.

Re-tested with a lower /proc/sys/net/ipv4/route/min_pmtu setting and it works this way

Re-tested with a lower /proc/sys/net/ipv4/route/min_pmtu setting and it works this way

Well, that at least confirms that I'm reproducing your problem.
I'm still not sure why the PMTU on the underlying network would drop to the default Linux minimum of 552.  I wondered if it might be because ICMP "frag needed" packets were being blocked, but I spent some time trying to reproduce that without success.
Also, I'm still trying to think of anything useful weave can do to work around this problem, but I don't have any bright ideas so far.  The best might simply be to show the problem in the weave status output.

@dpw, I'd be fine with that.. the worst part is always not knowing.  I (and hope anyone else) wouldn't be using a VMWare NAT in this manner for anything other then development purposes

@dpw

The best might simply be to show the problem in the weave status output.

How hard is that?

How hard is that?

Detect when PMTU for a connection falls such that the overlay MTU is below 552, stash the fact in the connection, and gossip it around.  Sounds doable, but I don't claim to know the gossipy side of things well.
However, I doubt that is the right solution.  When the problem occurs, weave will still be broken, and in circumstances that are already fairly clear from docker logs weave (now we know what to look for).  So we don't gain much at all.
One important consideration that is still not clear is: what conditions cause the PTMU to fall to 552, and how likely do we think they are to occur? If it seems rare, maybe we don't need to do anything.  If it seems potentially common, we should think further about whether weave can reasonably work around the problem.
Last week I talked to a friend who has lots of experience with MTUs and what happens to them when ICMP packets are being blocked, and it sounds like there is a good chance that is the cause.  More experimentation is needed though.
I've been working on other things, but I can drop them to return to this if it's a priority.


Compatibility with Node 15

In Node 15 brfs throw error The "path" argument must be of type string or an instance of Buffer or URL. Received undefined, because in readFile or readFileSync is undefined passed.
Full error:
node:internal/fs/utils:634
    throw new ERR_INVALID_ARG_TYPE(propName, ['string', 'Buffer', 'URL'], path);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string or an instance of Buffer or URL. Received undefined
    at Object.open (node:fs:462:10)
    at ReadStream._construct (node:internal/fs/streams:61:17)
    at constructNT (node:internal/streams/destroy:288:25)
    at processTicksAndRejections (node:internal/process/task_queues:79:21) {
  code: 'ERR_INVALID_ARG_TYPE'
}

Is there any effort to get this merged/released?

Node.js 16 - no error is returned


Chrome 69 audio problems

Suddenly, today the chrome browser updates itself to the newest version, 69, and the webrtc connection is lost.
There were no errors on version 67, but after update, I see this error:
Failed to get access to local media. Error code was NotFoundError.
I was thinking the problem maybe refers to easyrtc, not webrtc in generic form, but when I tested with test.webrtc.org I saw that the microphone is not on the list of devices it wants to allow permissions to use, and even the tests about the camera has been failed.
What should we do now?

I was thinking the problem maybe refers to easyrtc, not webrtc in generic form, but when I tested with test.webrtc.org I saw that the microphone is not on the list of devices it wants to allow permissions to use, and even the tests about the camera has been failed.

Use links above one use easyrtc tha other (the test page does not), we may be able to see if the issue depend local env or remote env

Thanks for the links.
I run the tests you provide in these conditions:
Changing the internet provider was not affected the results. ( I just checked to ensure that)
In chrome 69, most of the tests failed. although the mic and camera are available.
In firefox 63.0.3 most of the tests passed.
chrome result can be seen here, and firefox result here.
I just do the same test on my phone (android 4.4 and latest chrome stable version) and results are as same as firefox.
Why google chrome behaves like this?

Thanks for the links.
I run the tests you provide in these conditions:
Changing the internet provider was not affected the results. ( I just checked to ensure that)
In chrome 69, most of the tests failed. although the mic and camera are available.
In firefox 63.0.3 most of the tests passed.
chrome result can be seen here, and firefox result here.
I just do the same test on my phone (android 4.4 and latest chrome stable version) and results are as same as firefox.
Why google chrome behaves like this?

@AliBahramiEhsan could be chrome WebRTC issue that now amhave been fixed, can you try Chrome 70?

see #415 for beta for adapter 6.4.0 and #433 for PR with latest adapter 7.2.1.


ValueError: array must not contain infs or NaNs

If I follow the 1st example mentioned in the description under "how to use it" I get the following error. The dataset has 578 trials, 306 channels, 375 time points.
#Error:
"array must not contain infs or NaNs")
ValueError: array must not contain infs or NaNs
#Code:
import pyriemann
from sklearn.cross_validation import cross_val_score
load your data
X = ... # your EEG data, in format Ntrials x Nchannels X Nsamples
y = ... # the labels
estimate covariances matrices
cov = pyriemann.estimation.Covariances().fit_transform(X)
cross validation
mdm = pyriemann.classification.MDM()
accuracy = cross_val_score(mdm,cov,y)
print(accuracy.mean())

Try using a oas solver for the covariance.

Can you elaborate your answer? What do you mean by oas solver?

Your dimensionality may be too large to obtain a positive definite covariance matrix which is required in the Riemann geometry, so you need to regularize.
You can change the estimator (not 'solver', my bad) when initializing: cov = Covariance('oas')
See also https://github.com/alexandrebarachant/pyRiemann/issues/14.

Oh. I get it now. Thankyou. It's working.

Yes, this error is due to matrices not being definite positive.
High dimensionality can give sub optimal results, depending on your SNR. if you data are evoked potential, try using XdawnCovariances which perform a dimensionality reduction.
see this example : http://pythonhosted.org/pyriemann/auto_examples/ERP/plot_classify_EEG_tangentspace.html

Okay. Thankyou. Also, while using the Matlab package for covariance toolbox for the same dataset, I get a warning "Warning : Nombre d'itï¿½rations maximum atteint". I think it is while calculation of Riemannian Mean. Can you tell me what does this warning mean and how can it affect the calculation of covariances or its mean & distances?
I also left a similar question at the toolbox on GitHub but I am not sure if you saw it. I hope you will answer it soon.

indeed, i missed it. I answered the question in the other thread. This problem is not present in the python toolbox.


Fix server installation and unwanted file deletion

Server will now close on successful installation or error to properly load up mods at the next start.
Prevents MCIL from deleting what it considers it to be "empty files" at every load which would often have it deleting important files. Now it shall only do so prior to an installation.

Added progress count server side so users can see the installation progress:
Before (MCIL 2.4):

**After ** (MCIL 2.5):

Also the log will now print "The server will now restart to complete the setup." when the installation process is complete to prevent crash confusion:

@DrParadox7 Very good work !
About the file deletion patch, i now see what you were talking about. The mod can indeed cause issues by deleting files too early, i thought about it at the time but i forgot this issue.
Your patch can work indeed (i'll see what i can do more in 3.0 as it's gonna be a different beast), but it would break the update checker, i'd change the code to be something like this instead:
        String[] list = FileHelper.listDirectory("mods", true);
        for (String s : list) {
            long size = -1;
            try {
                size = Files.size(Paths.get("mods" + File.separator + s));
            }
            catch (Exception ignore) {}

            if (size == 0 && (FileHelper.exists(Config.configFolder + "pack.mcinstance") || s.startsWith("mcinstanceloader"))) FileHelper.delete("mods" + File.separator + s);
        }

The restart patch is perfect pretty much, i can't believe i forgot it xD
The server additions patch is also pretty good, i'd just remove the pipe separator (|) as i feel it makes the line slightly harder to read.
Same thing for the localized overrides. I haven't tested it but from what i see it shouldn't cause any issue. Could you rename the folders to client-overrides and server-overrides instead of using underscores (_)? I feel this would work better as a file name.
If you make those changes, i'll merge the PR and release 2.5 quickly after :D

Done.
I did also reworded some of the comments/logs to be more accurate.


Fix reference - Listeners not working

For use listeners add implementation "org.jetbrains.anko:anko-sdk25-listeners:0.10.8" in build.gradle

I've found that none of my listeners will fire in a release build, although they work as expected from the debugger. Adding implementation "org.jetbrains.anko:anko-sdk25-listeners:0.10.8" doesn't seem to fix it.
 Shame.


Python function Docstrings write up guidelines

Which will have high precedence.

Function Documentation
Description of argument
Example of function
Argument example

This is something we don't mandate apart from known community Python doc string.  There are examples already in the code in openbmc test Please follow it and if extra input feedback is required, we will see it on use case basis. since we don't plan to revamp all our documentation.


chore: update ipfs

Resolves #186

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Looks like the tests just need updating:
+<EMAIL_ADDRESS>-<EMAIL_ADDRESS>    at file:///home/runner/work/generator/generator/test/api/update.test.js:54:10 {

Also, please sign the digital CLA per the comment.
For IPFS testing, we likely will need to uncomment that section in the workflow, it seems I removed it in the Chomp PR https://github.com/jspm/generator/pull/101.

Ipfs works properly now. Both in my system, and also I added it in the CI.

Hey Guy, sure, I'm going to work on it.

@guybedford Green now.

@guybedford How can we resolve the lit issue in the ci?

What's the CI issue?

Oh, i see the ci is updated now, ok, nothing for now.

Green now.


additional description on token location attributes

this is necessary as they aren't all 0 or 1 indexed
(cherry picked from commit 0aa07e5ae10d5420ec03c37b9e4978f5d8caf94e)

Thanks @NaridaL this is very descriptive and useful information for end-users 👍


ISA-33 Interface for Viewservice plus added the role switchbox

Interface for Viewservice plus added the role switchbox

LGTM!


css not getting precompiled

I have a standard Rails 3.1.1.rc1 application set up. The only thing I have done to this point:

rails new myapp -T -d postgresql
Edited gemfile to add active_admin and a few other gems
Moved sass-rails out of assets group as per issue #447
Set up a very simple index page and set root :to => this page, which has no dynamic content
migrated the database and run in development mode. Everything runs fine.
Send the app over to the production server (Apache2, Passenger, Postgresql), migrate database and access the /admin

At this point I get a 500 error. So checking the production log, I get
ActionView::Template::Error (active_admin.css isn't precompiled):
    6:   <title><%= [@page_title, active_admin_application.site_title].compact.join(" | ") %></title>
    7:
    8:   <% ActiveAdmin.application.stylesheets.each do |path| %>
    9:     <%= stylesheet_link_tag path %>
    10:   <% end %>
    11:   <% ActiveAdmin.application.javascripts.each do |path| %>
    12:     <%= javascript_include_tag path %>

So, I open up a terminal and do
rake RAILS_ENV=production assets:precompile
And all the assets are compiled, except for the active_admin.css. I can see that the active_admin.css.scss file is in app/assets/stylesheets but for some reason it is being skipped.
Here is the gemfile:
gem 'rails', '3.1.1.rc1'

gem 'pg'
gem 'sass-rails', "  ~> 3.1.0"
group :assets do
  gem 'therubyracer'
#  gem 'sass-rails', "  ~> 3.1.0"
  gem 'coffee-rails', "~> 3.1.0"
  gem 'uglifier', '>= 1.0.3'
end

gem 'jquery-rails'
gem 'ancestry'
gem 'cancan', :git => "git://github.com/ryanb/cancan.git", :branch => "2.0"
gem 'friendly_id'
gem 'role_model'
gem 'activeadmin'

group :development, :test do
  gem 'guard-rspec'
end

group :development do
  gem 'rspec-rails'
  gem 'unicorn'
  gem 'capistrano'
end

group :test do
  gem 'rspec'
  gem 'webrat'
  gem 'factory_girl_rails'
end

Other than the above gemfile and very basic index page I have made no modifications to the application.

requiring sass-rails from "3-1-stable" branch in my Gemfile solved me all the troubles I had with this precompiling.

doesn't work even adding config.assets.precompile += %w[active_admin.css active_admin.js] to production :(

Yeah, I'm still having this issue on Rails 3.1.1 with the configuration in place, and I manually precompiled assets on the server with the rake task.

Could you also update http://activeadmin.info/documentation.html with this "tip"?

I sent this pull request that solves the problem adding the assets to the precompile list in the engine itself:
https://github.com/gregbell/active_admin/pull/822

config.assets.compile = true

This worked for me thanks.

@abuisman Yes, it works, but that way the assets are compiled after the first request and it can take time. And if you have an assets server you need to compile the assets locally before sending them to the assets server.
My pull request remove the necessity of having to modify production.rb to include something that is related with the gem.

@reqorder  will that be
config.assets.precompile += ['active_admin.css.scss', 'active_admin.js'] or just
config.assets.precompile += ['active_admin.css', 'active_admin.js'] ? I tried config.assets.precompile += ['active_admin.css', 'active_admin.js'] by putting it in production.rb, but I am getting some 2-3 files as empty in production. But those are working well in development..


Policy agent

@alexwlchan - Thanks for the feedback, but this isn't actually meant to be up for review.
Meant to put this against my own private master, but I must have messed up creating the PR.  I just wanted to see a nice diff.

@caseydavenport Oh well, that's what I get for idling through our repos on my lunch break.


Incompatible with 1.16.4

Mod currently requires below version 35 of forge to load. Version 35 is required to load Minecraft 1.16.4.

If it's just changeing the version numbers, I hope to have it fixed tomorrow.

If it's just changeing the version numbers, I hope to have it fixed tomorrow.

it works fine now, whether that be because it was fixed or if it's just me

it works fine now, whether that be because it was fixed or if it's just me

Forge-1.16.5 and Fabric-1.17 released


Initial-state callback docs, use case could be improved

The docs for callbacks on the initial state suggest that you (a) use a before_save hook or (b) call the starting event yourself.  The logical choice is to do both, e.g.:
class Model < ActiveRecord::Base
  before_save :start

  state_machine :state, :initial => nil do
    event :start do
      transition all => :started
    end
  end
end

However, this results in an infinite recursion.
Easy fix: say "Don't do that."
Better fix: It'd be really nice if you could, somehow, do that; even a special after_initialize hook would be better than having to call the start  event manually from the controller.
Best fix: Couldn't you rework that after_initialize hook so it gets called when you set the initial state?

Thanks for the feedback!  I've updated the docs to provide all of the various techniques that can be used and corresponding examples.  I think one of these 3 solutions should be sufficient for hooking into the initial state change.  I would prefer to be consistent in how transition callbacks get defined (whether that's for the initial transition or not) than introduce a new callback that's specific to the initial state.
The consistency is the main reason I've historically been against an initial-state-specific callback.  The callback really doesn't end up providing much info until the record gets saved.  Even once it's hooked into that spot, the lack of an event or from state makes it inconsistent with all other callbacks and, I think, confusing to work with.
I prefer to design the state machine definition to meet the needs for an initial state callback.
Hope this helps!


Cleanup original Bigtable Benchmarks

There's probably more to do, but at least:

Modernize the command line parsing. Currently, if you want to set one option, you must set all options listed before it. This can be made cleaner by using OptionDescriptor.

Change the table prefixes so that they match this regex. Then, if they leak, they will get cleaned up.

I could be wrong, but looks like setup.h is only included in embedded_server.cc and BenchmarkSetupData isn't even actually used. Remove it?

At the moment, setup.h is also included in benchmark.h, the base class for the old benchmarks. They all use the MakeBenchmarkSetup() method, for example, here: https://github.com/googleapis/google-cloud-cpp/blob/8794ddcc40c2211ada81c4d67a782112ba864504/google/cloud/bigtable/benchmarks/apply_read_latency_benchmark.cc#L106
The cleanest solution to this problem probably involves removing setup.h, and starting over with an Options-based approach, like in mutation_batcher_throughput_benchmark.cc.


Not working when phone screen is off

Hii, This package works fine when screen is on . But if i lock the device means it is not working. Can you please suggest me any solution ?

Ios, android or both?

I've tested on Android

notification is show?
-> android only work. when notification show
may be api v12??(i don't remember) above, you must setting battery optimization ( set : always on )

I'm experiencing same issues. @SurajMohanty02 were you able to resolve this?

Make sure these steps are configured correctly:

Yea. I have these configured correctly but still nothing.

the same

Any solutions so far?

w

Are you using this library for getting location ? If so then use react-native-get-location

The same

You need to turn off battery Optimization or Power Saving Mode for your app in Setting, if you using android 13, let check the notification, background actions need the notification.


kedro-telemetry causes error in read-only environments

Description
Details still TBC, but there are hints that kedro-telemetry>=0.3.1 can produce an error when running on a read-only environment.
Context
https://linen-slack.kedro.org/t/22727587/hi-everyone-i-am-new-to-kedro-and-i-am-wondering-how-we-can-#66d97df5-5f59-4c93-a9f1-f68b5cef416f
The user was trying to run a pipeline on Google App Engine like this:
from kedro.framework.session import KedroSession
from kedro.framework.startup import bootstrap_project
from pathlib import Path
bootstrap_project(Path.cwd())
with KedroSession.create(save_on_close=False) as session:
    session.run()

(Following this link: https://docs.kedro.org/en/stable/kedro_project_setup/session.html)
cc @oscarvilla

Reached out to the user to get some details.

For completeness, I'm running the pipeline just with kedro run.
And when I remove telemetry from the requirements.txt passed into the App Engine builder/deployer, the read-only error disappears.

Thank you, @oscarvilla!
Some additional context:

The user sees a log.error message that we output, but the error itself is caught, so it does not affect the execution
That's the expected behaviour for read-only environments; here is how we handle it: https://github.com/kedro-org/kedro-plugins/blob/24cd01c23dc36145ff7893f5497df86960a0f68f/kedro-telemetry/kedro_telemetry/plugin.py#L112
In this case, project_id is considered as not set

It doesn't look like any immediate fixes are required, but we can consider the following:

Change the log lever from error to warning so it doesn't look scary to users.
Show it only once for read-only environments now we log it every time we collect the telemetry
Do not show it to users at all but log it at telemetry, so we know it's a read-only environment

Agreed with all the points @ElenaKhaustova !

Also flagged by a user: https://github.com/kedro-org/kedro/issues/4066


Implemented support to be able to strip the ShaderDebugInfo in Rendedoc

It works this way:
The GameEngine stored the original shader blob on disk.
Than we add the path to that file to the D3D_BLOB_PRIVATE_DATA section of the shader blob.
After that we can strip the Debug information with D3DCOMPILER_STRIP_DEBUG_INFO.
Renderdoc will first check if the shader already has debug information.
If it cannot find the PDB in the shader blob it will try to look for a PrivateDataSection.
If there is a valid file path in the PrivateDataSection it will search for debug information in there.
If it finds valid debug information it will replace the entire shader blob with the one loaded from disk.
Pseudo example code engine side:
ID3DBlob* originalShader = ....
char* shaderPathOnDisk = SaveShaderToDisk(originalShader);
ID3DBlob* shaderWithDebugAnnotation = nullptr;
D3DSetBlobPart(originalShader->GetBufferPointer(), originalShader->GetBufferSize(), D3D_BLOB_PRIVATE_DATA, 0, shaderPathOnDisk, strlen(shaderPathOnDisk) + 1, &shaderWithDebugAnnotation);
ID3DBlob* strippedShader = nullptr;
D3DStripShader(shaderWithDebugAnnotation->GetBufferPointer(), shaderWithDebugAnnotation->GetBufferSize(), D3DCOMPILER_STRIP_DEBUG_INFO, &strippedShader);

I'm a bit skeptical against interpreting arbitrary user-supplied data as a path.
If it looks like an UNC path, you'll be walking the network. If it's begins with a drive, it can trigger very undesired options if it touches a slow device, an optical device or a network share.
What kind of codepage is the path in, ACP? What if the encoding doesn't match what the current user has set?
I'm not  to sound negative, but I'm not sure that this ad-hoc scheme belongs in RenderDoc, particularly without any form of magic constants in the PrivateData.

I think the feature is OK in principle, I had planned to add something along these lines myself as it's quite useful for codebases where actually plumbing through the unstripped shaders is difficult. It's weird that there's still no API way to do it, but this is a good workaround. I think I'll add an alternate scheme that uses SetPrivateData the same as setting debug names, but that's complimentary to this implementation.
For users of RenderDoc you pretty much implicitly trust the logs so I don't think there's any point worrying about malicious data captures, but I agree we could maybe add some kind of identifier before the path to be sure that this is intended and not accidentally misinterpreting someone using the private data for something else.
The string would be expected in UTF-8 I think, the same as every other string in RenderDoc. That's what FileIO::fopen expects (it converts UTF-8 to wide-chars for passing to the OS).

A magic constant will not really protect against any malicious use.
What would help a bit more and what I would like to have implemented is a relative path and a search folder set in renderdoc options. But after talking to baldur we decided its too difficult to pass this data for now and we decided for the ad-hock solution instead.

I've manually merged this in now. I made a couple of changes - you can specify the path at runtime with SetPrivateData(), and the offline blob-part must contain the same GUID used in SetPrivateData() as a magic number.