Implement (proper) support for configuring multi-datapaths

At the moment we only support configuring multiple datapath elements via running separate instances of Faucet with different configuration files (on separate ports)
This makes it annoying to manage multiple OpenFlow-enabled switches since we need to assign separate TCP ports for each to connect back to our multiple Faucet instances.
In original Valve we had the ability to list multiple DPIDs in the configuration file that would be configured (with different numbers of ports and different vlan assignments).
I think this change will require a change to the config file format since there doesn't appear to be an easy way to list additional datapaths in there.

The config file format should not need to be changed. Multiple datapaths can be read as multiple documents within the single file (IE separate them with a "---" line). It will require changing how the configs are read though, the files are currently being read by the DP object, which doesnt make sense if it is reading in multiple DP objects from a single file..

Can you also make sure that documentation is updated accordingly as this impacts how Faucet is used?  Thanks

Also will need appropriate example config files added to the repo and tests written.
We're thinking this will make a good SDNcon project for someone if no one else gets to it first.

That's a good idea, I'll add it to the list.

Hi all,
So the Victoria team at SDNcon took on this project, and we implemented it, changing the configuration format along the way. Our changes are being tracked here, in @gwacter's local branch.
Configuring multiple DPs currently looks something like this:
dps:
    1:
        dp_id: 0x000000000001
        name: "test-switch-1"
        interfaces:
            1:
                native_vlan: 2040
                acl_in: 1
    2:
        dp_id: 0x000000000002
        name: "test-switch-2"
        interfaces:
            1:
                native_vlan: 2040
                acl_in: 1

vlans:
    2040:
        name: "dev VLAN"

acls:
    1:
        - rule:
            nw_dst: "<IP_ADDRESS>/8"
            dl_type: 0x800
            allow: 1

        - rule:
            dl_type: 0x0806
            allow: 1

        - rule:
            nw_dst: "<IP_ADDRESS>/16"
            dl_type: 0x800
            allow: 0

        - rule:

I understand this will need some discussion before it gets merged because it breaks the current configuration format (although we could probably add backwards compatibility), so @gizmoguy and I had a quick chat and thought it would be a good idea for me to post here and start a discussion to determine what format this change should ultimately take, and when it should be merged (when version 2.0 is branched off for development?)
In the mean time, we'll clean up our code, add documentation, write associated tests and make a pull request when it is ready.

Hi Callum and Brad;
This sure is nice! Thanks for doing this - I imagine you have looked into
inter DP connections as well? I can imagine building larger switches out of
individual DPs will come in handy.
Can we enumerate the DPs directly by DP ID? Seems to be no need for a
separate index?
On Mon, Jul 11, 2016 at 5:00 PM, Callum Dickinson<EMAIL_ADDRESS>wrote:

Hi all,
So the Victoria team at SDNcon took on this project, and we implemented
it, changing the configuration format along the way. Our changes are being
tracked here https://github.com/gwacter/faucet/tree/multiple-dps, in
@gwacter https://github.com/gwacter's local branch.
Configuring multiple DPs currently looks something like this:
dps:
1:
dp_id: 0x000000000001
name: "test-switch-1"
interfaces:
1:
native_vlan: 2040
acl_in: 1
2:
dp_id: 0x000000000002
name: "test-switch-2"
interfaces:
1:
native_vlan: 2040
acl_in: 1
vlans:
2040:
name: "dev VLAN"
acls:
1:
- rule:
nw_dst: "<IP_ADDRESS>/8"
dl_type: 0x800
allow: 1
    - rule:
        dl_type: 0x0806
        allow: 1

    - rule:
        nw_dst: "<IP_ADDRESS>/16"
        dl_type: 0x800
        allow: 0

    - rule:

I understand this will need some discussion before it gets merged because
it breaks the current configuration format (although we could probably add
backwards compatibility), so @gizmoguy https://github.com/gizmoguy and
I had a quick chat and thought it would be a good idea for me to post here
and start a discussion to determine what format this change should
ultimately take, and when it should be merged (when version 2.0 is branched
off for development?)
In the mean time, we'll clean up our code, add documentation, write
associated tests and make a pull request when it is ready.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-231642555, or mute
the thread
https://github.com/notifications/unsubscribe/AEgZ1wTH8-S-oyX9dS0JryhUN84kw0dHks5qUc3ygaJpZM4I5RpP
.

Hi guys.
I agree with @anarkiwi that we should probably just enumerate by DP_ID (like we did back in Valve) so it would look a bit like this:
dps:
    0x000000000001:
        name: "test-switch-1"
        interfaces:
            1:
                native_vlan: 2040
                acl_in: 1
    0x000000000002:
        name: "test-switch-2"
        interfaces:
            1:
                native_vlan: 2040
                acl_in: 1

@KitL also had an idea of using separate YAML documents for each DP_ID which might make backwards compatibility a bit nicer, however it makes sharing VLANs between DP_IDs difficult which is what I like about the approach @Callum027 etc have taken.

While not backward compatible, I think this is a big enough step forward to
go through the inconvenience of changing it (especially while the number of
deployments is relatively low).
I have been thinking also of adding "include file" support, which would
allow splitting out relatively static parts of the config from more dynamic
parts, which would then allow automation to change parts of the config
perhaps with different permissions. However that probably deserves a thread
of its own.
Can I suggest that as part of the merge process, that the new config file
format be implemented as a PR by itself? It should accept only one DPID.
On Mon, Jul 11, 2016 at 11:33 PM, Brad Cowie<EMAIL_ADDRESS>wrote:

Hi guys.
I agree with @anarkiwi https://github.com/anarkiwi that we should
probably just enumerate by DP_ID (like we did back in Valve) so it would
look a bit like this:
dps:
0x000000000001:
name: "test-switch-1"
interfaces:
1:
native_vlan: 2040
acl_in: 1
0x000000000002:
name: "test-switch-2"
interfaces:
1:
native_vlan: 2040
acl_in: 1
@KitL https://github.com/KitL also had an idea of using separate YAML
documents for each DP_ID which might make backwards compatibility a bit
nicer, however it makes sharing VLANs between DP_IDs difficult which is
what I like about the approach @Callum027 https://github.com/Callum027
etc have taken.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-231872422, or mute
the thread
https://github.com/notifications/unsubscribe/AEgZ196uJ7bHqat2z5ikDYSk38STuQEeks5qUrbDgaJpZM4I5RpP
.

Hi guys,
Listening in, I have a suggestion regarding the config file format change.
When Docker was changing the format of the docker-compose.yml file, they introduced the config file syntax version into the syntax.
So when using the new syntax, you start your config file with:
version: '2'

This makes it easy for the parser to know which version to parse - and makes it possible to support both versions of the syntax.  And for future changes, it gives you each config file tagged with the version of the syntax it was written it...
More info + examples at https://docs.docker.com/compose/compose-file/#/versioning
Hope this helps!
Cheers,
Vlad

@gizmoguy, we can change the indexes to use the DPID directly, no problem. We initially used the numerical indexing because we thought it would make it more consistent with other data structures with the configuration format, but having it as you and @anarkiwi suggested would be better, as the numerical index serves no other real purpose.
@anarkiwi, so you would like there to be two PRs, one with the new config file format specifying the dps data structure along with other changes, and another one implementing multiple DP support within Faucet itself? We can do that if that's what you prefer.
@vladimir-mencl-eresearch, that is up to the REANNZ folks but I think this is a good idea. We could have version default to 1 if it is not specified, until the next major release, where the default should be fine to change to 2.

Yes please - a PR that changes the config file format and only supports one
DPID (iike today).
That should make the merge/review/test process considerably easier.
Yes please also on config file version - great idea.
Thanks,
On Tue, Jul 12, 2016 at 10:16 AM, Callum Dickinson<EMAIL_ADDRESS>
wrote:

@gizmoguy https://github.com/gizmoguy, we can change the indexes to use
the DPID directly, no problem. We initially used the numerical indexing
because we thought it would make it more consistent with other data
structures with the configuration format, but having it as you and
@anarkiwi https://github.com/anarkiwi suggested would be better, as the
numerical index serves no other real purpose.
@anarkiwi https://github.com/anarkiwi, so you would like there to be
two PRs, one with the new config file format specifying the dps data
structure along with other changes, and another one implementing multiple
DP support within Faucet itself? We can do that if that's what you prefer.
@vladimir-mencl-eresearch https://github.com/vladimir-mencl-eresearch,
that is up to the REANNZ folks but I think this is a good idea. We could
have version default to 1 if it is not specified, until the next major
release, where the default should be fine to change to 2.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-231882372, or mute
the thread
https://github.com/notifications/unsubscribe/AEgZ15fB1dSrFNWigb0Ju44AoPgpUnzJks5qUsClgaJpZM4I5RpP
.

I've made a fourth branch, gwacter/new-config-format, to track the new configuration format. I've implemented it as discussed, so if version is not specified or is set to 1, it will parse the configuration as before, and if it is set to 2, it will use a different version of the parse method which parses for dps (but of course, will only actually use the first one).
The configuration format would look like this:
version: 2

dps:
    0x000000000001:
        name: "test-switch-1"
        interfaces:
            1:
                native_vlan: 2040
                acl_in: 1
    0x000000000002:
        name: "test-switch-2"
        interfaces:
            1:
                native_vlan: 2040
                acl_in: 1

vlans:
    2040:
        name: "dev VLAN"

acls:
    1:
        - rule:
            nw_dst: "<IP_ADDRESS>/8"
            dl_type: 0x800
            allow: 1

        - rule:
            dl_type: 0x0806
            allow: 1

        - rule:
            nw_dst: "<IP_ADDRESS>/16"
            dl_type: 0x800
            allow: 0

        - rule:

I will test that the changes work (I am at home at the moment so no testbed to play with), and then make a PR.
For the documentation, should we modify the Configuration section of README.rst to elaborate a bit more on the configuration format, or would you rather there be two sample configuration files, one for each version?

Thanks. Looks pretty nice. Yes please, please do include updating
README.rst in the PR (no need to document both - we can do a release with
v1.1 soon after, and I can do a quick blog post calling out the change).
On Wed, Jul 13, 2016 at 10:53 AM, Callum Dickinson<EMAIL_ADDRESS>
wrote:

I've made a fourth branch, gwacter/new-config-format
https://github.com/gwacter/faucet/tree/new-config-format, to track the
new configuration format. I've implemented it as discussed, so if version
is not specified or is set to 1, it will parse the configuration as
before, and if it is set to 2, it will use a different version of the
parse method which parses for dps (but of course, will only actually use
the first one).
The configuration format would look like this:
version: 2
dps:
0x000000000001:
name: "test-switch-1"
interfaces:
1:
native_vlan: 2040
acl_in: 1
0x000000000002:
name: "test-switch-2"
interfaces:
1:
native_vlan: 2040
acl_in: 1
vlans:
2040:
name: "dev VLAN"
acls:
1:
- rule:
nw_dst: "<IP_ADDRESS>/8"
dl_type: 0x800
allow: 1
    - rule:
        dl_type: 0x0806
        allow: 1

    - rule:
        nw_dst: "<IP_ADDRESS>/16"
        dl_type: 0x800
        allow: 0

    - rule:

I will test that the changes work (I am at home at the moment so no
testbed to play with), and then make a PR.
For the documentation, should we modify the Configuration section of
README.rst to elaborate a bit more on the configuration format, or would
you rather there be two sample configuration files, one for each version?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-232206185, or mute
the thread
https://github.com/notifications/unsubscribe/AEgZ10gJ7YMPPWBBIqmeQ2AbCn_EbV3dks5qVBrlgaJpZM4I5RpP
.

Sorry, I just made a PR for this and didn't notice your comment on not needing to document the configuration format change - should I modify it to just give more detail on the current format?

Can you hold off on a 1.1 release until I get a chance to go through this next week. I have some work here on changing the configuration for gauge. It involves a pretty significant change to how configuration is stuctured. It would be good to have all of this together in the 1.1 release.
I have been on holiday since the SDNCon so I havent had the chance to merge my work back

I just unit tested this and it passes all tests. I upgraded my network to
use config file format version 2, and it works also.
Absolutely defer to you on a new release so that config is unified. However
this particular change is backward compatible and passes tests, so I will
merge.
On Fri, Jul 15, 2016 at 1:36 PM, KitL<EMAIL_ADDRESS>wrote:

Can you hold off on a 1.1 release until I get a chance to go through this
next week. I have some work here on changing the configuration for gauge.
It involves a pretty significant change to how configuration is stuctured.
It would be good to have all of this together in the 1.1 release.
I have been on holiday since the SDNCon so I havent had the chance to
merge my work back
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-232838741, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ18TIP_jz7tEav1bSlEuCgCHC2wp0ks5qVuQMgaJpZM4I5RpP
.

I've rebased gwacter/multiple-dps, cleaned up the code and modified test_config.py to work again (and added a second, duplicate switch in there to test for good measure). Is there a need to write tests for faucet_mininet_test.py that uses multiple DPs?

Great!
Yes, to actually use multiple DPs we absolutely need tests. New config
format is one thing, but the new functionality absolute needs to be tested.
On Jul 15, 2016 5:02 PM, "Callum Dickinson"<EMAIL_ADDRESS>wrote:

I've rebased gwacter/multiple-dps
https://github.com/gwacter/faucet/tree/multiple-dps, cleaned up the
code and modified test_config.py to work again (and added a second,
duplicate switch in there to test for good measure). Is there a need to
write tests for faucet_mininet_test.py that uses multiple DPs?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-232860211, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ17fkZBaCNtDjaMiw3Vt9d7LaNCSHks5qVxRPgaJpZM4I5RpP
.

It looks like we will need to change faucet_mininet_test.py to use the new config format and give it the ability to add multiple DPs to the test. This looks like a lot more work than I expected, so I'll track all the changes for that in a separate branch, gwacter/mininet-test-v2, and make a PR when it's ready. This branch will not include the tests for multiple DPs, those will be made in gwacter/multiple-dps and the PR for that will depend on gwacter/mininet-test-v2 being merged.

Every single test class doesn't have to have two controllers.
You could just create a test class that has a new topology that has two
switches, and two hosts on each, with the same controller. It can just test
untagged functionality.
I don't think that should be much work. It doesn't have to support hardware
but that would be a nice to have.
On Tue, Jul 19, 2016 at 5:28 PM, Callum Dickinson<EMAIL_ADDRESS>wrote:

It looks like we will need to change faucet_mininet_test.py to use the
new config format and give it the ability to add multiple DPs to the test.
This looks like a lot more work than I expected, so I'll track all the
changes for that in a separate branch, gwacter/mininet-test-v2
https://github.com/gwacter/faucet/tree/mininet-test-v2, and make a PR
when it's ready. This branch will not include the tests for multiple DPs,
those will be made in gwacter/multiple-dps and the PR for that will depend
on gwacter/mininet-test-v2 being merged.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-233535761, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ18mN70g1NNBwy-xBjHfJr4Cr9Fpsks5qXGB0gaJpZM4I5RpP
.

Another idea; I am out of the country right now, but I could come meet and
we could hash out a plan?
I'd very much like to see FAUCET benefit from your work here so I'm
motivated to have your contribution integrated.
I am back next week. Would you care to nominate a convenient time/place and
I can come to you?
On Tue, Jul 19, 2016 at 5:33 PM, Bailey, Josh<EMAIL_ADDRESS>wrote:

Every single test class doesn't have to have two controllers.
You could just create a test class that has a new topology that has two
switches, and two hosts on each, with the same controller. It can just test
untagged functionality.
I don't think that should be much work. It doesn't have to support
hardware but that would be a nice to have.
On Tue, Jul 19, 2016 at 5:28 PM, Callum Dickinson <
<EMAIL_ADDRESS>wrote:

It looks like we will need to change faucet_mininet_test.py to use the
new config format and give it the ability to add multiple DPs to the test.
This looks like a lot more work than I expected, so I'll track all the
changes for that in a separate branch, gwacter/mininet-test-v2
https://github.com/gwacter/faucet/tree/mininet-test-v2, and make a PR
when it's ready. This branch will not include the tests for multiple DPs,
those will be made in gwacter/multiple-dps and the PR for that will depend
on gwacter/mininet-test-v2 being merged.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-233535761, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ18mN70g1NNBwy-xBjHfJr4Cr9Fpsks5qXGB0gaJpZM4I5RpP
.

Thanks, @anarkiwi. That would be great. Any time that would be convenient for you is fine, as my work schedule is pretty flexible at the moment, but I'm usually working on Faucet (and any other project at Vic) on Friday mornings, if that is alright with you.
In the mean time, I'll do as much as I can. I need to read up on the Mininet Python API, but it shouldn't take too long if I don't have to change every test.

Great, I suggest AM410 11am next Friday (anyone else  on thread welcome to
join).
Much appreciated. Yes, adding a new test that an even simpler topology but
still tests multiple dataplanes would be fine.
On Wed, Jul 20, 2016 at 1:11 PM, Callum Dickinson<EMAIL_ADDRESS>wrote:

Thanks, @anarkiwi https://github.com/anarkiwi. That would be great. Any
time that would be convenient for you is fine, as my work schedule is
pretty flexible at the moment, but I'm usually working on Faucet (and any
other project at Vic) on Friday mornings, if that is alright with you.
In the mean time, I'll do as much as I can. I need to read up on the
Mininet Python API, but it shouldn't take too long if I don't have to
change every test.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-233811943, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ1zFSEXB1G0v--t51lYDUvrFBd8y6ks5qXXXYgaJpZM4I5RpP
.

So, I ended up adding a topology, base class and very basic tests for multiple DPs, shown here.
Everything seems to be working, at least when it comes to setting up the environment. The FaucetMultipleDPTest base class (and FaucetMultipleDPSwitchTopo that goes with it) tries to be as generic as possible, taking in the number of switches, untagged hosts and tagged hosts (per switch), and building a linear topology (switches linked in line) based around it. The implemented tests at the moment use three switches, with four untagged/tagged hosts per switch.
At the moment, FaucetMultipleDPUntaggedTest and FaucetMultipleDPTaggedTest just do a pingall, which might not be sufficient. If anyone had other ideas for how the test itself can be implemented, please let me know and I'll get onto it.

Excellent progress!
There is an existing test method to check if a given flow is actually
installed in the switch.
You could add a call to this method for each host to make sure forwarding
entries have been installed (you will have to make the existing method be
able to select a switch - right now it assumes the "first" one).
On Fri, Aug 5, 2016 at 10:50 PM, Callum Dickinson<EMAIL_ADDRESS>wrote:

So, I ended up adding a topology, base class and very basic tests for
multiple DPs, shown here
https://github.com/gwacter/faucet/compare/gwacter:635120a^^^^...gwacter:635120a
.
Everything seems to be working, at least when it comes to setting up the
environment. The FaucetMultipleDPTest base class (and
FaucetMultipleDPSwitchTopo that goes with it) tries to be as generic as
possible, taking in the number of switches, untagged hosts and tagged hosts
(per switch), and building a linear topology (switches linked in line)
based around it. The implemented tests at the moment use three switches,
with four untagged/tagged hosts per switch.
At the moment, FaucetMultipleDPUntaggedTest and FaucetMultipleDPTaggedTest
just do a pingall, which might not be sufficient. If anyone had other ideas
for how the test itself can be implemented, please let me know and I'll get
onto it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-237821315, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ12z8QPDl0ErK0GIujApQ9q7L2d6bks5qcxWDgaJpZM4I5RpP
.

Sounds good. If the method you are talking about is FaucetTest.wait_until_matching_flow, then at the moment I have slightly reimplemented that method to just run the check on all switches due to FaucetTest.start_net requiring that behaviour. I will change it again to take a dpid as an argument instead (and probably reimplement start_net to make it not use the existing one), and implement the flow checks on each switch for each host.

Callum, there is an issue with our implementation. It currently does not support routing. Since vlan config is loaded multiple times (one for each dp), the creation of BGP speakers will fail. Also, arp resolution is not working across switches. For example, in this network <IP_ADDRESS>/24 <--- h1 -- s1 -- s2 -- h2, s2 valve fails to resolve h1 arp in order to install a fib on s2.
We currently have a different valve for each switch and they do not share any state.

Thanks for bringing this to my attention. I'll more carefully look at the BGP implementation (and configure a real one that is not just the test) and see what's happening.
ARP resolution not working is very weird. That should be fine.
On 6/08/2016 00:18, trungdtbk<EMAIL_ADDRESS>wrote:Callum, there is an issue with our implementation. It currently does not support routing. Since vlan config is loaded multiple times (one for each dp), the creation of BGP speakers will fail. Also, arp resolution is not working across switches. For example, in this network <IP_ADDRESS>/24 <--- h1 -- s1 -- s2 -- h2, s2 valve fails to resolve h1 arp in order to install a fib on s2.
We currently have a different valve for each switch and they do not share any state.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

The way BGP speakers are configured on VLANs at the moment is not compatible with multiple DPs. The vlans section will have to be configured per DP, so BGP speakers can be configured per DP, in turn.
Sorry about this. Should have picked up on this. I'll make a separate PR for the configuration changes.
I initially misunderstood your description of the ARP issue. The valve object for s2 is trying to resolve h1 via ARP to install a FIB for h1 on s2,  and is failing to resolve it? It ends up working regardless, but I'll see what's happening.
We want each valve object to be separate as there is no guarantee they are topologically connected. They just happen to be connected to the same controller and being configured by the same Faucet instance (at least, at the moment).

