[WIP] Implement mailchimp subscriptions

First a warning. If you google for the official ruby mailchimp client you get https://bitbucket.org/mailchimp/mailchimp-api-ruby
TL;DR: Don't use it.
Don't be fooled by the fact that the account name is mailchimp. MailChimp didn't even know this wrapper existed until I pinged one of their employees in a DM yesterday. The API that it talks to has been scrapped (https://devs.mailchimp.com/blog/sunsetting-previous-mailchimp-api-versions/).
If you want the even longer version of this story—the one with yaks—I'll tell you  sometime.
Anyway. There are no official API wrappers for MailChimp. We're only talking to one endpoint, so I just went with plain HTTP calls with Faraday. I stuck it all in its own class, I may have gone overboard with the methodization (random bits of data make me confused and nervous, so I err towards the verbose when talking to APIs that are unknown to me).
There are a few things I wasn't sure what to do with:

The default for the API (with an API key) is basic auth. The transport is over HTTPS, so that might not be as terrible as it sounds, but still. We may want to consider using oauth instead of the API key (docs here: http://developer.mailchimp.com/documentation/mailchimp/guides/how-to-use-oauth2/)
Error handling in the controller. It's kind of gross right now, but I really don't know what sort of things will typically go wrong. For now I'm just logging errors and apologizing and moving on.
I don't think we're showing flashes yet
I don't HTML and CSS very well
We need copy for the newsletter part

Happy open source Friday! ✨ 💛  ✨

I'm not sure why the build is failing—there's no error that I can see in the tests, it just says that the build script exited with 2.

I'm not sure why the build is failing—there's no error that I can see in the tests, it just says that the build script exited with 2.

It's an issue with insufficient code coverage:

Coverage (51.50%) is below the expected minimum coverage (80.00%).

Anyway. There are no official API wrappers for MailChimp. We're only talking to one endpoint, so I just went with plain HTTP calls with Faraday. I stuck it all in its own class, I may have gone overboard with the methodization (random bits of data make me confused and nervous, so I err towards the verbose when talking to APIs that are unknown to me).

:+1: :sob:

The default for the API (with an API key) is basic auth. The transport is over HTTPS, so that might not be as terrible as it sounds, but still.
Error handling in the controller. It's kind of gross right now, but I really don't know what sort of things will typically go wrong. For now I'm just logging errors and apologizing and moving on.

These are fine with me as-is 👍

I don't think we're showing flashes yet

Yeh, would be good to get that before we 🚢 this. I can have a look if that'd be good.

I don't HTML and CSS very well
We need copy for the newsletter part

Similarly: I can take a look at these and push to your PR if that's 🆒 with you.

For the test coverage, what do you think: VCR?
If you'd do the flashes and other HTML+CSS stuff that would be fantastic.

For the test coverage, what do you think: VCR?

Yeh 👍

If you'd do the flashes and other HTML+CSS stuff that would be fantastic.

Sure!

Rubocop is complaining about this:
app/controllers/subscriptions_controller.rb:6:21: C: Use && instead of and.
    redirect_to "/" and return unless current_user
                    ^^^

Rubocop is wrong. This is not a boolean and. It's control flow. Booleans should not be used for control flow.

I added mailchimp env vars to the Travis repo settings, since the mailchimp test relies on them.

They've classified boolean vs control flow as wonfix https://github.com/bbatsov/rubocop/issues/1288.
I've rewritten the code to be on multiple lines to avoid the whole thing :sob:

@kytrinyx Random question that just occurred to me: I was looking at the styling of the Open Source Guides mailing list subscribe and thought that they aren't doing anything server-side because it's hosted on Pages. Check out their form here: https://github.com/github/opensource.guide/blob/74ea45e7de269507cecf1f9989cb2c99f5ad36fa/_includes/footer.html#L22-L38
Would we be able to take a similar approach to avoid needing the server-side logic? Are there pros/cons of the server-side approach that I've missed? Thanks!

Check out their form here: https://github.com/github/opensource.guide/blob/74ea45e7de269507cecf1f9989cb2c99f5ad36fa/_includes/footer.html#L22-L38

Less useful than that may be the PRs/commits with the diffs adding them:
https://github.com/github/opensource.guide/pull/110/files
https://github.com/github/open-source-survey/commit/ed999c4e254a7afccf29e8aba4f74ab64afe9143
https://github.com/github/open-source-survey/pull/87/files
Looks like we would need a form and JavaScript library.

It didn't even occur to me that this was an option. That would be MUCH better.
In that case whoever has access to the mailing list needs to go generate the embed.


No clean option

Would be good to have a no-clean option so the dist folder isn't destroyed every time when the project is being built

What should Gridsome do with the content while building? Overwrite existing files and leave the rest? Gridsome 0.6 (published yesterday) will keep the folder but delete its content. But we will keep the content between builds when we have incremental builds working :)


Share DEK resources across channels

Type of change

Enhancement / new feature

Description
Creating new DEKs for every channel is relatively wasteful. We are taking the cost of making more KMS operations at encrypt and then decrypt time, when more keys have to be unwrapped to decrypt. We can make more effective use of each generated DEK while still keeping the guarantees around only using a DEK for some limited amount of encryption invocations.
This change:

Makes KeyManager cached per event-loop, so all EnvelopeEncryptionFilter instances associated with channels registered with this event loop will share an InBandKeyManager
Similarly, makes the KekSelector cached per event-loop
Makes the KMS instance "application-wide" so there is one instance created at initialisation time for that filter config.
Introduces a DekAllocator, also "application-wide" that is used to share DEKs across event-loops

The InBandKeyManager uses the DekAllocator to obtain a DEK that can be used for N encryptions (this amount is configurable in InBandKeyManager). The idea is the InBandKeyManager for an event-loop would request a large allocation of encryption operations that it can use for many messages before asking for another allocation. This number will be dwarfed by the 2^32 recommended max invocations per DEK so we can allocate the same DEK many times including handing it out to multiple InBandKeyManager in parallel.
The end result is one DEK can be used by all channels.
Checklist
Please go through this checklist and make sure all applicable tasks have been done

[ ] Write tests
[ ] Make sure all tests pass
[ ] Review performance test results. Ensure that any degradations to performance numbers are understood and justified.
[ ] Make sure all Sonar-Lint warnings are addressed or are justifiably ignored.
[ ] Update documentation
[ ] Reference relevant issue(s) and close them after merging
[ ] For user facing changes, update CHANGELOG.md (remember to include changes affecting the API of the test artefacts too).

After reading your other issue about the Mediator now I'm thinking if destruction is a problem. I don't think I've touched destruction logic so if we exhaust a KeyContext it will destroy the SecretKey potentially referenced by other KeyContexts :facepalm:

I might call this a spike since it's raised some interesting ideas like the KmsMediator in #893 and I'm not convinced about keying on the eventloop executor. Don't want it to delay 0.5.0 either.


TypeScript 4.2 caches cwd between builds when using the programatic api

Bug Report
When using TypeScript 4.2 from the programmatic API, it seems to cache the CWD between runs. I don't think this is the desired effect. This can result in "Cannot read file '..../tsconfig.json'"
🔎 Search Terms
cwd, current working directory

🕗 Version & Regression Information

This bug started in 4.2.2.
Earlier versions as far back as 3.7 work as expected.
Nightly typescript@next also has this problem.

⏯ Playground Link
Programmatic API, so no playground link available. I made a small repro repo:
ts-cwd-issue.zip
Unzip, npm i and node compile.js.
💻 Code
// @ts-check
const ts = require('typescript');
const path = require('path');

async function build(tsconfig) {
    return new Promise(res => {
        const compiler = ts.createSolutionBuilderWithWatch(
            ts.createSolutionBuilderWithWatchHost(ts.sys,
                undefined,
                (error) => console.error(tsconfig,'error: ', error.messageText),
                (status) => console.log(tsconfig,'status:', status.messageText),
                (summary) => {
                    console.log(tsconfig, 'summary: ', summary.messageText);
                    res();
                }
            ),
            [tsconfig],
            {}
        );
        compiler.build();
    });
}

async function main() {
    process.chdir(path.resolve(__dirname, 'sample-a'));
    await build('tsconfig.a.json')
    process.chdir(path.resolve(__dirname, 'sample-b'));
    await build('tsconfig.b.json')
}

main().catch(console.error);

🙁 Actual behavior
$ node compile.js
tsconfig.a.json summary:  Found 0 errors. Watching for file changes.
tsconfig.b.json error:  Cannot read file '.../sample-a/tsconfig.b.json'.
tsconfig.b.json summary:  Found 1 error. Watching for file changes.

🙂 Expected behavior
$ node compile.js
tsconfig.a.json summary:  Found 0 errors. Watching for file changes.
tsconfig.b.json summary:  Found 0 errors. Watching for file changes.

Ping @RyanCavanaugh I think this is not a bug.. For each (Solution, watch, program) we have host that let you specify these methods and caller has option to override default behavior there. Refer to discussion on #43158


Drop unused variables in torchvision

Differential Revision: D33733360

Thanks for the PR @r-barnes
We can't merge the PRs that are exported via the export bot as torchvision has a specific syncing process (different from Pytorch). I'll close this PR and I'll re-export the diff manually once it's landed in fbcode. I'll approve the diffs there. Thanks!


update the rpc_parallel submodule again with the gethostname removal

This was accidentally downgraded. Without this fix, mac integration tests won't run (with this fix, I'm not sure if they will).