Sorry, I edited the above post, if you're reading this via email.

@KitL, we've determined in issue #112 that the current format for configuring VLANs is not compatible with multiple DPs since BGP speaker support was added (BGP speakers would get added for each switch with the same settings.)
The vlans section might have to be defined per DP (or given the option to with preference for per-DP settings), or the BGP speaker configuration might have to be split from the global vlans section in some other way.
Is there changes we can make in PR #149 so we can get around this issue?

Added per other email thread:
Regarding VLAN + BGP. As a matter of practicality. I think it's fine to add
a check for now to assert if you have BGP on a VLAN that is shared between
DPs, that this is unsupported (ie. catch this at config time).
I can imagine in the future, we can make a virtual switch out of a bunch of
smaller DPs, in and this case having one BGP instance as a virtual router
will make a lot of sense.
On Sat, Aug 6, 2016 at 9:40 AM, Callum Dickinson<EMAIL_ADDRESS>wrote:

@KitL https://github.com/KitL, we've determined in issue #112
https://github.com/REANNZ/faucet/issues/112 that the current format for
configuring VLANs is not compatible with multiple DPs since BGP speaker
support was added (BGP speakers would get added for each switch with the
same settings.)
The vlans section might have to be defined per DP (or given the option to
with preference for per-DP settings), or the BGP speaker configuration
might have to be split from the global vlans section in some other way.
Is there changes we can make in PR #149
https://github.com/REANNZ/faucet/pull/149 so we can get around this
issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-237972733, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ1z3mzI-1b1DlaCNtPHzxJkYv0Fjaks5qc63AgaJpZM4I5RpP
.

I have added some checks when vlan objects get added to DPs. They will now only be added if the VLAN is actually used by the DP, and if that VLAN is shared with another and BGP is configured, an assert will fail and this will be logged. Here are the changes.
@trungdtbk, I'm still not sure what the issues are with the implementation. Could you elaborate on what exactly is going wrong?

Great, I'll take a look.
I confess I don't understand the issue Trung is asserting.
Perhaps Trung you can express it in the form of a unit test that fails?
That would make it clearer.
On Aug 10, 2016 13:30, "Callum Dickinson"<EMAIL_ADDRESS>wrote:
I have added some checks when vlan objects get added to DPs. They will now
only be added if the VLAN is actually used by the DP, and if that VLAN is
shared with another and BGP is configured, an assert will fail and this
will be logged. Here are the changes.
https://github.com/gwacter/faucet/compare/gwacter:aab418d^^...gwacter:aab418d
@trungdtbk https://github.com/trungdtbk, I'm still not sure what the
issues are with the implementation. Could you elaborate on what exactly is
going wrong?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238741938, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ11v0W7oUoyPPzRS2kEh2PGwmVjDtks5qeSnAgaJpZM4I5RpP
.

OK, would you send a PR please against the REANNZ master branch?
I'll then patch it in and test in my development environment to make sure I
understand it thoroughly.
Thanks,
On Wed, Aug 10, 2016 at 1:34 PM, Bailey, Josh<EMAIL_ADDRESS>wrote:

Great, I'll take a look.
I confess I don't understand the issue Trung is asserting.
Perhaps Trung you can express it in the form of a unit test that fails?
That would make it clearer.
On Aug 10, 2016 13:30, "Callum Dickinson"<EMAIL_ADDRESS>wrote:
I have added some checks when vlan objects get added to DPs. They will
now only be added if the VLAN is actually used by the DP, and if that VLAN
is shared with another and BGP is configured, an assert will fail and this
will be logged. Here are the changes.
https://github.com/gwacter/faucet/compare/gwacter:aab418d^^...gwacter:aab418d
@trungdtbk https://github.com/trungdtbk, I'm still not sure what the
issues are with the implementation. Could you elaborate on what exactly is
going wrong?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238741938, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ11v0W7oUoyPPzRS2kEh2PGwmVjDtks5qeSnAgaJpZM4I5RpP
.

I will write a test after this PR. The issue relates to routing.
Given this topo H1(<IP_ADDRESS>) <--> S1 <---> S2 <---> H2 and vlan with route <IP_ADDRESS>/24, nexthop <IP_ADDRESS>.
S2 will not get fib entry because the corresponding valve never gets arp. The arp rely will arrive at S1 and be handled by valve1.

This seems like a misconfiguration?
In this case you would configure S1 as a switch with its own VLAN. And S2
as the router with a different VLAN. S1 reduces then to just a wire.
Distributed switching/routing is not something that is supported yet
(though I think we'd welcome it as a feature).
On Wed, Aug 10, 2016 at 2:02 PM, trungdtbk<EMAIL_ADDRESS>wrote:

I will write a test after this PR. The issue relates to routing.
Given this topo H1(<IP_ADDRESS>) <--> S1 <---> S2 <---> H2 and vlan with route
<IP_ADDRESS>/24, nexthop <IP_ADDRESS>.
S2 will not get fib entry because the corresponding valve never gets arp.
The arp rely will arrive at S1 and be handled by valve1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238746071, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ18YZNlO8PtQdfza6Ey7m9LujWIF8ks5qeTFSgaJpZM4I5RpP
.

I dont think you could configure that if the links between s1 and s2 needed
to be tagged. It seems like that would be the most likely scenario for
setting that up.
vlan rewriting would probably be a good thing to add to faucet.
I am starting to think that splitting routing out of the vlan configuration
would be a good idea.
On 10 August 2016 at 14:05, Josh Bailey<EMAIL_ADDRESS>wrote:

This seems like a misconfiguration?
In this case you would configure S1 as a switch with its own VLAN. And S2
as the router with a different VLAN. S1 reduces then to just a wire.
Distributed switching/routing is not something that is supported yet
(though I think we'd welcome it as a feature).
On Wed, Aug 10, 2016 at 2:02 PM, trungdtbk<EMAIL_ADDRESS>wrote:

I will write a test after this PR. The issue relates to routing.
Given this topo H1(<IP_ADDRESS>) <--> S1 <---> S2 <---> H2 and vlan with
route
<IP_ADDRESS>/24, nexthop <IP_ADDRESS>.
S2 will not get fib entry because the corresponding valve never gets arp.
The arp rely will arrive at S1 and be handled by valve1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238746071,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AEgZ18YZNlO8PtQdfza6Ey7m9LujWIF8ks5qeTFSgaJpZM4I5RpP>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238746317, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB48FbZigv_03RuroX5Kl_ls84kL7E22ks5qeTHfgaJpZM4I5RpP
.

Actually, you could configure that with the new config. You just configure
two separate vlans with different names but sharing the same VID. eg dp 1
uses 'v2040' and dp 2 uses 'v2040-with-router'.
Unintended consequences! Though I dont know that this is actually a
sensible way of configuring a device.
On 10 August 2016 at 14:24, Christopher Lorier<EMAIL_ADDRESS>wrote:

I dont think you could configure that if the links between s1 and s2
needed to be tagged. It seems like that would be the most likely scenario
for setting that up.
vlan rewriting would probably be a good thing to add to faucet.
I am starting to think that splitting routing out of the vlan
configuration would be a good idea.
On 10 August 2016 at 14:05, Josh Bailey<EMAIL_ADDRESS>wrote:

This seems like a misconfiguration?
In this case you would configure S1 as a switch with its own VLAN. And S2
as the router with a different VLAN. S1 reduces then to just a wire.
Distributed switching/routing is not something that is supported yet
(though I think we'd welcome it as a feature).
On Wed, Aug 10, 2016 at 2:02 PM, trungdtbk<EMAIL_ADDRESS>wrote:

I will write a test after this PR. The issue relates to routing.
Given this topo H1(<IP_ADDRESS>) <--> S1 <---> S2 <---> H2 and vlan with
route
<IP_ADDRESS>/24, nexthop <IP_ADDRESS>.
S2 will not get fib entry because the corresponding valve never gets
arp.
The arp rely will arrive at S1 and be handled by valve1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238746071,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEgZ18YZN
lO8PtQdfza6Ey7m9LujWIF8ks5qeTFSgaJpZM4I5RpP>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238746317, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB48FbZigv_03RuroX5Kl_ls84kL7E22ks5qeTHfgaJpZM4I5RpP
.

Quite possibly, but I think there are two main types of configuration here:

ships in the night. each DP is separate and has its own VLANs, routes,
you name it.

distributed switching/routing (you are making one switch/router out of
several physical DPs).

I assert that it's less confusing to consider those two main paths rather
than thinking at the rewrite-packet-by-port level.
On Wed, Aug 10, 2016 at 2:24 PM, KitL<EMAIL_ADDRESS>wrote:

I dont think you could configure that if the links between s1 and s2 needed
to be tagged. It seems like that would be the most likely scenario for
setting that up.
vlan rewriting would probably be a good thing to add to faucet.
I am starting to think that splitting routing out of the vlan configuration
would be a good idea.
On 10 August 2016 at 14:05, Josh Bailey<EMAIL_ADDRESS>wrote:

This seems like a misconfiguration?
In this case you would configure S1 as a switch with its own VLAN. And S2
as the router with a different VLAN. S1 reduces then to just a wire.
Distributed switching/routing is not something that is supported yet
(though I think we'd welcome it as a feature).
On Wed, Aug 10, 2016 at 2:02 PM, trungdtbk<EMAIL_ADDRESS>wrote:

I will write a test after this PR. The issue relates to routing.
Given this topo H1(<IP_ADDRESS>) <--> S1 <---> S2 <---> H2 and vlan with
route
<IP_ADDRESS>/24, nexthop <IP_ADDRESS>.
S2 will not get fib entry because the corresponding valve never gets
arp.
The arp rely will arrive at S1 and be handled by valve1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238746071,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AEgZ18YZNlO8PtQdfza6Ey7m9LujWIF8ks5qeTFSgaJpZM4I5RpP>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238746317,
or mute
the thread
<https://github.com/notifications/unsubscribe-
auth/AB48FbZigv_03RuroX5Kl_ls84kL7E22ks5qeTHfgaJpZM4I5RpP>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238748815, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ1ws7PZSGtLd8hnuNW-0C0sYQhHnDks5qeTZkgaJpZM4I5RpP
.

Ok, I actually missed Callum's earlier message, despite it mentioning me specifically.
What I would suggest is to move the router configuration out of the vlan section and into its own section. Possibly create a Router configuration object as well, following the structure of the other objects.
The router should just have a single vlan interface for now, but we should prepare for routing between vlans in future.
So it would look something like:
routers:
switch1-v2040-router:
interfaces:
p_s1_v2040:
dp: "switch1"
vlan: "v2040"
controller_ip: "<IP_ADDRESS>/24"
bgp_routerid: "<IP_ADDRESS>"
etc: "yadda yadda yadda"
This was something I was considering doing during my change, but I decided against it because I wasnt sure about how the bgp config was working and the whole thing was taking forever.
However for the short term, investigate whether having two vlans with different names but the same vid breaks things entirely. I feel like it shouldnt, but it might require a couple of tweaks. So you might not have to change the config at all.

I guess I refer to the earlier point.
We really want two different modes.
Ships in the night - each switch has its own config. It migjt even reuse
VLANs . No problem.
Distributed. We don't have a handle on this yet. That's fine we should
discuss it further rather than solve it incrementally as there are more
implications (as I think Trung is raising).
On Aug 10, 2016 3:12 PM, "KitL"<EMAIL_ADDRESS>wrote:

Ok, I actually missed Callum's earlier message, despite it mentioning me
specifically.
What I would suggest is to move the router configuration out of the vlan
section and into its own section. Possibly create a Router configuration
object as well, following the structure of the other objects.
The router should just have a single vlan interface for now, but we should
prepare for routing between vlans in future.
So it would look something like:
routers:
switch1-v2040-router:
interfaces:
p_s1_v2040:
dp: "switch1"
vlan: "v2040"
controller_ip: "<IP_ADDRESS>/24"
bgp_routerid: "<IP_ADDRESS>"
etc: "yadda yadda yadda"
This was something I was considering doing during my change, but I decided
against it because I wasnt sure about how the bgp config was working and
the whole thing was taking forever.
However for the short term, investigate whether having two vlans with
different names but the same vid breaks things entirely. I feel like it
shouldnt, but it might require a couple of tweaks. So you might not have to
change the config at all.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/REANNZ/faucet/issues/112#issuecomment-238754578, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEgZ1-XCl1KvFYxsYw9qnZhKB2A1IVCRks5qeUGAgaJpZM4I5RpP
.

FAUCET does now support multiple DPs I figure this is done.


The folders....

I know this with gambiarras(Technical Resoures) like these:

- "/" in the file name;

-Import from git;

it is possible to create folders inside the git-hub, but it could be better

So my request is, please could you really create a decent system for creating folders for Git-hub users.

Please put a button, a real interface, I know that the Absence of this functionality is not of great Issue, but it could be better

-Oct4viosZ-

Hi, I believe this is a question about GitHub.com, the website. This issue tracker is for a command-line utility called hub, not the website itself. For reporting bugs and requesting features for GitHub the website, please go to https://github.com/contact or visit https://github.community. Thank you!


Not to toot my own horn, but..

https://developer.amd.com/wordpress/media/2012/10/Green-Improved_Alpha-Tested_Magnification_for_Vector_Textures_and_Special_Effects(Siggraph07).pdf

The full paper is already provided under "Algorithms / Papers".


Game crashes at start up when paired up with Optifabric and Optifine

Mod loader
Fabric
Minecraft version
1.18.2
Mod version
4.0.1
Modloader version
Fabric 1.18.2-0.14.4
Modpack info
No response
If bug:

[ ] Can you reproduce this issue with relevant mods only?

If bug: The latest.log file
https://pastebin.com/EbQ1DZd1
Issue description
The game crashed whilst unexpected error
Error: java.lang.RuntimeException: Mixin transformation of net.minecraft.class_758 failed
Exit Code: -1
Crash Report
I've removed every mod and when it is with Optifabric and Optifine, it crashes.

yeah same is there any mod that remowes lava fog? or lava texture

consider using Tweakeroo


Onboarding applicationWhitelistings to a new stable API version - 2020-01-01

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[x] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[x] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

You don't have permission to trigger SDK Automation.
Please add yourself to Azure group from opensource portal if you are MSFT employee,
or please ask reviewer to add comment *** /openapibot sdkautomation ***.
Please ask<EMAIL_ADDRESS>(or NullMDR in github) for additional help.

Can one of the admins verify this patch?

Please do not merge yet.

approving from ARM side. Patch support is added to the backlog and will be done later. But these may be proxy types anyway.

Please do not merge yet.

@raych1 can you please remove the DoNotMerge flag and complete the PR? thanks.

@MatanShabtay , can you resolve the conflicts?

@raych1 it seems there's an issue with the validation:
the same code that was already approved is now failing.
one of the parameters is a subscription id that should pass the guid regex - and for some reason the validation removes the "-" from the string and so the validation fails.

/azp run

CI checks status isn't updated. Closed and reopen PR to trigger CI.

@jianyexi , can you take a look at the lint failures?

@jianyexi , can you take a look at the lint failures?

It caused by the conflict when autorest composing all the input file in tags "package-composite-v3", it's not a lint error, but an  autorest error.
the values of $.paths["/subscriptions/{subscriptionId}/providers/Microsoft.Security/applicationWhitelistings"].get["x-ms-examples"]["Gets a list of application control VM/server groups for the subscription"].parameters["api-version"]  are not consistent in the input files

/azp run

@erelh , let me know if this PR is ready to merge.

ready to merge, thanks


For this we deployed the Dockerrun.aws.json to AWS Elastic Beanstalk to dynamically resize the user profile images stored in an S3 bucket:
  "AWSEBDockerrunVersion": "1",
  "Image": {
    "Name": "apsl/thumbor"
  },
 "Ports": [
    {
      "ContainerPort": "8000"
    }
  ]
}```

The Thumbor Docker image is pulled by the Beanstalk instance from https://hub.docker.com/r/apsl/thumbor/ by AWS, and we give it the TC_AWS_LOADER_BUCKET='foocompany-images' environment variable, where `foocompany-images` is the name of the S3 bucket.

I expected the url `.../unsafe/100x100/foocompany-images/existingimage.jpg` to work with this setting, but it always gives a 404. Unfortunately the instance logs don't give any indication that Thumbor tries to access S3 or that the TC_AWS_ setting is applied at all.

Our Thumbor docker container works with the example URL where an image is fetched and resized from imgur.

Could it be that TC_AWS_XXX is not activated in the base image?

To give more info, here is the log I see:
2016-03-01 11:53:36 thumbor:WARNING ERROR retrieving image http://foocompany-images/001d91eb-fc35-4fad-a6b0-4bf94eb43f5e.jpg: [Errno -2] Name or service not known
2016-03-01 11:53:36 tornado.access:WARNING 404 GET /unsafe/50x50/foocompany-images/001d91eb-fc35-4fad-a6b0-4bf94eb43f5e.jpg (<IP_ADDRESS>) 3.43ms

I also see in issue https://github.com/thumbor/thumbor/issues/529 that others are using thumbor with the full URL to the S3 bucket, which also works for me. I just expected that giving the TC_AWS_LOADER_BUCKET setting allows direct fetching from S3 by using bucket and image name, otherwise it wouldn't make sense to have a TC_AWS_LOADER_BUCKET setting at all.

Take a look in the working docker-compose example to view what variables do you need: https://github.com/APSL/docker-thumbor/blob/master/docker-compose-examples/aws-s3-storage.yml

Thanks eduherraiz, it was not clear from the docs that you need all these params. I got it working until a new error with the following config:
AWS_ACCESS_KEY_ID = XXX
AWS_SECRET_ACCESS_KEY = XXX
LOADER = tc_aws.loaders.s3_loader
TC_AWS_LOADER_BUCKET = my-bucket-name

Unfortunately it still crashes with error 2016-03-01 13:57:52 thumbor:WARNING ERROR retrieving image from S3 001d91eb-fc35-4fad-a6b0-4bf94eb43f5e.jpg: {'ResponseMetadata': {'HTTPStatusCode': 400, 'HostId': 'REDACTED', 'RequestId': '1AE2D8'}, 'Error': {'Message': 'The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256.', 'Code': 'InvalidRequest'}}.
This means that the thumbor plugin is using outdated authorization method (version 2) when trying to connect to AWS. All new AWS regions are exclusively using version 4. This can only be solved by updating the AWS SDK that is being used in thumbor or its dependency to do the aws auth.
Plese also see issue: https://stackoverflow.com/questions/26533245/the-authorization-mechanism-you-have-provided-is-not-supported-please-use-aws4/26538266
Is this something you guys can fix?

I think the problem is in boto:
https://github.com/boto/boto/issues/2741
Try including anothe env var:
S3_USE_SIGV4 = True

I tried it with the env var and unfortunately I didn't work. I think thumbor is using an outdated version of boto?

@eduherraiz I am delighted to tell you that the issue was solved. The following environment parameters need to be set for thumbor to load images from S3.
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
LOADER=tc_aws.loaders.s3_loader
S3_USE_SIGV4=True
TC_AWS_LOADER_BUCKET=bucket-name
TC_AWS_REGION=eu-central-1```

@bf Great! Glad to help.
Could you share your final working json configuration (without secrets) to include it here?
I will include more examples ready to use in kubernetes, and if you share it, also Beanstalk.

For AWS Beanstalk you need to create a Dockerun.aws.json file with the following contents. Create a new Beanstalk environment and simply upload the JSON file.
{
  "AWSEBDockerrunVersion": "1",
  "Image": {
    "Name": "apsl/thumbor"
  },
 "Ports": [
    {
      "ContainerPort": "8000"
    }
  ]
}

As soon as the new environment is booted, you need to go to the configuration section where you can set the environment parameters for the docker container. There you should define the following environment variables to serve files from your AWS S3 Bucket through docker to your users (all environment params are listed on https://hub.docker.com/r/apsl/thumbor/ ).
AWS_ACCESS_KEY_ID=XXXXXX
AWS_SECRET_ACCESS_KEY=XXXXXX
LOADER=tc_aws.loaders.s3_loader
S3_USE_SIGV4=True
TC_AWS_LOADER_BUCKET=bucket-name
TC_AWS_REGION=eu-central-1

If you want to store the files resized by thumbor on S3 as well, you need to add some more evironment params. We use a caching server in front of thumbor which solves the need for caching of result files in S3.

Thank you!

You can add your env directly on the json:

      "environment": [
        {
          "name": "Container",
          "value": "thumbor"
        },
        {
          "name": "SECURITY_KEY",
          "value": "my key is secured"
        },
        {
          "name": "DETECTORS",
          "value": "['thumbor.detectors.queued_detector.queued_complete_detector',]"
        },
etc...

Thanks for the info, but I prefer that our team has transparence into the configuration params of our running instances from within AWS. This also makes it easier to respond to change requests without having to redeploy the whole cluster - we only have to change the config and AWS takes it from there.


Optimize overriding reminder by reducing one state store operation

Description
Optimize overriding reminder by reducing one state store operation.
Issue reference
Close #2985
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[x] Unit tests passing
[x] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

Please fix CI.

Please fix CI.

Fixed.

Thanks for the contribution but this change will not be applicable anymore with this refactor: https://github.com/dapr/dapr/pull/3297/files
Also, optimizing performance in a single record db is not ideal since we have a case where the database exceeds the max bytes allowed on the record. We should optimize for the partitioned data solution - which will be added by the change above.

Got it. Thanks for your reply.


Add version information to PyOPIA command line interface

To make it easier to check the version of PyOPIA being used when using the command line interface, add the version string to the output from --help or a new --version.

related to #148


Image loading fix

This pull request will fix :
https://github.com/ideaismobile/IDMPhotoBrowser/issues/145
and
https://github.com/ideaismobile/IDMPhotoBrowser/issues/137


Fix concurrent network client tests. [phab:D185]

Created by zarko at 2015-04-15 03:46:32:
Tests were failing in docker when run concurrently
because they were trying to bind to the same port.
(In non-docker mode we bind to :0 and use lsof to
get the port we want later on, but lsof is broken
in docker.) This CL randomizes the port.

schroederc accepted this revision at 2015-04-15 15:48:21

zarko closed via commit ff5258a89ea12f05ed623d929acd46a1e6848c82 at 2015-04-15 16:53:54


Using separate option

Hi, I have queries with several includes and has many relations of rows where at the end I am getting cartesian product and is slow. Looking for, I see that with Sequelize I can use separate:true in includes (https://github.com/sequelize/sequelize/pull/4177), but dont see it in your package. How can I use it?
Thanks

Hey @oscarcalvo thanks for reporting this. separate: boolean needs to be added to the IIncludeOptions.
For now you can make the compiler happy with this:
{
  include: [{
    ['separate' as any]: true,
  }]
}

(This seems to be missing on the sequelize typings as well)

ok thanks you

why is this closed ? please re-open.


Serde support?

Is there any way you guys could add a feature flag for supporting serde?

Could you explain your use case?

Could you explain your use case?

Asked this because I want to (de)serialize a user's preferred skin tone on a config file for an emoji picker so it'll show that skin tone by default for emojis with a single person.

Just tested it with emojis = { git = "https://github.com/rossmacarthur/emojis", branch = "serde", features = ["serde"] } and it works great. Thanks!

Alright, so &'static Emoji implements the traits, but Emoji doesn't. When I serialize an emoji reference, it becomes a string containing the emoji, but when I deserialize it using toml, I get this:
invalid type: string \"🥲\", expected a borrowed string

Oddly enough, it works fine when using serde_json instead. Is it just something wrong with my implementation?

Thanks for testing it! I have fixed it to work with TOML.


Add 'organization_url' parameter (#108)

Trying to implement my request. :) Works for me, but may be you can do it better.

Thanks, your code is good - but the context of the dot {{ . }} can become confusing when using nested with statements. In my commit, I used some if statements so that the value of {{ . }} is a bit clearer :)


fixes small typo in readme.md (of --> if)

extremely minor typo in readme, so minor I didn't even bother to create a feature branch.

:+1: thanks!


Component position offsets not affecting model

Describe the bug
When changing the the position offset on a custom robot model's component, the position in the field of the component isnt being affected
Version (required):
Version: 4.0.0-beta-1
Distributor: FRC 6328
Platform: linux-x64
Build Date: 9/26/2024, 24:41:47 UTC
Electron: 32.0.2
Chromium: 128.0.6613.84
Node: 20.16.0

Are you following the setup process here? The zeroedRotations and zeroedPosition keys don't affect the component positions unless a component pose is published.

Oh, I figured it might be something like that, thanks!


How to access NetworkViewer (in tellurium spyder)?

Hi all,
I am trying to visualize some simple SBML layout models.
I installed tellurium spyder on Windows and tried to find the NetworkViewer tab, but could not find it.
It states on
https://github.com/sys-bio/sbnw
that this is part of tellurium spyder.
How can I use the NetworkViewer in Tellurium spyder?
If not, is there some possibility to use the NetworkViewer standalone on Linux?
Best Matthias

The plugin was removed due to some compatibility issues. However, now that sbnw is under development again, we might fix the issue and put it back.

Thanks. Solves the issue for me. I was just wondering why it is not part of the tellurium spyder on windows and thought there were some installation issues.

Kyle and Kiri removed it for some reason.
Herbert
On Tue, Feb 12, 2019 at 10:14 AM Matthias König<EMAIL_ADDRESS>wrote:

Thanks. Solves the issue for me. I was just wondering why it is not part
of the tellurium spyder on windows and thought there were some installation
issues.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/sys-bio/tellurium/issues/431#issuecomment-462871965,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABAZDsRvOkYgEHE_VnuFP_lW5yu99VT0ks5vMwRWgaJpZM4azHDH
.

--
Herbert Sauro, Associate Professor
University of Washington, Bioengineering
206-685-2119, www.sys-bio.org
<EMAIL_ADDRESS>Books: http://books.analogmachine.org/


Relay Client Network Layer Recipe

In addition to apollo-client and urql we should also offer a relay code snippet.

I think we have it. @n1ru4l
https://the-guild.dev/graphql/yoga-server/docs/features/subscriptions#client-usage-with-relay


Support Resampling Weeks to/from FY5253Quarter

52–53-week fiscal year are designed to end on the same day of the week each quarter / year. Therefore it should be possible to upsample / downsample to/from weeks. I made an initial attempt at this in https://github.com/pydata/pandas/pull/5148 but that PR was never merged. This logic still makes sense.
/CC @fdion
Currently attempts to do so yield:
import pandas as pd
from pandas.tseries.offsets import FY5253Quarter, Week, WeekDay
from pandas.tseries.period import Period, PeriodIndex, period_range
from datetime import datetime

offset_fyq = FY5253Quarter(weekday=WeekDay.SAT, startingMonth=12,
                       variation="last", qtr_with_extra_week=4)
freq_week = Week(weekday=WeekDay.SAT)

prange = period_range(datetime(2013, 1, 5),
                               periods=2 * 13,
                               freq=freq_week)

df = pd.DataFrame({"A": [1] * 13 + [2] * 13}, index=prange)
resampled = df.resample(offset_fyq, fill_method="mean")

ValueError                                Traceback (most recent call last)
<ipython-input-8-38fa44432b0b> in <module>()
     13
     14 df = pd.DataFrame({"A": [1] * 13 + [2] * 13}, index=prange)
---> 15 resampled = df.resample(offset_fyq, fill_method="mean")

/Users/alex/.virtualenvs/work/lib/python2.7/site-packages/pandas/core/generic.pyc in resample(self, rule, how, axis, fill_method, closed, label, convention, kind, loffset, limit, base)
   3641                               fill_method=fill_method, convention=convention,
   3642                               limit=limit, base=base)
-> 3643         return sampler.resample(self).__finalize__(self)
   3644
   3645     def first(self, offset):

/Users/alex/.virtualenvs/work/lib/python2.7/site-packages/pandas/tseries/resample.pyc in resample(self, obj)
     90
     91             if self.kind is None or self.kind == 'period':
---> 92                 rs = self._resample_periods()
     93             else:
     94                 obj = self.obj.to_timestamp(how=self.convention)

/Users/alex/.virtualenvs/work/lib/python2.7/site-packages/pandas/tseries/resample.pyc in _resample_periods(self)
    340             return obj.reindex(new_index)
    341         else:
--> 342             start = axlabels[0].asfreq(self.freq, how=self.convention)
    343             end = axlabels[-1].asfreq(self.freq, how='end')
    344

pandas/src/period.pyx in pandas._period.Period.asfreq (pandas/src/period.c:14801)()

/Users/alex/.virtualenvs/work/lib/python2.7/site-packages/pandas/tseries/frequencies.pyc in get_freq_code(freqstr)
    253             # e.g., freqstr = ('T', 5)
    254             try:
--> 255                 code = _period_str_to_code(freqstr[0])
    256                 stride = freqstr[1]
    257             except:

/Users/alex/.virtualenvs/work/lib/python2.7/site-packages/pandas/tseries/frequencies.pyc in _period_str_to_code(freqstr)
    809                           FutureWarning, stacklevel=3)
    810         except KeyError:
--> 811             raise ValueError("Unknown freqstr: %s" % freqstr)
    812
    813         return _period_code_map[alias]

ValueError: Unknown freqstr: REQ-L-DEC-SAT-4

Also should be able to downsample to Day and upsample to FY5254

well you need to provide a parse these strings and convert them to proper offsets. That is the first step. Certainly would take a PR on that limited issue. Best to fix things like this in stages and not in big PR's.


Can't expose fastapi backend api following pynecone document

Describe the bug
Can't access fastapi api route
To Reproduce
Steps to reproduce the behavior:
copy code from here
 - Code/Link to Repo:
Expected behavior
return json object  same as document
Screenshots

** Specifics (please complete the following information):**

Python Version: 3.10.9
Pynecone Version: 0.1.14
OS:  manjaro
Browser (Optional): firefox/edge

Additional context
try to build a web system for both human and other systems with restful api.

Just guessing:
is that caused by nextjs routing which does not allow that path?
The index page works fine if I use add_page(Index)

The FastAPI server is exposed on port 8000 (while the NextJS app is on port 3000).
Does it work if you go to localhost:8000/items/23 ?

@picklelo
you are right, the 8000 port does have everything  :100: , thx
Can close this issue I think.
And using decorator way is more like fastapi style.

In general I would agree that using the decorator is neater.
In this case however it means you would have to write all your API endpoints between the app = pc.App(state=State) and app.compile(), and doing that just so we can use the decorator feel counter-productive.


Fixes permissions after osxfuse

Also, adds reboot caveat.
Closes #13631

Thank you for the contribution. It was merged directly as dd77fef61bbde8824cdd777b355a02db1ed07e39 to keep commit history cleaner. Your contribution is still credited to you.


Created responsive privacy policy page and linked it to footer.

Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state “None”]
Fixes:  #1074
Description
Created a responsive privacy policy page with table of content (at left) through which navigation can be done easily.

Type of PR

[x] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
[Attach any relevant screenshots or videos demonstrating the changes. Make sure to attach before & after screenshots in your PR.]
https://github.com/user-attachments/assets/b871f01e-bf7e-4bf0-a79f-07335c97ba98
Checklist:

[x] I have made this change from my own.
[ ] I have taken help from some online resources.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers and screenshots after making the changes.

@PriyaGhosal please review this pr and also assign this pr to me with the necessary labels if you find it worth merging.

@PriyaGhosal please review this pr.

@Palmistry2310 Your pull request has been successfully merged! Don't stop here—continue contributing by addressing more issues and aiming to become a top contributor. Exclusive swag awaits for those who go the extra mile!
Great contribution ! 🎉


Default filename for save?

Great, useful library :) It has the more modern find folder UI too on windows.
One small omission, as far as I can see: there's no way to pass a default filename to the save dialog.  You can provide a default folder, but not a default name to put in the save box.

The default_path argument is supposed to accept a full file path, too, but I realise the Windows implementation has a bug. Thanks for reporting this!

Yeah, I should have mentioned that I tried that already (on Windows) ;-)
Sent from my iPhone