@psteckler the latest downgrade happened in bbf68d6bcda9304deda855e7f752d7a061ee13e8 (merge of #4001)


Dictionary of <string, object> ignores attributes

Source/destination types
(Using this in Unity, hence the Vector3, which has various self-referencing properties)
public interface IExampleClass {

}

public class ExampleSubClass : IExampleClass {
    [JsonIgnore]
    public Vector3 ignoredVector = Vector3.one;
    public string publicString = "hello";
}

Dictionary<string, IExampleClass> lotsOfInstances = new Dictionary<string, IExampleClass>();

lotsOfInstances.Add("foo", new ExampleSubClass());

Dictionary<string, object> data = new Dictionary<string, object>();

data.Add("bar", lotsOfInstances);

JsonConvert.SerializeObject(data, Formatting.Indented);

Expected behavior
It should serialise with the public string and ignore the vector.
Actual behavior
It ignores the JsonIgnore and tries to serialise the vector. This is a heavily simplified version of what I'm actually doing, and I think the issue lies with the Dictionary<string, object> as I have no issue with the attributes when I serialise lotsOfInstances directly.
Steps to reproduce
See above.

Turns out this wasn't a bug, I'd just never had this mixture alongside using [System.Serializable] before so didn't realise that it overrides your JsonIgnore and JsonProperty attributes


support arguments on darwin

Pretty straightforward and works as expected

It occurs to me that it probably needs to be run through text/template's html function of something similar for safe escaping

I've just pushed a change that escapes the plist xml. Could you test?

yep, seems to work fine


Breaks vim-prosession

Hi,
Thanks for all the hard work on this. It's definitely my favourite neovim GUI I've used. There's one issue though. I usually rely on vim-prosession to automatically load my previous files and working directory. I've confirmed that this works correctly with nvim in the terminal. However, with goneovim it always launches at /, not loading my previous session. I'm running on macOS Catalina. I suspect the built-in workspace manager is interfering. I've tried disabling all goneovim features using
ginitvim = '''
  augroup GonvimAu
    autocmd!
  augroup end
  augroup GonvimAuStatusline
    autocmd!
  augroup end
  augroup GonvimAuLint
    autocmd!
  augroup end
  augroup GonvimAuMd
    autocmd!
  augroup end
  augroup GonvimAuFilePath
    autocmd!
  augroup end
  augroup GonvimAuMinimap
    autocmd!
  augroup end
  augroup GonvimAuScrollbar
    autocmd!
  augroup end
'''

, but it still did not work.

Hi :)
Thanks for using goneovim.
Sorry for the late reply.
I began to investigate this issue.
Certainly launching from goneovim.app will give me an error.
However, booting from the terminal appears to restore the previous session.
/Applications/goneovim.app/Contents/MacOS/goneovim

Would that be the case in your environment as well?
I also believe that disabling Ginitvim in setting.toml is ineffective for this problem.

Great, thanks! I'm actually not using vim much these days but if I get a chance to test it out and still get issues, I'll reopen the issue 😄


Update metrics tracker to most recent specifications

Description
This PR applies changes recently discussed. Specifications themselves should now be stable or almost stable. This should therefore be one of the latest associated PRs.
Changes made

See related issue for changes related to the specifications.
Improved implementation by building common payload at a single location.
Always use event creation date as timestamp.
Implement proper session management.

Checklist

[x] APIs have been properly documented (if relevant).
[x] The documentation has been updated (if relevant).
[x] New unit tests have been written (if relevant).
[x] The demo has been updated (if relevant).

@waliid Thanks for the review!


v2ray v5 socks无法使用账号密码

What version of V2Ray are you using?

v5

What's your scenario of using V2Ray?

使用socks连接中转服务器

What problems have you encountered?

从源码看到socks5直接选用了noAuth

What's your expectation?

支持账号密码

Please attach your configuration here

Server configuration:
{
"inbounds": [
{
"protocol": "socks",
"port": "55555",
"settings": {
"udpEnabled": true,
"address":"<IP_ADDRESS>",
"users":[
{
"user": "test",
"pass": "test"
}
]
}
}
],
"outbounds": [
{
"protocol": "freedom"
}
]
}

Client configuration:

// Please attach your client configuration here.

Please attach error logs here
Failed to start: main/commands: failed to load config: [config.json] > infra/conf/v5cfg: unable to build config > infra/conf/v5cfg: unable to load inbound protocol config > common/registry: unable to parse json content > unknown field "users" in v2ray.core.proxy.socks.simplified.ServerConfig

Server error log:

// Please attach your server error log here.

Client error log:

// Please attach your client error log here.

Please attach access log here

// Please attach your server access log here.

Other configurations (such as Nginx) and logs here

If V2Ray cannot start up, please attach output from --test command

If V2Ray service is abnormal, please attach journal log here

从官网文档来看，inbounds里配置是这样的：
https://www.v2fly.org/config/protocols/socks.html#outboundconfigurationobject

@devxu that is the v4 format. On the v5 format, authType is hardcoded to noAuth.

There are some problems with the Socks5 authentication implementation in V2Ray. For example, UDP can be used without authentication, so if you have a need, please use other software.


Review completed blockframes: Navigation, Sub-landing and Detail pages

User story
As a webex designer, we want to review early iterations of new page designs with Prod and Eng so that 1) we can align on the new pages 2) get feedback before adding fidelity and work hand-in-hand in an iterative manner.
Working links
Combined Figma prototype
Page-specific:

Navigation
Sub-landing page

Detail Page

Acceptance criteria

[x] Review design with prod and eng
[ ] Make necessary update to design

Prepped Figma file for review with prod and eng:

Created some page demarcations on Figma: "Ready for review" and "WIP"
Prepped sub-landing and detail pages for review. Added some context information on the left to go with the "Current Iteration" screens.
Added review links that jumps you to the specific screen on figma to the ticket under "Working links"

Prepped Figma file for review with prod and eng:

Created some page demarcations on Figma: "Ready for review" and "WIP"
Prepped sub-landing and detail pages for review. Added some context information on the left to go with the "Current Iteration" screens.
Added review links that jumps you to the specific screen on figma to the ticket under "Working links"

Shared async via Slack

07/06 Presented the blockframes (nav, detail, sublanding page) to the entire team during 16th min after standup. Requested for feedback on figma as comments.

Next steps: Need to review comments and feedback from Etan and Chris. No blockers.

Reviewed the feedback from Etan and Chris:

Responded to Etan [on figma] (https://www.figma.com/file/86JATe4hOwPfihwwloM5b8?node-id=83:719&mode=design#491338059) and as far as an action item from Chris' feedback, tagged Audrey to take a look at the Getting started page title versus Get started btn observation. Re: dynamic content piece, Chris is going to follow up on it.

cc: @jillian-hammer

Noting here that no changes had to be made for the completed blockframes based on the feedback provided.


v4 - Dropdown should adjust its placement to ensure it stays within viewport

With the new version, dropdown content does not reconize, when the element is out of view and does not change the align:

Pretty sure the old version didn't do that either.

Jup it did:

.dropdown-menu-right is probably what you are looking for, this behavior hasn't changed from v3.

@hnrch02 Nope did not add that class to the dropdown

Can you post your v4 test as a JS Bin?

@hnrch02 seems to have to do with being in a navbar I believe
V3 JSBin:
http://jsbin.com/rolitoqewi/edit?html,output

Ah, we used to special-case dropdowns within .navbar-right, but that class is gone in v4.
I do think it would be better to make the feature not navbar-specific. Should be feasible now that we're using Tether (see e.g. http://github.hubspot.com/drop/docs/welcome/ ).

Well, .navbar-right was replaced by .pull-right (for now, as @mdo said in Slack).

A dropdown menu pulled right on a fluid navbar is probably one of the most common use cases.
Perhaps the dropdown menu should default to aligning its right side to the left side of the dropdown element, and the opposite be the special case.

yeah i'd rather us solve this particular use case in css since so easy/common - @mdo what are your thoughts?
we could move dropdown onto tether but makes dropdown plugin a bit more complicated

we could move dropdown onto tether but makes dropdown plugin a bit more complicated

IMHO, I think it's worth doing that. Way more robust.

yeah fair enough

The suggestion of a new placement library here: #19673 - seems to have better support for flipping than Tether.

Untill this is solved (after 1 year of talking about it, here is a quick solution)
ul.pull-right .dropdown-menu {
right: 0;
left: initial;
}
And just add .navbar in front of the selector if you do not need this project wide...

@joviczarko in v4 alpha6 not working. Can you please add demo via JSBin?

This works in v4 alpha6: <div class="dropdown-menu" style="left:initial;right:0;" ...

Closed and fixed by #22444


Attach non-kubernetes container to kubernetes network

I have a use case where I need to start a container "outside" Kubernetes (with docker run, on one of the Kube nodes) and want to attach it to Weave Net in order to communicate with the Kubernetes containers/pods. Can this be done? How?

Yes. However it requires a little thought as weave-kube is deliberately coded to not interact directly with Docker.
You will need the weave script on the machine.
If both weave-kube and your new container are up and running, you can do weave attach <mycontainer> to give it an interface on the Weave network.
If you want the interface to be created as part of docker run you have two options:
Plugin: run weave launch-plugin then docker run --net=weave ...
Proxy: run weave launch-proxy then eval $(weave env) then docker run ...
Do not do weave launch-router or weave launch; those do not coexist with weave-kube
(Typing on my phone; haven't tried the above)

I have a use case where I need to start a container "outside" Kubernetes

Would you mind sharing why you need to do this? I'm intrigued :smile:

Add to docs.

In this instance I have a container that requires a specific MAC address to run. I cannot run such a container under Kubernetes.
Another use case would be non-containerized applications that need to be able to connnect to containerized applications.

I tested out the various options listed a few posts up.
The proxy variant does not seems to work.  I actually like to use this option, because I can use regular docker commands.  Does this option require the Weave router?
Results:
First I install weave with
sudo curl -L git.io/weave -o /usr/local/bin/weave
sudo chmod +x /usr/local/bin/weave

weave attach
** docker run -d --name test --mac-address=xx:xx:xx:xx:xx imagename
** weave attach test

Works OK.

weave plugin : issue with weave container

ERROR: weave container must be running before plugin can be launched

Does not work.

weave proxy : seems OK, but message about running docker daemon

[root@kub-minion1 bergtwvd]# /usr/local/bin/weave launch-proxy
cannot locate running docker daemon
Warning: unable to detect proxy TLS configuration. To enable TLS, launch the proxy with 'weave launch-proxy' and supply TLS options. To suppress this warning, supply the '--no-detect-tls' option.
52af27e3d2b40818a84dcc7dbafa2d4b1407fd8f7f1bd46b4ad4b56d41ad6507
[root@kub-minion1 bergtwvd]# eval $(/usr/local/bin/weave env)
[root@kub-minion1 bergtwvd]# echo $DOCKER_HOST
unix:///var/run/weave/weave.sock
[root@kub-minion1 bergtwvd]# docker ps
CONTAINER ID        IMAGE                                                 COMMAND                  CREATED             STATUS              PORTS               NAMES
8becba9eb175        weaveworks/weaveexec:1.8.2                            "/home/weave/weavepro"   36 seconds ago      Up 36 seconds                           weaveproxy
....
[root@kub-minion1 bergtwvd]# docker run -d --name test --mac-address=xx:xx:xx:xx:xx:xx imagename
be6c7d58847537324ae237d85e504f20e253d6061ef6811767058a58009bca5e
[root@kub-minion1 bergtwvd]# docker exec test ifconfig
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::218:8bff:fe0d:4f0b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:648 (648.0 B)  TX bytes:648 (648.0 B)

ethwe     Link encap:Ethernet  HWaddr 32:3c:bc:64:e9:73
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::303c:bcff:fe64:e973/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1410  Metric:1
          RX packets:4097 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:692566 (692.5 KB)  TX bytes:4063 (4.0 KB)

lo        Link encap:Local Loopback
          inet addr:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

[root@kub-minion1 bergtwvd]#

Seems to work.

Another observation is that Kubernetes containers cannot be addressed by name from the "external" container. DNS name resolution does not work this way. Not a big deal, since I define the external container as Kubernetes service, so that Kubernetes containers and address the external container via the service interface:
{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "crc",
        "namespace": "default"
    },
    "spec": {
        "type": "ExternalName",
        "externalName": "<IP_ADDRESS>",
        "ports": [{ "port": 8989 }]
    }
}

You should be able to include the kube-dns service via docker run ... --dns <address>

ERROR: weave container must be running before plugin can be launched

OK; that's unfortunate.
Another way to go is to abandon weave-kube and install Weave Net first, before Kubernetes.  Then all the options should work.  See https://www.weave.works/docs/net/latest/cni-plugin/

You should be able to include the kube-dns service via docker run ... --dns

As dns address I used the Cluster IP of the kube-dns service in my Kubernetes installation: <IP_ADDRESS>.
And I try to ping xserverapp, an existing running pod.
[root@kub-minion1 bergtwvd]# docker run -d --name test --mac-address=xx:xx:xx:xx:xx:xx--dns=<IP_ADDRESS> imagename
7d37bb1b5cd7220aa180d915914a572e7ca72327d7c0294c087467ce0f3c9807
[root@kub-minion1 bergtwvd]# docker exec -it test bash
root@7d37bb1b5cd7:/tmp/start# ping xserverapp
ping: unknown host xserverapp
root@7d37bb1b5cd7:/tmp/start# ping xserverapp.default.svc.cluster.local
ping: unknown host xserverapp.default.svc.cluster.local

The dns address in unreachable from the test container.
What should I do here?

ERROR: weave container must be running before plugin can be launched

OK; that's unfortunate.
Another way to go is to abandon weave-kube and install Weave Net first, before Kubernetes. Then all the options should work. See https://www.weave.works/docs/net/latest/cni-plugin/

Thanks for the tip. I may do this at some point later (need to re-install Kubernetes).

I poked a bit further on the DNS, now using --dns=<IP_ADDRESS>, the IP address of the DNS pod.
A ping to crc is resolved (runs as an external container on <IP_ADDRESS>), indicating that the DNS lookup works:
root@453c1ec0cfa5:/tmp/start# ping crc.default.svc.cluster.local
PING crc.default.svc.cluster.local (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=63 time=0.217 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=63 time=0.345 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=63 time=0.455 ms

A ping to something internal in Kubernetes is not resolved. Service names are resolved to addresses that are outside reach, e.g. xserverapp corresponds to cluster IP <IP_ADDRESS>.
Will this therefore work?

I managed to recreate this symptom.  Failure to contact kube-dns on the service address is basically the same point as discussed at #2714 - the packets leave via the Docker network interface and hence get blocked by the iptables rule described.
When you switch to the pod address the DNS packets route via the Weave network and so are not blocked.

However, I suspect that Kubernetes does not store the Pod IP addresses/names in DNS, but only the Cluster (Service) IP addresses/names.


allow user to enter relative time to get the history from UI

we can enter only absolute time(date & time) to fetch the history, we should be able to enter the relative time (-3h) to get the history three hours before.

https://github.com/skydive-project/skydive/pull/855


Fallback URLs

This can be used if a user what's to have their local network take priority over ngrok.
First, the local IP is attempted to connect to. It will work when on the home network. If it fails, use ngrok.

I'll try and work on this as many people seem to want this

Does this need a server side update?

Does this need a server side update?

Nah, this is a client side thing. So this would be the flow:
Prerequisites

User sets a fallback server URL (the primary will already be set)

Workflow

User opens the app (or an intent is invoked that spins up the Dart Isolate)
App attempts to connect to socket using primary address
If that connection attempt fails, try the secondary address. If that fails, keep retrying primary, then secondary, primary, then secondary, etc.

Ultimately, the primary address will always be used, unless there is a connection failure. And the secondary will never override the primary as long as the primary connection succeeds.

This kinda exists now with the localhost detection - if proxy services are ever down, users can just flip that on and get a direct connection to server. Is that enough for this ticket or need something more robust @zlshames

I think the localhost thing is a good start, but I don't think it solves this. It's more of, I got a 500 or 404 error or timeout from my primary URL, try with the fallback


Update guider-vi

Q
A

Is bugfix?
yes/no

New feature?
yes/no

Breaks BC?
yes/no

Tests pass?
yes/no

Fixed issues
comma-separated list of tickets # fixed by the PR, if any

Merged. Thank you!


Conventions for string and character array encoding

As discussed here https://github.com/Unidata/netcdf4-python/issues/654#issuecomment-298284181, there is a need for conventions to specify the encoding of strings and character arrays in netcdf.
There is also a need to specify whether char arrays in NetCDF3 contain strings or character arrays.
@BobSimons addressed these issues in an enhancement to CF conventions that would specify charset for NetCDF3 and _Encoding for NetCDF4, and the Unidata gang (@DennisHeimbigner, @WardF, @ethanrd and @cwardgar) agreed with the concept, but suggested this be handled in the NUG and we came up with this slightly different proposal that would still accomplish Bob's goals of making it easy for software to figure out what is stuffed in those  char or string arrays!
Proposal:

Use _CharType variable attribute with allowed values ['STRING', 'CHAR_ARRAY'] to specify if a char array variable should be interpreted as a string or as an array of individual characters.  If _CharType is missing, default is 'STRING'.
Use _Encoding variable attribute with allowed values ['ISO-8859-1', 'ISO-8859-15', 'UTF-8'] to specify the encoding.   If _Encoding is missing for _CharType='STRING', default is 'UTF-8'.  If _Encoding is missing for  _CharType='CHAR_ARRAY', default is 'ISO-8859-15'.

Should an _Encoding attribute on a 'char' typed variable be restricted to a 7- or 8-bit encoding?

As @DennisHeimbigner mentions here https://github.com/Unidata/netcdf4-python/issues/654#issuecomment-298735562, this proposal does deals only with char or String typed variables, not char or String typed attributes.

Why wouldn't _Encoding apply to attributes as well as variable data?

Because netcdf does not support attributes for attributes. We would
need to come up with some kind of convention for this: a second
attribute that could be interpreted as applying to the string/char
attribute. Alternate is to define a global encoding for all attributes.
=Dennis Heimbigner
Unidata
On 5/3/2017 8:01 AM, Jeff Whitaker wrote:

Why wouldn't |_Encoding| apply to attributes as well as variable data?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/402#issuecomment-298919846,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3P2yhdO2_-QxIAH57sQUlvJMbiB3I-ks5r2IjKgaJpZM4NOoaO.

@DennisHeimbigner, I guessing you can answer @ethanrd question:

Should an _Encoding attribute on a char typed variable be restricted to a 7- or 8-bit encoding?

Should an _Encoding attribute on a char typed variable be restricted to a 7- or 8-bit encoding?
If an _Encoding is specified, then that technically determines 7 vs 8 bit. E.g. Ascii is 7 bit, but
ISO-Latin-8859-1 is 8-bit. The tricky case is when something like utf-8 encoding is specified.
Technically, the single character subset of utf-8 is 7-bit ascii. But, it is clear that some users
treat an array of chars as a string, in which case any legal utf-8 char bit pattern should be legal.
IMO, we should always treat char as essentially equivalent to unsigned byte so that a char
can hold any 8-bit bit pattern so that e.g. _Encoding = "iso-latin-8859-1" is legal and does not
lose information.

I suggested always indicating the encoding/charset with the same attribute (_Encoding), whether string or character, thinking it simplified things. Now that restrictions on allowed encodings has come up, I'm seeing the wisdom of @BobSimons original proposal to the CF list with one attribute that gives a string encoding for use when interpreting strings and one that gives the character set for use when interpreting individual characters. (It avoids the need for different restrictions on the value of _Encoding depending on the situation.)
So, as an alternate to the above proposal, I'll restate Bob's proposal here with a change or two given the target is the NUG rather than CF:

Use the _CharSet variable attribute to indicate that a char array should be interpreted as individual 8-bit characters. The value of the attribute gives the 8-bit character set to use when interpreting the 8-bit characters. (E.g., 'ISO-8859-15'.)

Use the _Encoding variable attribute to indicate which character encoding should be used to interpret a string variable. Used with a char array, the attribute indicates that it should be interpreted as a string (or an array of strings).

Reviewing Bob's original proposal brought up a number of questions on how the netCDF-4 and HDF5 libraries handle string encoding (if they enforce the encoding or not, etc.). I'm still digging and will report back when I get somewhere.
Also, there was some question in the CF discussion on whether an explicit indicator was needed to differentiate between whether a char array should be interpreted as individual 8-bit characters or as a string(s). Since the current proposal is suggesting a change to the NUG, I'm not sure if this question will or should play out the same as in a CF discussion.

@lesserwhirls, do you have any thoughts here?   @ethanrd are you still looking at this, or can we propose the above changes to NUG?

I do not understand the need for the _CharSet attribute. The type of the variable (char vs String)
and the _Encoding attribute seem to me to encompass _CharSet. That is
_Encoding for char type == CharSet

@DennisHeimbigner, the problem is that while netcdf4 has char or string, netcdf3 has only char.  So we don't know whether the netcdf3 char holds a string or an array of characters.

@DennisHeimbigner, this is an alternative proposal.
In this proposal _CharSet and _Encoding apply to different situations, have different options, and are used differently (mandatory vs optional):
_CharSet would be for char variables when they are to be interpreted as individual chars.
The options are ISO-8859-1 and ISO-8859-15.
_CharSet is mandatory if the chars should be interpreted as individual chars.
_Encoding would be for String variables (e.g., in nc4) and char variables in nc3 which should be interpreted as Strings.
The options are ISO-8859-1, ISO-8859-15, and UTF-8.   [Different!]
_Encoding is optional. The default is UTF-8.   [Different!]
A further advantage is that only one attribute is needed per variable, not two.
Think of it from a software reader's point of view:

Is there a _CharSet attribute? Then these are chars and I now know the charset.
Is there an _Encoding attribute? Then these are strings and I now know the encoding.
Is there neither? Then these are UTF-8 strings.

I think the term "mandatory" is being misused here since a default is defined.
But the real issue in Bob's proposal has to do with whether a character typed
variable (or attribute?) is to be treated as if it was a surrogate for the lack of
a String type in netcdf-3 and do we want a special attribute to mark that case.
Personally undecided on that issue.

One other question. If we had an attribute to indicate that a char array
should be treated like a string, do we want to limit the use of that
attribute to netcdf-3 only. Since netcdf-4 has string type, that attribute
is technically not needed.

@BobSimons Given the backward compatibility issues, I'm not sure the NUG should specify how character arrays are interpreted when the proposed attributes are not used. At least not at the level of a MUST.

The proposed default behavior is to assume that a netcdf3 char array is a string.
With Bob's proposal, if a_CharSet attribute is found, we know it's not a string.

With the original proposal, an nc3 file might have:
  someMonths(a=5, b=10)
    _CharType="STRING"
    _Encoding="UTF-8"
  someStatus(c=4, d=2)
    _CharType="CHAR_ARRAY"
    _Encoding="ISO-8859-1"

With the alternative proposal, that nc3 file would have:
  someMonths(a=5, b=10)
    _Encoding="UTF-8"
  someStatus(c=4, d=2)
    _CharSet="ISO-8859-1"

because _Encoding now says two things (this var is a String var and the encoding is ...)
and _CharSet likewise says two things (this var has individual chars and the charset is ...).

@BobSimons I don't think the default for NC3 can be UTF-8 because there are existing NC3 files w/o _Encoding which are not UTF-8.  Existing NC3 files w/o _Encoding are ambiguous (broken) for strings due to bad spec.

I think what @BobSimons means is that the convention will be to assume string and UTF-8 for char arrays without any attributes because, as you say, it's ambiguous, and software will have to do something!

And I leave it to everyone else to say what the default should be. There
are advantages and disadvantages to every choice.
ISO-8859-1 probably makes sense from a safe, backward-looking sense.
UTF-8 would be nice in a forward-looking sense.
On Tue, May 9, 2017 at 12:15 PM, Rich Signell<EMAIL_ADDRESS>wrote:

I think what @BobSimons https://github.com/BobSimons means is that the
convention will be to assume string and UTF-8 for char arrays without any
attributes because, as you say, it's ambiguous, and software will have to
do something!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/402#issuecomment-300272683,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABarOJxsouo4DKsLxduKi4Jw0rrQI2Gbks5r4LtjgaJpZM4NOoaO
.

--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A      (New!)
Monterey, CA 93940               (New!)
Phone:<PHONE_NUMBER>            (New!)
Fax:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><

If utf-8 is an option, why are we restricting the rest of the list to iso-8859-1/15?

Under either proposal, for char variables that will be interpreted as
individual characters (which will be stored as individual bytes in .nc
files), UTF-8 isn't and can't be an option because most UTF-8 characters
are represented as more than one byte.
Under either proposal, for char variables that will be interpreted as
Strings, UTF-8 is a valid option.
That said, why just 2 other options?
It can't be open-ended because then all software which tries to read a .nc
file is responsible for being ready to read every possible encoding.
There's a question of what are the "correct" or at least valid names --
different systems seem to use slightly different names. Different computer
languages support different options. So there needs to be a defined list of
acceptable options. Right now, that list is short.
ISO-8859-1 is nice because it is the same as the first 256 characters of
Unicode. So it is the closest to what netcdf library has been doing when
writing just the low byte of a Unicode character. ISO-8859-1 has been
widely used.
ISO-8859-15 is nice because it is the modern version of ISO-8859-1.
ISO-8859-15 has been fairly widely used.
Support for options other than UTF-8 is a way of dealing with legacy files.
There are millions (billions?) of .nc files that aren't going to be
re-written, so it would be nice if there were a way to specify the encoding
if it is known. If it is known, it could be specified by adding an, e.g.,
_Encoding attribute with NCO or on-the-fly with NCML without having to
write a program to read the file and write the file out with the attribute
specifying the encoding.
I personally am open to allowing other options if the need arises, But I
don't know which other options are needed. If others are added, we need to
agree on the specific names.
On Tue, May 9, 2017 at 1:04 PM, Ryan May<EMAIL_ADDRESS>wrote:

If utf-8 is an option, why are we restricting the rest of the list to
iso-8859-1/15?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/402#issuecomment-300285127,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABarOPt83LfG-df6K_lr_lMzAHArBl46ks5r4MbCgaJpZM4NOoaO
.

--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A      (New!)
Monterey, CA 93940               (New!)
Phone:<PHONE_NUMBER>            (New!)
Fax:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><

Well the problem with ISO-8859-1 (aka latin-1) and ISO-8859-15 (aka latin-9) is that they're distinctly focused on western European languages. We should at a minimum look at something like koi8-r and cp1251 to encompass eastern european/cyrillic characters. You should also be able to declare ascii itself to indicate that you only intend to use the lowest 7-bits.

Every charset has a different focus.
I suggested ISO-8859-1 and -15 because I know they have been widely used.
If you know of files that use koi8-r and cp1251, then let's add them to the
list of acceptable charsets/encodings.
I don't like the idea of allowing an ASCII (7-bit) option because the data
is 8-bits. A reader has to be ready to deal with 8-bit data. (Or we could
say that ASCII is a valid option but if the file has a character using the
8th bit, the file is invalid. I suspect we would get a lot of invalid files
from non-ASCII apostrophes and hyphens that the file authors aren't even
aware of.)  I also don't see the need for an ASCII option because, if the
author really believes the characters are all ASCII, then ISO-8859-1 can be
specified (since the first 128 chars are the same).
On Tue, May 9, 2017 at 2:46 PM, Ryan May<EMAIL_ADDRESS>wrote:

Well the problem with ISO-8859-1 (aka latin-1) and ISO-8859-15 (aka
latin-9) is that they're distinctly focused on western European languages.
We should at a minimum look at something like koi8-r and cp1251 to
encompass eastern european/cyrillic characters. You should also be able to
declare ascii itself to indicate that you only intend to use the lowest
7-bits.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/402#issuecomment-300311352,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABarOM4wyqAA0LWh7tNd-oYMRudXDGwfks5r4N61gaJpZM4NOoaO
.

--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A      (New!)
Monterey, CA 93940               (New!)
Phone:<PHONE_NUMBER>            (New!)
Fax:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><

for multidimensional character arrays that are to be interpreted as strings, is there a standard way to interpret the dimensions?  Should the last dimension be interpreted as the length of the strings?  If so, is there a convention for naming that dimension?

"Yes" for your first two questions: CF 1.6 (and previous) section 2.2
http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#_data_types
says that is always the last dimension that holds the number of characters
"NetCDF does not support a character string type, so these must be
represented as character arrays. In this document, a one dimensional array
of character data is simply referred to as a "string". An n-dimensional
array of strings must be implemented as a character array of dimension
(n,max_string_length), with the last (most rapidly varying) dimension
declared large enough to contain the longest string in the array. All the
strings in a given array are therefore defined to be equal in length. For
example, an array of strings containing the names of the months would be
dimensioned (12,9) in order to accommodate "September", the month with the
longest name."
"No" for your third question:
As far as I know, there is no standard for how that dimension should be
named.
CF section 2.3 says
"This convention does not standardize any variable or dimension names. "
On Tue, May 16, 2017 at 10:02 AM, Jeff Whitaker<EMAIL_ADDRESS>wrote:

for multidimensional character arrays that are to be interpreted as
strings, is there a standard way to interpret the dimensions? Should the
last dimension be interpreted as the length of the strings? If so, is there
a convention for naming that dimension?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/402#issuecomment-301848278,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABarOBxdV5--h9sFvQr0O2SK2gAUvWuFks5r6da6gaJpZM4NOoaO
.

--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A      (New!)
Monterey, CA 93940               (New!)
Phone:<PHONE_NUMBER>            (New!)
Fax:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><

@dopplershift , are you satisfied with the explanation @BobSimons provided?
I'd like to push this one to closure and not just leave it hanging...

I added automatic detection of the _Encoding attribute in netcdf4-python (https://github.com/Unidata/netcdf4-python/pull/665).  For string variables, if _Encoding is set it is used to encode the strings into bytes when writing to the file, and to decode the bytes into strings when reading from the file.  If _Encoding is not specified, utf-8 is used (which was the previous behavior).  When reading data from character variables _Encoding is used to convert the character array to an array of fixed length strings, assuming the last dimension is the length of the strings.  When writing data to character variables, _Encoding is used to encode the string arrays into bytes, creating an array of individual characters with one more dimension.    For character variables, if _Encoding is not set, an array of characters is returned.

This seems to be significantly different from the original proposal or the
alternate proposal.
"When writing data to character variables, _Encoding is used to encode the
string arrays into bytes, creating an array of individual characters with
one more dimension. For character variables, if _Encoding is not set, an
array of characters is returned."
I'm confused. Since netcdf4 has separate char and String data types, why
are you adding a dimension when writing chars to a char variable?
Is this your way of allowing chars in a char variable to be encoded with
UTF-8 (and thus perhaps take up multiple bytes / char)? That would expand
the usage of chars significantly.
And when reading a char variable from an nc4 file, won't an array of chars
always be returned? (Or, again, is this your way of expanding the usage of
chars to include UTF-8 encoding?) And can't _Encoding be used to indicate
the charset of the returned characters (e.g., ISO-8859-1)?

This usage seems oriented to just reading and writing netcdf-4 files. It
doesn't solve the problem of how to interpret a char variable in a netcdf-3
file (as strings? as separate chars?). One of the complaints in the CF
discussion was: someone writing code to read a file shouldn't have to know
whether they are reading an nc3 file or an nc4 file in order to know how to
interpret the data. It would be nice to have a system that works with nc3
and nc4 files.
On Wed, May 17, 2017 at 8:49 AM, Jeff Whitaker<EMAIL_ADDRESS>wrote:

I added automatic detection of the _Encoding attribute in netcdf4-python (
Unidata/netcdf4-python#665
https://github.com/Unidata/netcdf4-python/pull/665). For string
variables, if _Encoding is set it is used to encode the strings into
bytes when writing to the file, and to decode the bytes into strings when
reading from the file. If _Encoding is not specified, utf-8 is used
(which was the previous behavior). When reading data from character
variables _Encoding is used to convert the character array to an array of
fixed length strings, assuming the last dimension is the length of the
strings. When writing data to character variables, _Encoding is used to
encode the string arrays into bytes, creating an array of individual
characters with one more dimension. For character variables, if _Encoding
is not set, an array of characters is returned.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/402#issuecomment-302134033,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABarOGWkde0uKwdnXJdxGsaZ0Sez40vlks5r6xcmgaJpZM4NOoaO
.

--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A      (New!)
Monterey, CA 93940               (New!)
Phone:<PHONE_NUMBER>            (New!)
Fax:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><

@rsignell-usgs @BobSimons
Well I was thinking ascii as a nice option for "I don't care about the 8th bit", but I can see the rationale behind forcing a choice for the 8th bit--I'm just guessing most users are not going to care or even understand anything beyond ascii and are just going to pick the option that let's them write without errors. Either way, so long as we make our restricted list as inclusive as possible--was just trying to make us less US/Western Europe-centric.

What I wish was the case was this:

char type is an alias for unsigned byte - this guarantees that 8 bits of data must always
be preserved
The _Encoding is a suggestion about how programs (ncdump, etc) should interpret
the characters in the event that they have to print them (or read them from text).
The same should also hold for strings in that strings are equivalent to variable length
sequences of unsigned bytes.
The reason I wish this were the case is that the _Encoding is AFIAK irrelevant except
when reading or writing text.

Also, with respect to using the rightmost dim to encode (fixed-length) strings: this is purely
an external convention and is certainly not part of the netcdf spec. It raises a question?
Who actually makes use of this convention? I know only one place: the conversion of DAP2
string typed vars into netcdf-3 character typed variables. Is it used anywhere else?

--- External?
I've always been confused about the relationship of netcdf and CF so I
don't know if you consider CF external, but using the rightmost dim to
encode strings in char variables is part of the CF specification (section
2.2).
--- Where is this relevant?
Doesn't netcdf-java always use the rightmost dim when you use
NetcdfFileWriter.addStringVariable() and
NetcdfFileWriter.writeStringData() when writing an nc3 file?
And doesn't it use the rightmost dim when you use
NetcdfFile.read(), readData(), and readSection()?
(When reading nc3 files, do those/how do those distinguish
char variables that should be read as individual chars from
char variables that should be read as Strings?)
Doesn't netcdf-c do the same?
Some other software (e.g., some of mine) also uses the rightmost dimension
system explicitly in places that were written before (or before my
awareness of) writeStringData().
On Wed, May 17, 2017 at 11:26 AM, DennisHeimbigner<EMAIL_ADDRESS>
wrote:

Also, with respect to using the rightmost dim to encode (fixed-length)
strings: this is purely
an external convention and is certainly not part of the netcdf spec. It
raises a question?
Who actually makes use of this convention? I know only one place: the
conversion of DAP2
string typed vars into netcdf-3 character typed variables. Is it used
anywhere else?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/402#issuecomment-302185109,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABarOHFtmcd4UftG-NkFEHtbHcYanZGCks5r6zvKgaJpZM4NOoaO
.

--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A      (New!)
Monterey, CA 93940               (New!)
Phone:<PHONE_NUMBER>            (New!)
Fax:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><

WRT to jswhit proposal above.

As part of the python strings -> netcdf-4 string translation rules, the rule for strings
seems reasonable.
The character part of that proposal is relevant only to the issue of python strings <->
netcdf-3 char array translation rules..  It is consistent with DAP2 and CF translation rules.
For translating netcdf4-char arrays to python, #2 also seems appropriate.
I have a question for the python people. Is there any situation in which a python
string would be translated into a netcdf- char array? I infer that this case is prohibited
using the jswhit rules for python <-> netcdf-4

At this point, there seems to be agreement about strings: _Encoding specifies
the character set and if missing, utf-8 should be assumed.
So we can focus on the character type as an eight bit value. I am not concerned here
with translation rules (e.g. python strings <-> netcdf character arrays).
1 _Encoding applies to individual 8-bit characters but the only legal _Encodings are
those that are inherently 8-bit or less: iso-8859, ascii being prevalent.
Converting a vector of such characters to a string (via some rule) should produce a
legal string of that encoding.
2. _Encoding applies to individual 8-bit characters and specify only the expected bit patterns.
This allows utf-8 _Encoding since the set of legal utf8 bit patterns are known).
Note that this does not mean that converting (via some rule) a vector of chars to a String
would necessarily produce a legitimate utf8 encoded string. the default encoding is
to allow any 8-bit pattern.
Personally I prefer #2 since it at least allows (again via some reasonable rule) to
convert a utf8 string to a vector of 8-bit characters.
Choosing #1 would preclude that possibility at all and an error would have to be thrown.

@BobSimons, regarding your comment that the python implemention deviates from your original proposal...
In the situation when a user tries to write an array of python fixed length strings to a character variable with _Encoding set, the python interface will convert that array of fixed length strings to an array of single characters (bytes) with one more dimension (equal to the length of the fixed length strings, and the rightmost dimension of the character variable) then write that array of characters to the file.
I thought this was in the spirit of the CF convention - and this is what a user would have to do manually to write the strings to the character variable.  One could certainly argue that this is a too much 'magic' though.
The same happens in reverse when data is read from a char variable with _Encoding set.

@DennisHeimbigner, regarding your question "Is there any situation in which a python
string would be translated into a netcdf- char array?"....
The answer is yes, if you are writing a single string into a character array like this
>>> v
<type 'netCDF4._netCDF4.Variable'>
|S1 strings(n1, n2, nchar)
    _Encoding: ascii
unlimited dimensions: n1
current shape = (0, 10, 12)
filling on, default _FillValue of  used
>>> v[0,0,:] = 'foobar'

The string foobar will get converted into an array of 12 characters (with trailing blanks appended) and then written to the file resulting in
netcdf tst_stringarr {
dimensions:
n1 = UNLIMITED ; // (1 currently)
n2 = 10 ;
nchar = 12 ;
variables:
char strings(n1, n2, nchar) ;
strings:_Encoding = "ascii" ;
data:
strings =
"foobar",

Your approach is internally consistent -- if someone writes files with your
system and reads them with your system, all is well. But there are other nc
files created by other software, which I think don't mesh with your
approach.
I don't know if your system is for netcdf-4 only, but if netcdf-3 files are
included, the problem is: there are nc3 files with char variables where the
chars are meant to be read as individual chars without collapsing the
rightmost dimension. The Argo program has 100's of 1000's (millions?) of
these files. They have variables like
char POSITION_QC(N_PROF=254);
where there is one QC character per profile. (Yes, there's a more CF-way to
do this now, but they started doing this many years ago.)
I think it is a reasonable reading of the CF convention (section 2.2) to
say that these are legit char variables, not to be interpreted as Strings
(by collapsing the rightmost dimension).
A goal of this proposal is to make it simple for a software reader to read
a file (including an Argo file) and know quickly and easily if a given char
variable in an nc3 file is meant to be interpreted
as individual chars (not collapsing the rightmost dimension)
or as Strings (by collapsing the rightmost dimension).
With nc4 files that is trivial because there are explicit char and String
data types. The problem is with disambiguating char variables in nc3 files.
Stated another way, it is a goal that netcdf-java library's
NetcdfFile.read() should be able to know quickly and easily whether it
should return
an ArrayChar (by not collapsing the rightmost dimension)
or an ArrayString (by collapsing the rightmost dimension)
(and also be able to properly deal with the charset/encoding of the stored
characters).
On Wed, May 17, 2017 at 3:40 PM, Jeff Whitaker<EMAIL_ADDRESS>wrote:

@BobSimons https://github.com/bobsimons, regarding your comment that
the python implemention deviates from your original proposal...
In the situation when a user tries to write an array of python fixed
length strings to a character variable with _Encoding set, the python
interface will convert that array of fixed length strings to an array of
single characters (bytes) with one more dimension (equal to the length of
the fixed length strings, and the rightmost dimension of the character
variable) then write that array of characters to the file.
I thought this was in the spirit of the CF convention - and this is what a
user would have to do manually to write the strings to the character
variable. One could certainly argue that this is a too much 'magic' though.
The same happens in reverse when data is read from a char variable with
_Encoding set.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/402#issuecomment-302251264,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABarOAqdua1ezYBcjktrLDRQH7DevGtTks5r63dBgaJpZM4NOoaO
.

--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A      (New!)
Monterey, CA 93940               (New!)
Phone:<PHONE_NUMBER>            (New!)
Fax:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><

for nc3 or nc4 files, if _Encoding is not set the individual chars will be returned by the python interface without collapsing the rightmost dimension.  I thought from your proposal that if _Encoding was set, then the client should interpret the char array as strings.  Did I misread that?

Ah. Thank you. I misunderstood.
On Wed, May 17, 2017 at 4:46 PM, Jeff Whitaker<EMAIL_ADDRESS>wrote:

for nc3 or nc4 files, if _Encoding is not set the individual chars will
be returned by the python interface without collapsing the rightmost
dimension. I thought from your proposal that if _Encoding was set, then
the client should interpret the char array as strings. Did I misread that?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/402#issuecomment-302261668,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABarOD3-7mfaiaH_o3mt7JsVy0ZDdhNEks5r64bjgaJpZM4NOoaO
.

--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A      (New!)
Monterey, CA 93940               (New!)
Phone:<PHONE_NUMBER>            (New!)
Fax:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><

@BobSimons, would @jswhit's approach with NetCDF-Python work for you in ERDDAP to disambiguate string and char array handling in NetCDF3 and NetCDF4?
Seems like it does, right?

Sorry. I'm on vacation for the next 2 weeks and not available to evaluate
this.
I was confused by his original email. So I don't think I understand his
proposal. I stand by my proposal.
On Sun, Jun 4, 2017 at 12:25 PM, Rich Signell<EMAIL_ADDRESS>wrote:

@BobSimons https://github.com/bobsimons, would @jswhit
https://github.com/jswhit's approach with NetCDF-Python work for you in
ERDDAP to disambiguate string and char array handling in NetCDF3 and
NetCDF4?
Seems like it does, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/402#issuecomment-306050428,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABarOIukT81RvoM10PX0NCVIdr3y1o_Oks5sAtprgaJpZM4NOoaO
.

--
Sincerely,
Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A      (New!)
Monterey, CA 93940               (New!)
Phone:<PHONE_NUMBER>            (New!)
Fax:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><

Okay, I'll discuss with you when you get back from vacation.


fix: unpack errors on ReferenceBlockAttestation

Related Github tickets

Closes https://github.com/VolumeFi/paloma/issues/1740

Background
ReferenceBlockAttestation messages currently do not need an assignee, however they are still queried for messages to relay, leading to unpack error messages in palomad logs.
This is a quickfix to comply with the TurnstoneMsg interface so we don't get errors. A more thorough fix could be to keep a list of queues with messages that can be relayed and only query those.
Testing completed

[x] test coverage exists or has been added/updated
[x] tested in a private testnet

Breaking changes

[x] I have checked my code for breaking changes
[x] If there are breaking changes, there is a supporting migration.

I think ValidatorBalancesAttestation works by having Assignee defined in the proto although it doesn't need it as well. This makes it comply with the TurnstoneMsg interface.
I didn't want to add the field to ReferenceBlockAttestation as it's not needed. We can remove it from ValidatorBalancesAttestation and implement an empty function as well, but didn't want to change it unnecessarily. Do you think we should remove it?

I think ValidatorBalancesAttestation works by having Assignee defined in the proto although it doesn't need it as well. This makes it comply with the TurnstoneMsg interface.
I didn't want to add the field to ReferenceBlockAttestation as it's not needed. We can remove it from ValidatorBalancesAttestation and implement an empty function as well, but didn't want to change it unnecessarily. Do you think we should remove it?
edit
We set PublicAccessData in ReferenceBlockAttestation messages, but pigeon still queries all queues for relay here. I think we could also address this in pigeon by splitting SupportedQueues but that also doesn't feel like addressing the root of the problem.

Pigeon will still query it, but Paloma won't hand the message out for delivery, since the PublicAccessData is already set. See GetMessagesForRelaying in the consensus keeper. Essentially, setting the PublicAccessData field to anything but nil should prevent this message from ever being handed over to the assignee.  It will also trigger the "attestation" stage of the message lifecycle, since Paloma will start handing it over to all Pigeons for attestation once either PublicAccessData or ErrorData are filled.
To be honest, I think it's more in line with the current architecture to stick with this approach. Can you see any reasons why you'd want to move away from it?
Splitting queues is likely something we want to explore in the future, but out of scope for this one.

I think ValidatorBalancesAttestation works by having Assignee defined in the proto although it doesn't need it as well. This makes it comply with the TurnstoneMsg interface.
I didn't want to add the field to ReferenceBlockAttestation as it's not needed. We can remove it from ValidatorBalancesAttestation and implement an empty function as well, but didn't want to change it unnecessarily. Do you think we should remove it?
edit
We set PublicAccessData in ReferenceBlockAttestation messages, but pigeon still queries all queues for relay here. I think we could also address this in pigeon by splitting SupportedQueues but that also doesn't feel like addressing the root of the problem.

Pigeon will still query it, but Paloma won't hand the message out for delivery, since the PublicAccessData is already set. See GetMessagesForRelaying in the consensus keeper. Essentially, setting the PublicAccessData field to anything but nil should prevent this message from ever being handed over to the assignee. It will also trigger the "attestation" stage of the message lifecycle, since Paloma will start handing it over to all Pigeons for attestation once either PublicAccessData or ErrorData are filled.
To be honest, I think it's more in line with the current architecture to stick with this approach. Can you see any reasons why you'd want to move away from it?
Splitting queues is likely something we want to explore in the future, but out of scope for this one.

We have that, and it's working. I agree we should keep it.
The current issue is that in GetMessagesForRelaying we will try to unpack these messages as TurnstoneMsg here, but this will fail as we don't have the GetAssignee() method, as there's no Assignee field. Everything still works fine, but we're getting a bunch of errors in the logs, which is what I'm trying to avoid here.
I realize now a simpler solution could be to push this check for PublicAccessData to happen before checking the assignee. This would filter these messages before we try to unpack them as TurnstoneMsg and get rid of the errors as well. Do you see an issue with doing this?

I think ValidatorBalancesAttestation works by having Assignee defined in the proto although it doesn't need it as well. This makes it comply with the TurnstoneMsg interface.
I didn't want to add the field to ReferenceBlockAttestation as it's not needed. We can remove it from ValidatorBalancesAttestation and implement an empty function as well, but didn't want to change it unnecessarily. Do you think we should remove it?
edit
We set PublicAccessData in ReferenceBlockAttestation messages, but pigeon still queries all queues for relay here. I think we could also address this in pigeon by splitting SupportedQueues but that also doesn't feel like addressing the root of the problem.

Pigeon will still query it, but Paloma won't hand the message out for delivery, since the PublicAccessData is already set. See GetMessagesForRelaying in the consensus keeper. Essentially, setting the PublicAccessData field to anything but nil should prevent this message from ever being handed over to the assignee. It will also trigger the "attestation" stage of the message lifecycle, since Paloma will start handing it over to all Pigeons for attestation once either PublicAccessData or ErrorData are filled.
To be honest, I think it's more in line with the current architecture to stick with this approach. Can you see any reasons why you'd want to move away from it?
Splitting queues is likely something we want to explore in the future, but out of scope for this one.

We have that, and it's working. I agree we should keep it.
The current issue is that in GetMessagesForRelaying we will try to unpack these messages as TurnstoneMsg here, but this will fail as we don't have the GetAssignee() method, as there's no Assignee field. Everything still works fine, but we're getting a bunch of errors in the logs, which is what I'm trying to avoid here.
I realize now a simpler solution could be to push this check for PublicAccessData to happen before checking the assignee. This would filter these messages before we try to unpack them as TurnstoneMsg and get rid of the errors as well. Do you see an issue with doing this?

I think it sounds like a great idea :)


unsafe under high concurrency

after wrtc.close(), need update publishers immediately

Description

[] It needs and includes Unit Tests
Changes in Client or Server public APIs

[] It includes documentation for these changes in /doc.

if removeExternalOutputs error, you wish delete publishers[streamId] ? I'm not sure, it's up to you. But after wrtc.close(), wrtc is 0x00 in c++, any call wrtc.xxx will crash

You're right, thanks a lot!


List Box are not beeing filled

Hi,
I have a PDF form example that I would like to fill and everything is working fine besides the list boxes are not changing their values.
For example I have a list box for Gender and I can't change it's value, even the default value from the template is not displayed.
Thank you!

I thought I had a similar issue, but in the end the problem was that Preview in Mac was not showing the values, but they were there. Opening in windows Edge the data I changed in lists showed ok.
Take a look to check whether this might be your case too.


Bump version 1.2.0

Change version from 1.0.2 to 1.2.0.
Signed-off-by: 662962756<EMAIL_ADDRESS>

 change 1.0.2 tags to 1.2.0 in all repos


I want to get all the transaction logs on the chain. Could you please give me some help? Thank you!

I want to get EVM transaction log, but I haven't found a way. Could you please give me some help? It's better to provide specific function calls, thank you!

you can use websocket to subcribe event from contract transition


Ignores datapacks

I wanted to add some bartering items. Sadly, none of these items were shown in the bartering category. I tried to obtain these items and it worked. Just not shown in JEPB.

I think this happens because you need to take the loot table entries from client world loot manager and the datapack only changes the loot table on server which isn't synced to client.
I think this can be fixed by sending a packet with the changed loot table to the client.

I'll take a look as soon as I can, thanks for reporting!

Hello,
how is it going with this feature ? :)


Small question regarding gradient scaling

Where in the code is the gradient rescaled with the batchsize?

in optimizers

Any implementation difference comparing against Caffe?
I am finetuning the Caltech101 dataset with the pre-trained GoogleNet model (converted from Caffe). With exactly the same hyper-parameters (learning rate, wd, momentum, etc.), it seems that MXNet converges much slower that Caffe. Is there any hyper-parameters that I should scale accordingly?
Here is the log file:

For MXNet:

epoch
train-accuracy
valid-accuracy
time

1
0.070569
0.497333
67.3

2
0.503607
0.779000
67.2

3
0.719350
0.836667
68.1

4
0.791148
0.850000
66.2

5
0.834754
0.847731
67.8

6
0.872520
0.872667
68.4

7
0.882951
0.863333
74.7

8
0.901463
0.871667
78.2

9
0.916721
0.880000
74.0

10
0.923934
0.876975
76.1

For Caffe (122 iters = 1 epoch)

iter
test-accuracy

0
0.0040

122
0.8514

244
0.8825

366
0.8861

488
0.9072

610
0.9065

732
0.9045

854
0.9132


Fixed bug with installation

Error: 404 Not Found: cordova-plugin-file

Your version of cordova-cli is outdated please run a npm update -g cordova
You might need to run "sudo npm update -g cordova" to allow npm update access to restricted files.


Mem Optimizations

This is another one which will cause a the streaming code to fail to compile. Currently, we would need another pull request on the other end. Though I'm not sure if the feature I added (variable queue size) is good to have or not. I'll get an answer on that soon.


[BUG] Slider volume has no effect on IOS

Describe the bug
When i change the slide position, the volume doesn't change
Technical Details:

Device: [e.g. iPhone8 ]
OS: [13.3]

Thx a lot for this great job !

Reopening this. setVolume has no effect on iOS.


Fix white background on right side panel

The contextual bar (right side panel) background is white when it should be the same color as the left side panel:

Channel specific panels:

I recently took the liberty to tweak the (previous) version of this template - it fixes the sidebar, but also does some other stuff (e.g. changes the look of the text-input field).
Unfortunately I am not exactly a less pro, so all I did was add some custom stuff to the .css file.
It looks like this

/*custom stuff*/
#icon-menu {
    fill: #c2c3c5;
}
#icon-team {
    fill: #c2c3c5;
}
#icon-user-plus {
    fill: #c2c3c5;
}
#icon-send path {
    fill: #c2c3c5;
}
#icon-add-reaction {
    color: #c2c3c5;
}
#icon-lock, #icon-hashtag {
    color: #c2c3c5;
}
#icon-at, #icon-cross, .rc-tags__tag-text {
    color: #c2c3c5;
}
.reactions > li {
	background-color: #888889;
}
.rc-header__name, .rc-message-box__typing__user, .create-channel__title {
  color: #fff;
}
.rc-input__wrapper, .rc-tags  {
  border: none;
}
.rc-message-box__container{
  border: none;
  border-bottom: 1px solid #7289da;
}
.rc-button--primary {
 background-color: #7289da;
}
.rc-button--outline {
  border-color: #c2c3c5;
  color: #c2c3c5;
}
.rc-input__title, .rc-form-legend, .rc-form-label, .rc-switch__text, .rc-member-list__counter {
  color: #c2c3c5;
}
.rc-tags__tag {
  background-color: #424449;
}
.contextual-bar__content {
 background-color: #2f343d;
}
.rc-member-list__user:hover {
 background-color: #444444;
}