On 7 Nov 2019, at 22:28, Sam Hocevar<EMAIL_ADDRESS>wrote:

The default_path argument is supposed to accept a full file path, too, but I realise the Windows implementation has a bug. Thanks for reporting this!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


New private-distributors membership

Review done with Brandon, about this submission request for OVH Group.

/hold
/lgtm
waiting for committee lazy consensus round until March 12th

@gclem you will need to sign the CLA

/check-cla

/check-cla

/close


Build HIE with cabal via install.hs

Closes #1047
Discovers GHC installations that can be found via System.Directory.findExecutable. Found GHC installations are shown with cabal-ghcs target.
Adapts the target cabal-build and cabal-docs to only install HIE for GHCs that have already been found.
HIE executables are installed to $HOME/.local/bin. The main executable hie will be symlinked to that location, as well as hie-wrapper, while the other executables will be copied. We could also symlink them, but this may cause Problems for Windows. On the other hand, we could also replace the symlinked hie and hie-wrapper with real copies, or wait until the respective flag lands in cabal.
Adds more helpful error messages such as, "GHC not found!".
Blockers
Tested on the systems:

[ ] Windows, does currently not work since cabal new-install does not work for windows, see https://github.com/haskell/cabal/issues/5837
[x] Fedora
[x] MacOS
[x] NixOS

The documentation needs some changes. If someone uses cabal new-build without our smart wrapper, a .ghc.environment file is generated. Almost any tool seems to read that and consequentially, the script install.hs can not be run because its dependencies are not added to the local .ghc.environment file. We can not include a fix for this, like deleting the file if present, in the install.hs since it can not be run at all. Thus, I propose we add this to the FAQ.
Discussion:

Is the cabal target needed for installation via cabal new-build? I removed it for now.
We require that $HOME/.cabal/bin is in the path instead of $HOME/.local/bin in the current implementation. We no longer require $HOME/.cabal/bin to be on the $PATH.

Hmpf, I think stack script changes the path such that the GHC is on the PATH of the global project.
Maybe there is a difference between GHCs installed by stack and those installed from source/package manager?

Cleaning up my dist and dist-newstyle seemed to help, I presume something funny went wrong in the configure step, probably not the fault of the install script.

Mainly because then we know where the locations of the executables are located. It then also has the same behaviour as build.
Moreover, I don't know how else I can obtain the path to the executable

I believe cabal new-install symlinks into ~/.cabal/bin/ by default, but that makes sense in terms of keeping the artefacts consistent with the stack installation

I believe cabal new-install symlinks into ~/.cabal/bin/ by default, but that makes sense in terms of keeping the artefacts consistent with the stack installation

Yes, but I am not sure where it is on windows and also it might break if someone has a custom cabal configuration.

@fendor do i understand correctly that this PR adds\alters cabal targets, while stack targets are unaffected? Also, if those cabal targets aren't properly working on Windows - will user get a clear message about it if he tries to run it on Windows machine?

@Anrock That is right, it adds targets to build HIE via cabal new-build. Stack targets are not affected except that some implementation details have changed.
Regarding windows, yes and no, it will build hie as expected but when trying to install, cabal will terminate with a message that it does not work on windows atm. So, you have the worst of both: It will build and fail just before the finish line.

@fendor borderline acceptable, imo. Could you either hide broken cabal targets or fail them instantly with error message specifically for Windows? If no/too much effort, then LGTM.

@Anrock You are right, I will add a check whether the script is executed on mingw32 and error out accordingly.

@fendor shouldn't it be mingw32 || win32? I'm using stack via cmd.exe instead of mingw mintty and i'm not exatcly sure if in this case host will be reported as mingw32.

I am out of my depth on this one, but if you guys are happy with it, it can merge.

@fendor shouldn't it be mingw32 || win32? I'm using stack via cmd.exe instead of mingw mintty and i'm not exatcly sure if in this case host will be reported as mingw32.

On my windows, I tested it with
stack ghci on cmd and powershell, the result was mingw32
compiled with stack ghc --stack-yaml shake.yaml -- -O2 install.hs; ./install.exe and the result was always reported as mingw32. Not sure if win32 is actually a possible result of System.Info.os

Should show now a nice error message when trying to use one of the cabal targets.

A fitting readme is missing.

I am worried about the first-time user experience with this.  Running the bare command gives a wall of text, with so many options it is not clear what is going on.
$ ./install.hs

Usage:
    stack install.hs <target>

Targets:
    help                      Show help
    cabal                     Makes sure that Cabal the lib is available for cabal-helper-wapper, to speed up project start
    dist                      Creates a tarball containing all the hie binaries
    build                     Builds hie for all supported GHC versions (8.2.1, 8.2.2, 8.4.2, 8.4.3, 8.4.4, 8.6.1, 8.6.2 and 8.6.3)
    build-all                 Builds hie and hoogle databases for all supported GHC versions
    build-docs                Builds the Hoogle database for all supported GHC versions
    test                      Runs hie tests with stack
    hie-8.2.1                 Builds hie for GHC version 8.2.1 only with stack
    hie-8.2.2                 Builds hie for GHC version 8.2.2 only with stack
    hie-8.4.2                 Builds hie for GHC version 8.4.2 only with stack
    hie-8.4.3                 Builds hie for GHC version 8.4.3 only with stack
    hie-8.4.4                 Builds hie for GHC version 8.4.4 only with stack
    hie-8.6.1                 Builds hie for GHC version 8.6.1 only with stack
    hie-8.6.2                 Builds hie for GHC version 8.6.2 only with stack
    hie-8.6.3                 Builds hie for GHC version 8.6.3 only with stack
    build-doc-8.2.1           Builds the Hoogle database for GHC version 8.2.1 only with stack
    build-doc-8.2.2           Builds the Hoogle database for GHC version 8.2.2 only with stack
    build-doc-8.4.2           Builds the Hoogle database for GHC version 8.4.2 only with stack
    build-doc-8.4.3           Builds the Hoogle database for GHC version 8.4.3 only with stack
    build-doc-8.4.4           Builds the Hoogle database for GHC version 8.4.4 only with stack
    build-doc-8.6.1           Builds the Hoogle database for GHC version 8.6.1 only with stack
    build-doc-8.6.2           Builds the Hoogle database for GHC version 8.6.2 only with stack
    build-doc-8.6.3           Builds the Hoogle database for GHC version 8.6.3 only with stack
    cabal-ghcs                Show all GHC versions that can be installed via `cabal-build` and `cabal-build-all`.
    cabal-build               Builds hie with cabal with all installed GHCs. Target `cabal-ghcs` shows all GHC versions that will be installed
    cabal-build-all           Builds hie and hoogle databases for all installed GHC versions with cabal
    cabal-build-docs          Builds the Hoogle database for all installed GHC versions with cabal
    cabal-test                Runs hie tests with cabal
    cabal-hie-8.2.1           Builds hie for GHC version 8.2.1 only with cabal new-build
    cabal-hie-8.2.2           Builds hie for GHC version 8.2.2 only with cabal new-build
    cabal-hie-8.4.2           Builds hie for GHC version 8.4.2 only with cabal new-build
    cabal-hie-8.4.3           Builds hie for GHC version 8.4.3 only with cabal new-build
    cabal-hie-8.4.4           Builds hie for GHC version 8.4.4 only with cabal new-build
    cabal-hie-8.6.1           Builds hie for GHC version 8.6.1 only with cabal new-build
    cabal-hie-8.6.2           Builds hie for GHC version 8.6.2 only with cabal new-build
    cabal-hie-8.6.3           Builds hie for GHC version 8.6.3 only with cabal new-build
    cabal-build-doc-8.2.1     Builds the Hoogle database for GHC version 8.2.1 only with cabal
    cabal-build-doc-8.2.2     Builds the Hoogle database for GHC version 8.2.2 only with cabal
    cabal-build-doc-8.4.2     Builds the Hoogle database for GHC version 8.4.2 only with cabal
    cabal-build-doc-8.4.3     Builds the Hoogle database for GHC version 8.4.3 only with cabal
    cabal-build-doc-8.4.4     Builds the Hoogle database for GHC version 8.4.4 only with cabal
    cabal-build-doc-8.6.1     Builds the Hoogle database for GHC version 8.6.1 only with cabal
    cabal-build-doc-8.6.2     Builds the Hoogle database for GHC version 8.6.2 only with cabal
    cabal-build-doc-8.6.3     Builds the Hoogle database for GHC version 8.6.3 only with cabal
    icu-macos-fix             Fixes icu related problems in MacOS

Build completed in 0:01m

I agree with that, however, in the readme there are simple instructions
what targets do you think are not required?
Or maybe, help shows all targets, while no target just shows a clear overview?

Or maybe, help shows all targets, while no target just shows a clear overview?

This sounds like a good idea.

Introduced short helper message that only shows the commands absolutely necessary, example output:
> stack install.hs  # equal to `stack install.hs short-help` and `stack install.hs all`

Usage:
    stack install.hs <target>

Targets:
    help                      Show help message including all targets
    build                     Builds hie for all supported GHC versions (8.2.1, 8.2.2, 8.4.2, 8.4.3, 8.4.4, 8.6.1, 8.6.2 and 8.6.3)
    build-all                 Builds hie and hoogle databases for all supported GHC versions
    hie-8.6.3                 Builds hie for GHC version 8.6.3 only with stack
    build-doc-8.6.3           Builds the Hoogle database for GHC version 8.6.3 only with stack
    hie-8.4.4                 Builds hie for GHC version 8.4.4 only with stack
    build-doc-8.4.4           Builds the Hoogle database for GHC version 8.4.4 only with stack

    cabal-ghcs                Show all GHC versions that can be installed via `cabal-build` and `cabal-build-all`.
    cabal-build               Builds hie with cabal with all installed GHCs.
    cabal-build-all           Builds hie and hoogle databases for all installed GHC versions with cabal
    cabal-hie-8.6.3           Builds hie for GHC version 8.6.3 only with cabal new-build
    cabal-build-doc-8.6.3     Builds the Hoogle database for GHC version 8.6.3 only with cabal
    cabal-hie-8.4.4           Builds hie for GHC version 8.4.4 only with cabal new-build
    cabal-build-doc-8.4.4     Builds the Hoogle database for GHC version 8.4.4 only with cabal