Thanks for sharing. It doesn't seem to be 100% working by me, as the channel header is still white.

Thanks for the report! Looks like the Windows client version is a bit different from the web version. I'll download and test it out, hopefully sometime this week but since I'm moving this week it might not be until next week.

That's weird because I have the same behavior with the web version:

Are you using Rocket.Chat 0.61.0?

How strange!! I used 0.61.0 when doing the refactor. After I saw the issue I upgraded to 0.61.1 but still couldn't duplicate it.
I feel like there must be a setting somewhere because I don't have those icons in the header, instead I have a sidebar on the right.

@Otiel have you tried resetting the Colors under Administration > Layout > Colors and Administration > Layout > Old Colors yet?
Also, you could check if you have any less-errors in your Logs (Administration > View Logs). At some point in the past my custom CSS wasn't applied as well and resetting the colors after finding the less-error fixed it.

I feel like there must be a setting somewhere because I don't have those icons in the header, instead I have a sidebar on the right.

I agree with you, but I can't find a setting related to that sidebar... The only setting I could find is: My Account → Preferences → Hide Right Sidebar with Click, but it's set to False by default and changing it to True has no effect.

@Otiel have you tried resetting the Colors under Administration > Layout > Colors and Administration > Layout > Old Colors yet?

Just tried this, no luck.