Build completed in 0.00s

In my opinion, ready to merge.
I would ask for a quick proof read of the changed README.

LGTM, will land it once CI completes

Do I understand it correctly that this PR show to make it possible to install HIE without stack? Because I tried to do that on my system (x86_64 linux, w/o stack, with ghc 8.6.3) and it failed. Specifically, I compiled install.hs with cabal, and then ran ./install cabal-hie-8.6.3, but it failed after a couple of minutes with the following error message:
# stack (for cabal)
Error when running Shake build system:
  at want, called at src/Development/Shake/Internal/Args.hs:83:69 in shake-0.17.6-2Y524cW7xdJLdvFCU0NUxw:Development.Shake.Internal.Args
* Depends on: cabal-hie-8.6.3
  at need, called at install.hs:121:9 in main:Main
* Depends on: cabal
* Raised the exception:
stack: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory)

which indicates that it needs stack to continue.

No, it means you can build hie with cabal, we still require stack to ensure that cabal is installed and to know the stack path --local-bin location. It is one of the design goals of install.hs to only require stack and git.


[CBR-255] TxMeta persistent storage

Description
This PR adds support for storing the transaction metadata (cfr. "Tracking Metadata" section of the Wallet Spec) on disk but outside acid-state, due to the fact such data is unbounded (in size) and as such it won't eventually all fit into main memory.
The concrete storage implementation is completely hidden via an opaque interface (i.e. via an Handle pattern) and the persistence of choice was Sqlite, accessed via the excellent beam library.
@edsko Feel free to review this already, as I expect lots of massaging to make it mergeable against latest develop and in order to please the CI (we are introducing a toolchain dependency on Sqlite, so I think this has all kinds of implications I will need to check with devops).
Linked issue
https://iohk.myjetbrains.com/youtrack/issue/CBR-255
Type of change

[~] 🐞 Bug fix (non-breaking change which fixes an issue)
[x] 🛠 New feature (non-breaking change which adds functionality)
[~] ⚠ Breaking change (fix or feature that would cause existing functionality to change)
[~] 🏭 Refactoring that does not change existing functionality but does improve things like code readability, structure etc
[~] 🔨 New or improved tests for existing code
[~] ⛑ git-flow chore (backport, hotfix, etc)

Developer checklist

[x] I have read the style guide document, and my code follows the code style of this project.
[x] If my code deals with exceptions, it follows the guidelines.
[x] I have updated any documentation accordingly, if needed. Documentation changes can be reflected in opening a PR on cardanodocs.com, amending the inline Haddock comments, any relevant README file or one of the document listed in the docs directory.

Testing checklist

[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

QA Steps

Screenshots (if available)

Thanks for taking the time out of your day to review this PR, @parsonsmatt !
All in all they are all fair review points. I will need to do some massaging with CI and the windows-specific deps first, but then I will tackle your comments. Thanks!

Be careful of not accidentally having only seconds resolution. We surely want more than that, otherwise we may have to worry about rounding issues.

@k0001 What you say is surely true and a great review point, but I think (@edsko to confirm or disprove) that for metadata tracking (and for the API history tracking alike) we don't need anything more precise than seconds -- I cannot think of any substantial use case where we might need to distinguish between a Tx arriving into the system with milliseconds or microseconds precision.
Furthermore, there is no FromField instance for (a,b) (and quite rightly so), therefore a bit more massaging would be needed to store the time serialised that way, to which I might simply save myself the hassle and go with the less inefficient textual representation 😁
In my local branch I have amended that instance to use Word64 as per @parsonsmatt 's suggestion which I think strikes the sweet spot between efficiency, requirements and ease of implementation.
My 2 cents anyway :)

Ok, a bit of report from the trenches on why this PR is not building. In a nutshell, beam-sqlite depends on Win32 >= 2.4, but we are stuck in using 2.3.x due to two major factors:

It's what LTS 9.1 ships;
Win32 has all kind of reverse deps, including core packages like process, happy (I believe) etc;

In a nutshell the only way out I see is to try manually backporting some Win32 >= 2.4 features into a forked version of beam-sqlite, in order to remove or make this dependency more lenient.
On top of that my specs are failing on Hydra, but that is a separate problem. :trollface:

@edsko @parsonsmatt @k0001 @cleverca22 Ok, I have tried to wrestle a little bit with this over the weekend by weeding out the deps and by changing the cardano-integration-test to a shorter name to circumvent the max_path limitation on Windows, but this is still borked. Not only on Appveyor but also on Darwin, despite the use of enabledSharedExecutable = false which should have fixed the infamous linker bug, but apparently it hasn't.
For now, I'm parking this PR and declaring defeat, as this turned out to be a huge time sink and I need to move to other tickets to get the velocity going.
Said that, it's quite worrisome to me that we are running so close to the edge of the tar pit: I can imagine that if not me, somebody else will soon hit this limit, as cardano seems to have incorporated quite a few dependencies in a katamary damacy fashion.
I think the path forward is the following:

Park this PR here for a bit, as the part of the system it delivers is largely independent from the rest of the data layer, but will eventually block @k0001 in his migration task;

Add a ticket to CBR-277 to track the fact we need to merge this PR;

Have a valiant DevOps help us making this mergeable (this also reminds me our squad doesn't have a dedicated devops engineer assigned, but it would be nice to have, for situations like these).

Outstanding problems (as a checklist) which prevents this PR to witness its full glory:

[ ] AppVeyor fails due to max_path limitation (see this YT ticket);

[ ] Build on Darwin (via Hydra) fails due to linker space limit exceeded (likely due to too many deps);

[ ] We are using a forked version of Win32 to please AppVeyor. The proper fix is to switch to LTS-11.2, which is in the works and @avieth has an open patch for that.

@cleverca22 @rvl Sigh, tried to rebase against develop but I think I have done more harm than good, and needless to say the linker bug in Darwin is still present.
Do you guys have any cunning plan on how we could escape this conundrum? Ideally we should revive this script and start thinking about another round of pruning, I suppose..

@edsko , look, progress! Only AppVeyor to go 😉

After speaking with @erikd , it seems in our brave new world we are temporarily overriding the Windows CI check as it's currently borked but we cannot afford to have development grind to an halt due to it.
@jcmincke , @edsko , little heads up that I'm going to merge this PR very soon (or any other I'm told) overriding CI, until we sort out the CI woes. If you want me to refrain, just shout 😀

Drat, a conflict again, I should have merged yesterday!


Is lv_port_windows production ready?

I see in the roadmap that there are some items not completed yet, and so I wonder if this porting to Windows is "production ready" or in a beta stage.
Moreover, is it possible using it with VSCode and a modern supported toolchain (i.e. MinGW)?
Thanks

This project is in the beta stage.
Currently, you can't use it with VSCode and MinGW. But I will consider your suggestion.
Kenji Mouri


[mesheryctl] fix Bug: system reset on stable channel breaks if no version is specified

Description
This PR fixes #2366

Added a helper function GetLatestStableReleaseTag in mesheryctl/pkg/utils/helpers.go to fetch latest stable release tag using GitHub API
This is later used by resetMesheryConfig in case no version is specified while using stable channel

Notes for Reviewers
Should I rather move the GetLatestStableReleaseTag logic inside the resetMesheryConfig itself? (will have to import additional packages in reset.go which are already imported in helpers.go)
Signed commits

[x] Yes, I signed my commits.

Should I rather move the GetLatestStableReleaseTag logic inside the resetMesheryConfig itself? (will have to import additional packages in reset.go which are already imported in helpers.go)

We can have this function in the helpers.go file itself. We will need to add the context support and platform support for some more commands and it would be reused a lot.

Nice work @aneeshnema . The changes are looking great.


Update .gitmodules

Update source of the eigen repo.

Hi @yanxiangyi - thank you for the update. However, we've actually moved all of the source code over to https://github.com/pytorch/pytorch. Things should be updated over there.


Disables the check of min masternode age between blocks 650001 and 655000

All seems ok. I just add some "beauty make up" :)
We can merge.


Fix hassio command timeout

Description:
With the slower devices, like my Raspberry Pi 1 Model B, 300 seconds (5 minutes) are not enough to check homeassistant configuration
core-ssh:~# time hassio ha check
ok

real	5m37.336s
user	0m0.048s
sys	0m0.016s

Related issue (if applicable): fixes #17177
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#<home-assistant.io PR number goes here>
Example entry for configuration.yaml (if applicable):
hassio:
  check_timeout: 600

Checklist:

[ ] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

User configuration option is the wrong solution to most problems. Because you're not solving anything, you're just outsourcing responsibility.
CC @pvizeli

You're right, especially because if don't configured the problem persists.
I thought about two possible ways to solve it:

By increase the time for all device and show a warning if call exceeds 5 minutes
Or increase timeout if the device is mark as slow

It could be the right solution?

You can fix add a timeout of 600 for this command


RxView scrollChangeEvents for api lower than M

For now scroll change events are supported only for @TargetApi(M).
 @TargetApi(M)
  @CheckResult @NonNull
  public static Observable<ViewScrollChangeEvent> scrollChangeEvents(@NonNull View view) {
    checkNotNull(view, "view == null");
    return Observable.create(new ViewScrollChangeEventOnSubscribe(view));
  }

I write simple solution for this:
  public static Observable<ViewScrollChangeEvent> scrollChangeEvents(View view) {
        checkNotNull(view, "view == null");
        return Observable.create(new CustomScrollChangeEventOnSubscribe(view));
    }

final class CustomScrollChangeEventOnSubscribe implements Observable.OnSubscribe<ViewScrollChangeEvent> {
    private final View view;
    private ViewTreeObserver.OnScrollChangedListener onScrollChangedListener;
    private ViewTreeObserver viewTreeObserver;

    CustomScrollChangeEventOnSubscribe(View view) {
        this.view = view;
    }

    @Override
    public void call(final Subscriber<? super ViewScrollChangeEvent> subscriber) {
        checkUiThread();

        ViewScrollChangeEventListener listener = new ViewScrollChangeEventListener() {
            @Override
            public void onViewScrollChangeEvent(ViewScrollChangeEvent viewScrollChangeEvent) {
                if (!subscriber.isUnsubscribed()) {
                    subscriber.onNext(viewScrollChangeEvent);
                }
            }
        };
        setScrollTouchListener(listener, view);

        subscriber.add(new MainThreadSubscription() {
            @Override
            protected void onUnsubscribe() {
                if (checkTreeObserver()) {
                    viewTreeObserver.removeOnScrollChangedListener(onScrollChangedListener);
                }
            }
        });
    }

    private void setScrollTouchListener(final ViewScrollChangeEventListener viewScrollChangeEventListener, final View viewToObserve) {
        onScrollChangedListener = new ViewTreeObserver.OnScrollChangedListener() {
            private int oldScrollX = 0;
            private int oldScrollY = 0;

            @Override
            public void onScrollChanged() {
                if (viewToObserve.getScrollX() != oldScrollX || viewToObserve.getScrollY() != oldScrollY) {
                    viewScrollChangeEventListener.onViewScrollChangeEvent(ViewScrollChangeEvent.create(viewToObserve, viewToObserve.getScrollX(), viewToObserve.getScrollY(), oldScrollX, oldScrollY));
                    oldScrollX = viewToObserve.getScrollX();
                    oldScrollY = viewToObserve.getScrollY();
                }
            }
        };
        viewTreeObserver = viewToObserve.getViewTreeObserver();
        if (checkTreeObserver()) {
            viewTreeObserver.addOnScrollChangedListener(onScrollChangedListener);
        }
    }

    private boolean checkTreeObserver() {
        return viewTreeObserver != null && viewTreeObserver.isAlive();
    }

    interface ViewScrollChangeEventListener {
        void onViewScrollChangeEvent(ViewScrollChangeEvent viewScrollChangeEvent);
    }

}

Maybe it can be added to library

Send a PR if you like.
On Mon, Dec 5, 2016, 10:09 AM MickSparrow<EMAIL_ADDRESS>wrote:

For now scroll change events are supported only for @TargetApi(M).
@TargetApi(M)
@CheckResult @NonNull
public static Observable scrollChangeEvents(@NonNull View view) {
checkNotNull(view, "view == null");
return Observable.create(new ViewScrollChangeEventOnSubscribe(view));
}
I write simple solution for this:
public static Observable scrollChangeEvents(View view) {
checkNotNull(view, "view == null");
return Observable.create(new CustomScrollChangeEventOnSubscribe(view));
}
final class CustomScrollChangeEventOnSubscribe implements Observable.OnSubscribe {
private final View view;
private ViewTreeObserver.OnScrollChangedListener onScrollChangedListener;
private ViewTreeObserver viewTreeObserver;
CustomScrollChangeEventOnSubscribe(View view) {
    this.view = view;
}

@Override
public void call(final Subscriber<? super ViewScrollChangeEvent> subscriber) {
    checkUiThread();

    ViewScrollChangeEventListener listener = new ViewScrollChangeEventListener() {
        @Override
        public void onViewScrollChangeEvent(ViewScrollChangeEvent viewScrollChangeEvent) {
            if (!subscriber.isUnsubscribed()) {
                subscriber.onNext(viewScrollChangeEvent);
            }
        }
    };
    setScrollTouchListener(listener, view);

    subscriber.add(new MainThreadSubscription() {
        @Override
        protected void onUnsubscribe() {
            if (checkTreeObserver()) {
                viewTreeObserver.removeOnScrollChangedListener(onScrollChangedListener);
            }
        }
    });
}

private void setScrollTouchListener(final ViewScrollChangeEventListener viewScrollChangeEventListener, final View viewToObserve) {
    onScrollChangedListener = new ViewTreeObserver.OnScrollChangedListener() {
        private int oldScrollX = 0;
        private int oldScrollY = 0;

        @Override
        public void onScrollChanged() {
            if (viewToObserve.getScrollX() != oldScrollX || viewToObserve.getScrollY() != oldScrollY) {
                viewScrollChangeEventListener.onViewScrollChangeEvent(ViewScrollChangeEvent.create(viewToObserve, viewToObserve.getScrollX(), viewToObserve.getScrollY(), oldScrollX, oldScrollY));
                oldScrollX = viewToObserve.getScrollX();
                oldScrollY = viewToObserve.getScrollY();
            }
        }
    };
    viewTreeObserver = viewToObserve.getViewTreeObserver();
    if (checkTreeObserver()) {
        viewTreeObserver.addOnScrollChangedListener(onScrollChangedListener);
    }
}

private boolean checkTreeObserver() {
    return viewTreeObserver != null && viewTreeObserver.isAlive();
}

interface ViewScrollChangeEventListener {
    void onViewScrollChangeEvent(ViewScrollChangeEvent viewScrollChangeEvent);
}

}
Maybe it can be added to library
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/JakeWharton/RxBinding/issues/315, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEfX_HfC5e7XDI0kb76HPgTiJ8huiks5rFCk2gaJpZM4LEVcA
.

OK, this solution is not passing test, but passes "eye test", so I must check it out, and when I'll send PR.

I tested my solution on some devices with api level from 16 to 23 and its working.
But this fails test because ViewTreeObserver.OnScrollChangedListener() is not calling in test enviroment.
So I don't know what to do because I have no time to investigate tests environment.

In test case, "view" doesn't attach any contexts. So "view.getViewTreeObserver()" returns "mFloatingTreeObserver". It doesn't invoke ViewTreeObserver.dispatchOnScrollChanged
private final View view = new View(context);
https://github.com/JakeWharton/RxBinding/blob/master/rxbinding/src/androidTest/java/com/jakewharton/rxbinding2/view/RxViewTest.java#L41
public ViewTreeObserver getViewTreeObserver() {   | if (mAttachInfo != null) {   | return mAttachInfo.mTreeObserver;   | }   | if (mFloatingTreeObserver == null) {   | mFloatingTreeObserver = new ViewTreeObserver(mContext);   | }   | return mFloatingTreeObserver;   | }

https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/View.java#21287
So I added new test code RxViewScrollTest.java. It tests RxView.scrollChangeEvents with view attached a activity context.
"setContentView(view)" solves this problem
https://github.com/kujyp/RxBinding/commit/71a86293c7542f918708941882231405e3b5d3d4#diff-2fa09177d9d6ae1c0204b88a5b808cc7R18

keep writing.

@JakeWharton
https://github.com/JakeWharton/RxBinding/pull/433/commits/5339796c09d9d28fd521a3e690fb6daa447e218a passed the ci pipeline.
But I make small changes, then https://github.com/JakeWharton/RxBinding/pull/433/commits/03685a01e45507eeae7bf06e44529337d173a322 failed.
I have no idea why it failed with the Classes that I didn't touch.
com.jakewharton.rxbinding2.view.RxViewSystemUiVisibilityTest > systemUiVisibilityChanges[test(AVD) - 4.3.1] FAILED
com.jakewharton.rxbinding2.view.RxViewSystemUiVisibilityTest > systemUiVisibilityChanges[test(AVD) - 4.3.1] FAILED
com.jakewharton.rxbinding2.widget.RxAutoCompleteTextViewTest > itemClickEvents[test(AVD) - 4.3.1] FAILED
com.jakewharton.rxbinding2.widget.RxRatingBarTest > ratingChangeEvents[test(AVD) - 4.3.1] FAILED
com.jakewharton.rxbinding2.widget.RxSeekBarTest > changeEvents[test(AVD) - 4.3.1] FAILED
...
https://travis-ci.org/JakeWharton/RxBinding/jobs/345882826#L1667

It seems to be flaky tests, so I just leave it failed.
I'm sorry for pushing empty commits. I need some feedbacks that I didn't do wrong.


allow admin to add without voting

As a list curator, I like to add top releases at least weekly. Sometimes it may be 50 or 100 tracks I want in rotation but don't want to block or force other voters. i just want them in rotation.
As a work-around in Soundrop, I would often add late at night with less people in the room and then shuffle when there weren't any votes. This would remove my votes for the 50 tracks.
A solution example might be for an admin to hold ctrl or shift when dragging and dropping to add without voting.

Admins can essentially do this now using new commands, using /topup spotify:playlist:uri - that will add 50 random tracks from that playlist without voting.  Also admin can add all the tracks by drag drop, then /shuffle to remove votes.


An almost non-issue

Hi, my list of "saved searches" grew so big that it does not fit the screen anymore. Is there any way to let the list grow while keeping it in-screen? A scroll bar? Sub-lists? Thanks!

Hi, sorry for a super late comment. Although I can not say when, I will fix this issue when I have a chance to change the code. From the options you listed, I prefer to use sublists.

Aaron has left OmegaT development so if you're interested in taking over improvements of your code in OmegaT, you are very welcome.


Adding tests

Hi! I'm seriously looking at this library, and I am ready to invest some time in improving it. My very first question would be: are you planning on maintaining it? If I do a couple of PR, will you consider them?
The very first thing I would need before changing any code is having a suite of tests. I could create a few basic tests (text with UTF characters, special encoding, etc.) but for this, I would potentially need to create a solution, and depend on something like NUnit.
What do you think? Would you accept a PR that adds tests and a solution? If not, are you open to an alternative?

I sent you a PM on gitter.  want to chat with you there about this and the other issues you opened or commented on.

Sure, I won't be able to chat right now, but if you're curious: https://github.com/christianrondeau/lz-string-csharp
I tried to include every fork's changes, but I didn't put too much thoughts in pulling back everything yet. I'll try to reach out tomorrow :)

Thanks!


pull request for e2e test at 12/28/2016 14:26:07

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


self is nil on iPhone

Hi,
I'm trying out Starscream 0.9.7 (Swift 1.2) for iOS using Cocoa Pods.
When connecting right after initialising the websocket object, the self? inside the connect()-function is nil and so createHTTPRequest() doesn't get called so no websocket connecting is made.
var socket: WebSocket!

override func viewDidLoad() {
    super.viewDidLoad()
    // Do any additional setup after loading the view, typically from a nib.

    socket = WebSocket(url: NSURL(scheme: "ws", host: "<IP_ADDRESS>:3001", path: "/")!)
    socket.delegate = self
    socket.connect()
}

However, when connecting some time after the websocket object is created, self? is not nil and the socket connects.
var socket: WebSocket!

override func viewDidLoad() {
    super.viewDidLoad()
    // Do any additional setup after loading the view, typically from a nib.

    socket = WebSocket(url: NSURL(scheme: "ws", host: "<IP_ADDRESS>:3001", path: "/")!)
    socket.delegate = self
}

@IBAction func buttonConnect_touchUp(sender: AnyObject) {
    socket.connect()
}

Also, when adding a println(self) to the connect()-function, the problem is solved:
public func connect() {
    if isCreated {
        return
    }
    dispatch_async(queue,{ [weak self] in
        self?.didDisconnect = false
        println(self)
        dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0), { [weak self] in
            self?.isCreated = true
            self?.createHTTPRequest()
            self?.isCreated = false
        })
    })
}

Could this be another timing issue?
Grtz,
Sam

Yeah I think that might have been an issue. Looking at the latest code we change the connect method:
https://github.com/daltoniam/Starscream/blob/master/WebSocket.swift#L127
Might want to try changing it to that and see if that resolves the issue.

Jup, that fixes it!
Thanks

Cool. Great to hear.