Also, you could check if you have any less-errors in your Logs (Administration > View Logs). At some point in the past my custom CSS wasn't applied as well and resetting the colors after finding the less-error fixed it.

I've got zero error. 😞


build: Resolve CI dependency issues

Update eslint and plugins to avoid dependency resolution failures stemming from the use of the latest Node 16 version.  Also fix the resulting linting errors.
At the same time, use ubuntu-latest and use npm ci for CI settings.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Merge branch 'tensorflow' into tensorflow-merge

Bring the new changes in the tensorflow branch.

I had to resolve merge conflicts in:
include/swift/AST/Attr.h
lib/AST/Type.cpp
lib/Parse/ASTGen.cpp
lib/Parse/ParseDecl.cpp
lib/SILOptimizer/Mandatory/Differentiation.cpp
lib/Sema/TypeCheckDecl.cpp
Also, I made the derivativeGenericSignature field of AutoDiffConfig a GenericSignatureImpl*, not sure if that's the right fix. In any case, tests pass.

@swift-ci please clean test tensorflow

I don't believe CI is strictly necessary on merge PRs other than the final apple/tensorflow-merge -> apple/tensorflow PR, so let's perhaps merge this now and create + test the final PR.

Oh I thought it's to the tensorflow branch.


Allow invoice expiry of 3 days or less

Currently in the android app, the invoice expiry can be changed between 1, 2, or 3 weeks only.
However, some CEX (like kucoin) and other custodial wallets like WOS, don't allow invoices with an expiry of more than 3 days, which is making transactions to fail.
I thought I once saw a commit that allows changing the expiry between 1 second and 999999 seconds, but I'm not able to set it to less than a week in the app right now :strange:
Possibly related issue #335

Strangely sending from WOS is working now, last time it failed after sending from Kucoin had failed made me assume it was the same reason.
However, sending from Kucoin is still not working, and unfortunately they don't forward any error message to their users.
After speaking with customer support, this is what they said

Upon investigation, we have noticed that the expiry time you have configured is a week time. However, KuCoin only currently support the expiry time for up to 72 hours. Please configure the expiry time to 72 hours so that you are able to do a successful withdrawal.

In the v2 app, the app only let you choose between fixed values to make things simpler.

Unfortunately, this decision does not make it simpler for me 😞

The fix will be available in the next Android version.
For iOS, we'll need a separate commit so I reopen the ticket.


How many items can I retrieve?

Is there a limit to how many items I can retrieve from Firebase?

Nope


TaskPool type shadowing in bevy_tasks 0.12 with features

Bevy version
0.12
[Optional] Relevant system information
cargo 1.73.0 (9c4383fb5 2023-08-26) Win 10 64bit
What you did
I was upgrading my crate bevy_background_compute to 0.12. It depends on the bevy components (app, ecs, tasks) individually rather than the entirety of bevy. So step one is changing version of all dependencies to 0.12
What went wrong
My usage of bevy_tasks::TaskPool::spawn was returning a wrong type, FakeTask instead of a Task<()>.
I've looked at the changes in bevy_tasks and FakeTask was a new type introduced for and used exclusively by the new single threaded TaskPools, except I did not wish to use single-threaded TaskPools. The regular and single threaded task pools are shadowing each other in the crate exports, depending on the feature flags.
https://github.com/bevyengine/bevy/blob/675aac97e5d114914966192cad73295e951424e9/crates/bevy_tasks/src/lib.rs#L13-L14
https://github.com/bevyengine/bevy/blob/675aac97e5d114914966192cad73295e951424e9/crates/bevy_tasks/src/lib.rs#L18-L19
Since their APIs are not equivalent I do not believe this type aliasing sleight of hand is appropriate (and even if they were, my code would silently become single threaded). It is quite unorthodox to see an error about a type that's not present in the documentation (FakeTask), and figure out the type you've imported is actually a different type with the same name. Cargo book is of the same opinion
IMO ideally both TaskPool types should have their APIs unified, exported regardless of flags and have the flags control which task pool is used for the internal instead.
Additional information
The feature "multi-threaded" for bevy_tasks crate is enabled by default in the bevy crate, but not in the bevy_tasks crate itself. I think bevy components should have the same default features when depended on directly as when they're depended on indirectly through the "main" bevy crate.

For the skimmer, the key paragraphs are:

Since their APIs are not equivalent I do not believe this type aliasing sleight of hand is appropriate (and even if they were, my code would silently become single threaded). It is quite unorthodox to see an error about a type that's not present in the documentation (FakeTask), and figure out the type you've imported is actually a different type with the same name. Cargo book is of the same opinion
IMO ideally both TaskPool types should have their APIs unified, exported regardless of flags and have the flags control which task pool is used for the internal instead.

I do agree.

I have run into this as well when upgrading to 0.12 and I depend on Bevy directly.
For others running into this, the workaround for me was to explicitly add the "multi-threaded" feature in my Cargo.toml (I am not targeting wasm).


Maybe add screen keyboard for touch devices

Today I tried to connect to the desktop with my tablet and was suddenly stuck - there is no keyboard with VNC. I researched a little and you can easily add a screen keyboard via sudo apt-get install matchbox. It would be nice to include it in the image, preferences could be adapted to make it even easier (larger size, always-on-top).
For the impatient: you can add it to your running docker container via
sudo docker exec -it <container-id> bash
sudo apt-get update
sudo apt-get install matchbox

I cannot get the touchscreen keyboard to work on android devices. Any suggestions?

I see that the latest noVNC has support for touch screen keyboards (have not tested it though). May be upgrading to the latest noVNC can help. @fcwu - Your inputs please.

Related Issue 36: upgrade noVNC

@bluepuma77 I had upgrade noVNC to the latest version. Does it help you?

apt install matchbox-keyboard


vcpkg.cmake does not import boost's DLLs related to a shared library

Hello,
i use vcpkg version : Vcpkg package management program version 0.0.104-2018-02-07-d503a55412b3fa1b2b96ae0719286ee593f3d732
i use this script for build my project :
function build($type)
{
    mkdir build-$type
    cd build-$type
    $cmd = "-DCMAKE_BUILD_TYPE=$type"
    Write-Host $cmd
    $localpath = Join-Path $env:VCPKG_ROOT '/scripts/buildsystems/vcpkg.cmake'
    $localpath = $localpath -replace "\\", "/"
    cmake -DCMAKE_TOOLCHAIN_FILE="$localpath" $cmd -DZIA_BUILD_TESTS=ON -G "Visual Studio 15 2017 Win64" ..
    if ($LASTEXITCODE -ne 0) {
        Write-Host "cmake generation failed"
        exit 127
    }
    cmake --build . --config $type -- /verbosity:minimal /maxcpucount:3
    if ($LASTEXITCODE -ne 0) {
        Write-Host "build fail."
        exit 127
    }
}

and this cmake to build a shared library:
add_library(php_cgi SHARED
        Php_cgi.cpp
        Php_cgi.hpp)

find_package(Boost 1.66 COMPONENTS system thread filesystem REQUIRED)

set_target_properties(php_cgi
        PROPERTIES
        ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_SOURCE_DIR}/modules"
        LIBRARY_OUTPUT_DIRECTORY "${CMAKE_SOURCE_DIR}/modules"
        RUNTIME_OUTPUT_DIRECTORY "${CMAKE_SOURCE_DIR}/modules"
        LIBRARY_OUTPUT_DIRECTORY_DEBUG "${CMAKE_SOURCE_DIR}/modules"
        LIBRARY_OUTPUT_DIRECTORY_RELEASE "${CMAKE_SOURCE_DIR}/modules"
        RUNTIME_OUTPUT_DIRECTORY_DEBUG "${CMAKE_SOURCE_DIR}/modules"
        RUNTIME_OUTPUT_DIRECTORY_RELEASE "${CMAKE_SOURCE_DIR}/modules"
        )

target_link_libraries(php_cgi Core::Log Core::Lib Boost::thread Boost::filesystem Boost::system)
target_include_directories(php_cgi PRIVATE ${CMAKE_SOURCE_DIR}/zia/utils)

and there is the output directory without any boost dll:

Please tell me if i'm doing something wrong.

This issue should be fixed in latest vcpkg that with Boost 1.69 installed, please try again and open a new issue if this is still a problem for you!


fix pr summary

Fix pull request summary generation to avoid 80-column text truncation issues with git-diff --stat, where directory-based summaries were showing up with ... in (or as) the directory name.

+1 with style nit


Surface the correct "how do I apply" information in ListingView

Bloom's existing data model supports a couple different ways to answer the question "how do I apply to this listing?":

The Listing model has an applicationMethods field, which can be one of four types:

Internal (which means filling out the application through the Bloom portal)
FileDownload (applicant clicks a button to download an application form, e.g. this application PDF that is linked from one of the listings that's seeded in the test DB)
ExternalLink (presumably a link to a property management website, where they have their own application process)
PaperPickup (go to a physical place and pick up a paper application)

The Listing model also has a bunch of application-related fields:

applicationOrganization
applicationAddress
applicationPickUpAddress
applicationPickUpAddressOfficeHours
applicationPickUpAddressType
applicationDropOffAddress
applicationDropOffAddressOfficeHours
applicationDropOffAddressType
applicationMailingAddress
applicationDueDate and applicationDueTime
applicationOpenDate
applicationFee

On the other hand, the relevant fields in the ArcGIS DB:

Management_Company
Manager_Contact (the name of the property manager)
Property_Phone
Management_Website
Manager_Phone
Project_Address (not sure if this is where applications might be picked up / dropped off)

A few questions to answer here:

How should we map the existing ArcGIS data to fields in the Bloom model? (i.e. maybe we can assume Project_Address should be filled in for applicationPickUpAddress and applicationDropOffAddress?)
What additional fields should we add to the Bloom data model (e.g. Manager_Contact)
What additional data do we want to try to collect from property managers?

Done criteria: answers to those three questions above.

This is still a "product-level" bug - we need to pin down requirements before we can make any changes. I believe a lot of this was discussed earlier in the fellowship, but I'm not sure whether we came to conclusions or whether those conclusions are outdated. I'll raise this in the next "Property Management Weekly" meeting.

Adding @kar-r-green and @tomgebauer to this conversation.
We could also change the language of the detail listing view entirely to a more "contact the property manager" orientation instead of "here's how you apply".

Apologies for the delay on my comments here.
Early user feedback responded well to 'How to Apply' language as the header. However, due to our deprioritization of a Common App, let's leave 'applications' out of this entirely.
Propose to remove: applicationPickUpAddress and applicationDropOffAddress.
Proposed change to surface correct info:
'Contact Property to Apply'
Property address / website
Property Manager Contact details (phone # and email address)
@tomgebauer anything else to add here? Agree/disagree? Could you please experiment with how this might impact our mocks / design?

Thanks Kar, I created #328 and #329 to track improvements along the lines of what you describe.

thanks, Andy! open to feedback / additional questions or clarifications on this topic.


Auto-updating the field's value breaks when not using useForm's defaultValue

Describe the bug and the expected behavior
Before https://github.com/edmundhung/conform/pull/729 went in I could have something like this:
const schema = z.object({ displayName: z.string() });

const [form, fields] = useForm({
  onValidate({ formData }) {
    return parseWithZod(formData, { schema });
  },
});

const defaultValueForInput = "defaultValueForInput";

<Texfield
  name={fields.displayName.name}
  defaultValue={defaultValueForInput}
/>

The input was properly initialised with the provided default value and that'd be it. With the https://github.com/edmundhung/conform/pull/729, either we provide a defaultValue to the useForm hook or the input's value will be overwritten to an empty text input / unchecked radio or checkbox.
I think such a change could either be marked as a major upgrade since the documentation / previous versions did not force users to provide the defaultValue to the useForm hook when wanting to pass a default value to their inputs - meaning that inputs that are initialised "out of the useForm realm" will be overwritten. Not necessarily arguing that this is better than using the defaultValue property in useForm since I can see arguments for both side, but it definitely caught me off-guard and broke my edit forms since they would be all empty by bumping to this version.
Or it could make sure that it only overwrites stuff if the defaultValue is provided and input is currently empty.
Conform version
v1.2.1
Steps to Reproduce the Bug or Issue
const schema = z.object({ displayName: z.string() });

const [fields] = useForm({
  onValidate: ({ formData }) => {
    return parseWithZod(formData, { schema });
  }
});

const inputDefaultValue = "default-value";

<input name={fields.displayName.name} defaultValue={inputDefaultValue} />

In here we can assert that the input will in fact be changed to an empty one.
What browsers are you seeing the problem on?
Chrome, Firefox, Microsoft Edge, Safari
Screenshots or Videos
No response
Additional context
No response

Same issue if my isActive boolean default value is set to true the form won't pick up the value until I turn the value off and then on again

Thanks for the writeup. I have gave it some thoughts last night and my current plan is to make this opt-in with an option to customize the behavior. I will put up a draft PR with more information later today. Sorry for the trouble!

Thanks for the writeup. I have gave it some thoughts last night and my current plan is to make this opt-in with an option to customize the behavior. I will put up a draft PR with more information later today. Sorry for the trouble!

That'd be perfect, thanks for the quick turnaround. It's really appreciated 👍

I have put up a fix on #775. Can you give the pre-release a try and let me know if you run into any issues? Thanks.

I have put up a fix on #775. Can you give the pre-release a try and let me know if you run into any issues? Thanks.

Tested this pre-release versions and no longer running into issues with my inputs being cleared due to the lack of defaultValue.

I'm sorry for the trouble. I've concluded that it's best to revert the relevant changes, and I've just published v1.2.2.

That works as well! Already tested 1.2.2 and can attest it fixes this issue, thus I'm closing this. Thanks!


Unexpected token '.' when using eval with optional chaining operator

Description
SyntaxError: Unexpected token '.' when using the optional chaining operator in eval().
Note I am using Expo SDK 44. Does anyone know if this would have anything to do with it? Should I be reporting it in the Expo repo instead?
Version
0.64.3
Output of npx react-native info
System:
    OS: Windows 10 10.0.19042
    CPU: (12) x64 Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz
    Memory: 16.94 GB / 31.81 GB
  Binaries:
    Node: 16.13.1 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.14.15 - ~\Documents\Projects\project_name\node_modules\.bin\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK: Not Found
    Windows SDK:
      AllowAllTrustedApps: Disabled
      Versions: 10.0.17763.0, 10.0.19041.0
  IDEs:
    Android Studio: Version     2<IP_ADDRESS> AI-203.7717.56.2031.7935034
    Visual Studio: Not Found
  Languages:
    Java: Not Found
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.1 => 17.0.1
    react-native: 0.64.3 => 0.64.3
    react-native-windows: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Steps to reproduce
Example code
let someObject = { propertyMayOrMayNotExist: { deeper: 'test' } }
eval('someObject.propertyMayOrMayNotExist?.deeper')

Running that code in Node or the browser works just fine.
But running that code in a React Native project generates an error: SyntaxError: Unexpected token '.'
If you change the second line to:
console.log(someObject.propertyMayOrMayNotExist?.deeper)
or
eval('someObject.propertyMayOrMayNotExist.deeper')
then it works.
Snack, code example, screenshot, or link to a repository
No response

Same problem here, with react native 0.63.4.
I init  a new project  in version 0.63.4 and gave this problem too


Add more languages (PT_BR) to /usr/share/vim/vim90/keymap/

Steps to reproduce
I use KDE, the truth, I have problem with neovide which bound to vim.
Using the normal Konsole and vim I use my system's keyboard, which here is "Keyboard Portuguese (Brasil) - IBM / Lenovo ThinkPad", this one has a keymap better there normal abnt2.
It's easy to find it on images on internet, just type: portuguese (brazilian abnt2) keyboard layout.
The problem is when I use neovide, I just want to go to my init.vim and type there set keymap="portuguese-br".
I tried to create my own modified file but vim couldn't find it.
Is it possible to create a Keymap file for Portuguese_BR speakers? Thanks in advance
Expected behaviour
I just to use the keyboard without trying to find the key and retyping all the time.
I just want to go to my init.vim and type there set keymap="portuguese-br".
Version of Vim
9.0.1420
Environment
Garuda Linux x86_64
Terminal: konsole 22.12.3
Value of $TERM: xterm-256color
Shell: fish 3.6.1
Logs and stack traces
No response

I am not sure, this is a bug for Vim. You may want to ask user questions on vi.stackexchange.com (e.g. how to properly create keymaps).
This is a bug tracker for vim, we cannot provide individual help here.

This doesn't look like a Vim bug, as the label would suggest.  It's definitely possible to add your own keymap.  If you have problems with that, you can find help elsewhere.  If you are looking for an existing keymap, I'm not sure where to ask, perhaps there is a Brazilian Vim user group?
Anyway, this is not an issue we can fix, so let's close it.


Support for machine numbers

Support for patterns like a + b -> $add a b that will act as following:
2 + 2 -> 4
(1 + 2) + 3 -> 6
(a + 2) + 3 -> a + 5
1 + ((a + 2) + 3) -> a + 6

This will require numbers to be a  specific builtin though :(

basic support implemented


Color of selected date

Even if I set on layout a different color, sometimes it will popup back with the defaults. I think I set the correct attrs:
 app:mti_bgLblDateSelectedColor="..."   app:mti_lblDateColor="..."   app:mti_ringLblDateSelectedColor="..."   app:mti_tabBeforeSelectionColor="..."   app:mti_tabSelectedColor="..."
Next days if I have time I'll look into src code to find the bug, if you spot it before me please answer this issue.
ty

As workaround, you can override the values in your colors.xml
	<color name="mti_bg_lbl_date_selected_color">@color/colorPrimary</color> 	<color name="mti_ring_lbl_date_color">@color/colorPrimary</color>

Will try this, thank you!


sourcemaps not working

Using the latest versions, sourcemaps have stopped working. I updated my karma config with no success.
I'm using these versions:
"karma": "^2.0.0",
"karma-rollup-preprocessor": "^5.0.0",
"rollup": "^0.54.0"

And this config:
rollupPreprocessor: {
	plugins: [...listOfPlugins],
	output: {
		sourcemap: 'inline'
	},
	format: 'iife',
	name: 'projectname'
}

Any suggestions?

I have encountered this issue as well. So here is a repo that reproduces the issue:
https://github.com/Lalem001/karma-rollup-preprocessor-issue


Privacy Policy URL 404s

The privacy policy link in the info screen (http://onebusaway.org/privacy/) returns a 404. Either get that URL working, or update the app to the correct URL by modifying kPrivacyURLString in OBAInfoViewController.m.

I'll work on fixing this on OBA.org.
On Jul 3, 2015 3:26 AM, "Yogi Patel"<EMAIL_ADDRESS>wrote:

The privacy policy link in the info screen (http://onebusaway.org/privacy/)
returns a 404. Either get that URL working, or update the app to the
correct URL by modifying kPrivacyURLString in OBAInfoViewController.m.
—
Reply to this email directly or view it on GitHub
https://github.com/OneBusAway/onebusaway-iphone/issues/431.

Related to this - I'm re-creating the privacy page, and we have a reference to OBA iOS using TestFilght for beta version distribution.  Is this still correct?  Or did we abandon TestFlight for OBA iOS?

Ok, this is fixed - privacy page no longer returns a 404 - http://onebusaway.org/privacy/.  Just let me know about TestFlight, and I'll update the page as to whether its still used on iOS or not.

TestFlight is still used on iOS but TestFlight is now owned by Apple so the privacy policy has changed.
Some other comments on the privacy policy page:

"Github" and other variants should be changed to "GitHub"
Double spaces are unnecessary