Compare final record counts between GNAF and Admin Bdy versions for QA

Need to compare the new and previous gnaf.qa and admin_bdy.qa tables to qa the results and get record count differences

In August 2021 Release


Issue with IP Addresses after a node rebuild

Version <IP_ADDRESS>
After a rebuild of a node with Kubernetes/Docker we se a strange behavior that causes Elasticsearch node to go dead.
If you look at the two outputs, nodetool status IS CORRECT. <IP_ADDRESS> is the new node.
Nodetool status:
root@elassandra-5:/opt/elassandra-<IP_ADDRESS>/conf# nodetool status
Datacenter: DC1
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address         Load       Tokens       Owns    Host ID                               Rack
UN  <IP_ADDRESS>   616.91 MiB  8            ?       c4366c6f-7cdc-4dc2-8a02-75511c393d30  Rack1
UN  <IP_ADDRESS>  532.88 MiB  8            ?       9796b736-e0d2-4a11-88cd-62bb9bc50ebe  Rack1
UN  <IP_ADDRESS>     287.17 MiB  8            ?       414c4363-e3ae-453a-bc0e-4948135ce731  Rack1
UN  <IP_ADDRESS>  709.58 MiB  8            ?       ab90840a-5ed7-45d7-b816-6545f5103ac5  Rack1
UN  <IP_ADDRESS>  515.25 MiB  8            ?       d76a5242-4d12-41e8-a526-7724b57dbc31  Rack1
UN  <IP_ADDRESS>  719.57 MiB  8            ?       62891ec9-7de6-4d55-b2cb-7eae97ed2957  Rack1
Now looking at the cluster status you can see <IP_ADDRESS>.  This IP ADDRESS does not exist in the cluster.  I can see from the logs that it stops Gossiping due to this.  I am not sure how/why to get them in sync.
I just show the cluster state here:
macbook-pro-2:~ liottar$ curl http://inception.cevalogistics.com:9200/_cluster/state?pretty=true
{
"cluster_name" : "Cassandra",
"version" : 80,
"state_uuid" : "18RU9rExTlCzH9gn6dUo5Q",
"master_node" : "62891ec9-7de6-4d55-b2cb-7eae97ed2957",
"blocks" : { },
"nodes" : {
"9796b736-e0d2-4a11-88cd-62bb9bc50ebe" : {
"name" : "<IP_ADDRESS>",
"status" : "ALIVE",
"ephemeral_id" : "9796b736-e0d2-4a11-88cd-62bb9bc50ebe",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
},
"d76a5242-4d12-41e8-a526-7724b57dbc31" : {
"name" : "<IP_ADDRESS>",
"status" : "ALIVE",
"ephemeral_id" : "d76a5242-4d12-41e8-a526-7724b57dbc31",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
},
"62891ec9-7de6-4d55-b2cb-7eae97ed2957" : {
"name" : "<IP_ADDRESS>",
"status" : "ALIVE",
"ephemeral_id" : "62891ec9-7de6-4d55-b2cb-7eae97ed2957",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
},
"ab90840a-5ed7-45d7-b816-6545f5103ac5" : {
"name" : "<IP_ADDRESS>",
"status" : "ALIVE",
"ephemeral_id" : "ab90840a-5ed7-45d7-b816-6545f5103ac5",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
},
"e271fb65-2836-4421-8292-77fcc3890012" : {
"name" : "<IP_ADDRESS>",
"status" : "DEAD",
"ephemeral_id" : "e271fb65-2836-4421-8292-77fcc3890012",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
},
"c4366c6f-7cdc-4dc2-8a02-75511c393d30" : {
"name" : "<IP_ADDRESS>",
"status" : "ALIVE",
"ephemeral_id" : "c4366c6f-7cdc-4dc2-8a02-75511c393d30",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
}
},
Partial Log:
2018-05-01 20:43:15,742 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>334882293.  Ignoring /<IP_ADDRESS>
2018-05-01 20:43:15,822 INFO  [GossipStage:1] org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1034) InetAddress /<IP_ADDRESS> is now DOWN
2018-05-01 20:43:25,717 INFO  [GossipStage:1] org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1055) Node /<IP_ADDRESS> is now part of the cluster
2018-05-01 20:43:25,726 WARN  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2342) Not updating host ID 414c4363-e3ae-453a-bc0e-4948135ce731 for /<IP_ADDRESS> because it's mine
2018-05-01 20:43:25,730 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token -2906258939937529727.  Ignoring /<IP_ADDRESS>
2018-05-01 20:43:25,731 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token -8362130585556172891.  Ignoring /<IP_ADDRESS>
2018-05-01 20:43:25,734 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token -959123631124296270.  Ignoring /<IP_ADDRESS>
2018-05-01 20:43:25,736 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>066165006.  Ignoring /<IP_ADDRESS>
2018-05-01 20:43:25,737 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>489195507.  Ignoring /<IP_ADDRESS>
2018-05-01 20:43:25,739 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>600102763.  Ignoring /<IP_ADDRESS>
2018-05-01 20:43:25,743 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>178346392.  Ignoring /<IP_ADDRESS>
2018-05-01 20:43:25,748 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>334882293.  Ignoring /<IP_ADDRESS>
2018-05-01 20:43:25,819 INFO  [GossipStage:1] org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1034) InetAddress /<IP_ADDRESS> is now DOWN
2018-05-01 20:44:17,316 INFO  [GossipTasks:1] org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:812) FatClient /<IP_ADDRESS> has been silent for 30000ms, removing from gossip
2018-05-01 20:44:27,322 INFO  [GossipTasks:1] org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:812) FatClient /<IP_ADDRESS> has been silent for 30000ms, removing from gossip
2018-05-01 20:45:18,941 INFO  [GossipStage:1] org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1055) Node /<IP_ADDRESS> is now part of the cluster
2018-05-01 20:45:18,944 WARN  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2342) Not updating host ID 414c4363-e3ae-453a-bc0e-4948135ce731 for /<IP_ADDRESS> because it's mine
2018-05-01 20:45:18,944 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token -2906258939937529727.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:18,944 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token -8362130585556172891.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:18,959 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token -959123631124296270.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:18,962 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>066165006.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:18,967 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>489195507.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:18,971 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>600102763.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:18,976 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>178346392.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:18,978 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>334882293.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:19,048 INFO  [GossipStage:1] org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1034) InetAddress /<IP_ADDRESS> is now DOWN
2018-05-01 20:45:19,051 INFO  [GossipStage:1] org.apache.cassandra.utils.NoSpamLogger$NoSpamLogStatement.log(NoSpamLogger.java:91) Maximum memory usage reached (512.000MiB), cannot allocate chunk of 1.000MiB
2018-05-01 20:45:28,070 INFO  [GossipStage:1] org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1055) Node /<IP_ADDRESS> is now part of the cluster
2018-05-01 20:45:28,129 WARN  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2342) Not updating host ID 414c4363-e3ae-453a-bc0e-4948135ce731 for /<IP_ADDRESS> because it's mine
2018-05-01 20:45:28,133 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token -2906258939937529727.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:28,135 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token -8362130585556172891.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:28,137 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token -959123631124296270.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:28,137 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>066165006.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:28,138 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>489195507.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:28,140 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>600102763.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:28,142 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>178346392.  Ignoring /<IP_ADDRESS>
2018-05-01 20:45:28,142 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>334882293.  Ignoring /<IP_ADDRESS>

Hello.  I can make this problem happen.
I have two nodes with the same issue now.
This is the latest....
{
"cluster_name" : "Cassandra",
"nodes" : {
"62891ec9-7de6-4d55-b2cb-7eae97ed2957" : {
"name" : "<IP_ADDRESS>",
"status" : "DEAD",
"ephemeral_id" : "62891ec9-7de6-4d55-b2cb-7eae97ed2957",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
},
"d76a5242-4d12-41e8-a526-7724b57dbc31" : {
"name" : "<IP_ADDRESS>",
"status" : "ALIVE",
"ephemeral_id" : "d76a5242-4d12-41e8-a526-7724b57dbc31",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
},
"ab90840a-5ed7-45d7-b816-6545f5103ac5" : {
"name" : "<IP_ADDRESS>",
"status" : "ALIVE",
"ephemeral_id" : "ab90840a-5ed7-45d7-b816-6545f5103ac5",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
},
"414c4363-e3ae-453a-bc0e-4948135ce731" : {
"name" : "<IP_ADDRESS>",
"status" : "DEAD",
"ephemeral_id" : "414c4363-e3ae-453a-bc0e-4948135ce731",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
},
"9796b736-e0d2-4a11-88cd-62bb9bc50ebe" : {
"name" : "<IP_ADDRESS>",
"status" : "ALIVE",
"ephemeral_id" : "9796b736-e0d2-4a11-88cd-62bb9bc50ebe",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
},
"c4366c6f-7cdc-4dc2-8a02-75511c393d30" : {
"name" : "<IP_ADDRESS>",
"status" : "ALIVE",
"ephemeral_id" : "c4366c6f-7cdc-4dc2-8a02-75511c393d30",
"transport_address" : "<IP_ADDRESS>:9300",
"attributes" : {
"rack" : "Rack1",
"dc" : "DC1"
}
}
}
}
Cassandra Log:
/<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>379969757.  Ignoring /<IP_ADDRESS>
2018-05-02 11:44:11,584 INFO  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2400) Nodes /<IP_ADDRESS> and /<IP_ADDRESS> have the same token<PHONE_NUMBER>812791023.  Ignoring /<IP_ADDRESS>
2018-05-02 11:44:11,791 INFO  [GossipStage:1] org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1034) InetAddress /<IP_ADDRESS> is now DOWN
2018-05-02 11:44:13,456 INFO  [GossipTasks:1] org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:812) FatClient /<IP_ADDRESS> has been silent for 30000ms, removing from gossip
2018-05-02 11:45:13,500 INFO  [GossipTasks:1] org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:812) FatClient /<IP_ADDRESS> has been silent for 30000ms, removing from gossip
2018-05-02 11:45:13,603 INFO  [GossipStage:1] org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:1055) Node /<IP_ADDRESS> is now part of the cluster
2018-05-02 11:45:13,624 WARN  [GossipStage:1] org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2342) Not

As you see, changing the IP address of a casandra node is not possible.
See this link about running cassandra/docker https://docs.docker.com/samples/library/cassandra/#start-a-cassandra-server-instance.

Vincent,
Actually, I got it to work.  I believe if I had first removed the old node from Cassandra before starting the new one it would have been OK.
I completely deleted the config from Kubernetes and then reapplied it being careful not to remove the storage.  This worked perfect.  My nodes are all happy now.  I tested that multiple times.
Best regards,
Bob Liotta
SVP IT Enterprise Architect
CEVA Logistics / 10751 Deerwood Park, Blvd, Jacksonville, FL 32256 / www.cevalogistics.comhttp://www.cevalogistics.com
O: +1<PHONE_NUMBER> / E: robert.liotta<EMAIL_ADDRESS>Making business flow
From: Vincent Royer<EMAIL_ADDRESS>Reply-To: strapdata/elassandra<EMAIL_ADDRESS>Date: Friday, May 11, 2018 at 4:40 AM
To: strapdata/elassandra<EMAIL_ADDRESS>Cc: "Liotta, Robert"<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [strapdata/elassandra] Issue with IP Addresses after a node rebuild (#189)
As you see, changing the IP address of a casandra node is not possible.
See this link about running cassandra/docker https://docs.docker.com/samples/library/cassandra/#start-a-cassandra-server-instance.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/strapdata/elassandra/issues/189#issuecomment-388300603, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQ-uq4trqw7M-bplYLAerfdorJuhWhbbks5txU54gaJpZM4TuiiH.
NVOCC Services are provided by CEVA as agents for and on behalf of Pyramid Lines Limited trading as Pyramid Lines.
This e-mail message is intended for the above named recipient(s) only. It may contain confidential information that is privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail by error, please immediately notify the sender by replying to this e-mail and deleting the message including any attachment(s) from your system. Thank you in advance for your cooperation and assistance. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.


"dlls_setup.sh" not executable and with too generic a name

I just uploaded a PKGBUILD for dxvk and noticed  what the title says.
It's easily fixable from the packaging point of view, but i think I'd be better to just do it upstream, i.e., set the executable bit on the script and rename it to something like "dxvk_dlls_setup.sh", to make it evident that it's a script belonging to dxvk.
What do you think?
If I weren't completely unfamiliar with meson, I'd be submitting a pull request ;)

Resolved in 8f134bafcfe9136f924df2ae1d2946e46b1b7795.
As for packaging, the setup scripts are required to be in the same location as the DLLs so that they can be used for downloadable binary releases as well. It is however possible to create symlinks to the scripts in /usr/bin if you absolutely want to do that.

That's just what I've done for the AUR package.
Now it installs both the 32 and 64 bit versions, under /usr/local/dxvk/[w32,w64], and I symlink each setup script to /usr/local/bin as setup_dxvk32 and setup_dxvk64, respectively.
But I agree with Raffarti that maybe the name would be better as "dxvk_setup" rather than "setup_dxvk", easier to find and for autocomplete.

really local?
please read:
https://wiki.archlinux.org/index.php/MinGW_package_guidelines#Packaging

I think @doitsujin meant that since you have to symlink it anyway, you can change the name to whatever you please as well (e.g. dxvk_setup and dxvk_setup32)

@Thaodan
If you want to discuss about my packaging choices, I think it'd be better to do so in the package's AUR page:
https://aur.archlinux.org/packages/dxvk-git/
Having said that... dxvk is not a package for a mingw64 cross-compiling environment, so I don't see how would what you link to apply.

ok, but anyway /usr/local is not for pkgs.


create translate:table artisan command

we can create the country_translations migration using translate:table artisan command like this :
php artisan translate:table Country

it will create full translate migration file :
Schema::create('country_translations', function(Blueprint $table)
{
    $table->increments('id');
    $table->integer('country_id')->unsigned();

    $table->string('name');

    $table->string('locale')->index();
    $table->unique(['country_id','locale']);
    $table->foreign('country_id')->references('id')->on('countries')->onDelete('cascade');
});

Good idea - an option like: --fields=name:string;foobar:integer would be good.
But this will also help, but I'm not 100% if the tablename generator works in all situations!?

@Gummibeer Certainly the table name generate in all situations you can see the source code in the new pull request https://github.com/dimsav/laravel-translatable/pull/381/commits/54c694a3e3d05eff03dcbc7ffe84cd652a4a44e1#diff-914175b570e8409c8ca1e823f8b1048cR85


Documentation in Chinese language

Hi there, I've translated the MLeap documentation into Simplified Chinese, hope it can help more users from China. :D
GitBook Link:  https://mleap.ihainan.me/
GitHub Repo:  https://github.com/ihainan/mleap-docs

Thank you, that's amazing! I will close this issue for now, as it's not really an issue per se. Thanks again!


UP-4771: Label radio buttons in User Locales Selector Portlet - rel-4-3-patches

https://issues.jasig.org/browse/UP-4771
Issue
This radio input element does not have a name available to an accessibility API. Valid names are: label element, title attribute.
Code Snippet
<input type="radio" name="locale" value="en_US">

...all radio button instances.
label element (either with a "for" attribute or wrapped around the form field), or "title", "aria-label" or "aria-labelledby" attributes as appropriate.
When a form control does not have a name exposed to assistive technologies, users will not be able to identify the purpose of the form control. The name can be provided in multiple ways, including the label element. Other options include use of the title attribute and aria-label which are used to directly provide text that is used for the accessibility name or aria-labelledby which indicates an association with other text on a page that is providing the name. Button controls can have a name assigned in other ways, as indicated below, but in certain situations may require use of label, title, aria-label, or aria-labelledby.
Code Snippet
<input type="radio" name="locale" value="en_US">

...all radio button instances.
Resolution
Add <label> for <input type="radio"/>

Coverage decreased (-0.002%) to 22.869% when pulling 48e44ff615d0f32b43564a1381f360f2fffa95b6 on ChristianMurphy:UP-4771-user-locales-wcag-rel-4-3 into e6b4afdd506529d90275b783e859c6be70f204ab on Jasig:rel-4-3-patches.


Better error reporting.

I am still seeing an error with 0.4.11 in my environment.  I had to add some code figure out what error Scanner.allocScratch was returning, since at the moment it simply throws an OutOfMemory error regardless of the error code.  The actual error I am seeing is HS_DB_VERSION_ERROR, which is returned by dbIsValid in hyperscan, which is called by hs_alloc_scratch.  I need to figure out why the database appears corrupted.

That looks great, thank you!


SyntaxError: Expected "\#", "\u", "\{", "\}", "{", [^{}\\0-\x1F \t\n\r], end of input or whitespace but "\" found.

When a user navigates to a route with query parameter ending with a backslash , the above syntax error will be thrown.
eg. /search?query=test\ will throw the error.
This will happen both on the front end and backend on an isomorphic app where routes are shared. It appears that it is happening on the navigateAction call.

@lingyan Could this be happening within routr?

routr strips off query string and hash before trying to match a url to routes: https://github.com/yahoo/routr/blob/master/lib/router.js#L74-L94
@geekyme Does the stack trace show which lib/line throws the error?

Unfortunately no, there was no stack trace. :(

On 28 Jul 2015, at 6:18 am, lingyan<EMAIL_ADDRESS>wrote:
routr strips off query string and hash before trying to match a url to routes: https://github.com/yahoo/routr/blob/master/lib/router.js#L74-L94 https://github.com/yahoo/routr/blob/master/lib/router.js#L74-L94
@geekyme https://github.com/geekyme Does the stack trace show which lib/line throws the error?
—
Reply to this email directly or view it on GitHub https://github.com/yahoo/fluxible-router/issues/71#issuecomment-125363630.

Following up on this, got the same syntax error triggering when a user access the route with query parameter ?query=%5BD.Y.O.N%5DPopular+Taiwan+Teeth+Whitening+Spa%21%7B+

This error actually comes from https://github.com/yahoo/intl-messageformat when there is escaped ''


[Feature] - not an issue!! - Specific records in a list

Hi,
Thanks again for this plugin!! very useful. The proof, I received a request from a user. Here is the feature requested... :
The person said that he would like to be able to, after he applied filters, that the list kept only the selected records.
For example, with the october/test plugin:

Hi there!  I'm thinking this is a bit of scope creep for ListSaver.  Why not create a "favorites" column and add it to the current filter widget?  Perhaps a bulk "Add Checked to Favorites" or an inline switch to toggle each item as a favorite?  Your user can then check the Favorites filter and save the list to ListSaver.

Or when a list is created, all rows that are checked are stored (ids) as well with the current filters configuration. And perhaps, the plugin could listen to [backend.list.extendQuery] as if there is any id's stored, do a whereIn[].
this would just allow to create really customized list. (regardless if filters have been used).

"What to do with the checked IDs is outside the scope of ListSaver. Some may want to query whereIn(), some may want to query whereNotIn(), some may want to keep the checked state alongside the unchecked, etc."
Totally agree, thank you!! can't wait to test.

Just an headsup, it works well! thank you again @sixgweb , very appreciated.


Iterator protocol

for loops now act on IntoIterator, so iter() can be left out in for loops in many cases
deref coercions have landed. Removed a few &*

see http://this-week-in-rust.org/blog/2015/02/02/this-week-in-rust-68/ for details

These are such awesome changes! I'm excited about them.


adds linked-list exercise

modified:   config.json
new file:   exercises/practice/linked-list/.docs/instructions.md
new file:   exercises/practice/linked-list/.meta/config.json
new file:   exercises/practice/linked-list/.meta/proof.ci.wren
new file:   exercises/practice/linked-list/.meta/tests.toml
new file:   exercises/practice/linked-list/LICENSE
new file:   exercises/practice/linked-list/linked-list.spec.wren
new file:   exercises/practice/linked-list/linked-list.wren
new file:   exercises/practice/linked-list/package.wren

closes #117

Since we're both creating exercises, I'd suggest we use issues to track exercises we claim. I did this on the awk track with success: create an issue to indicate you have claimed an issue and assign it to yourself. Put Closed #123 (the number of the issue) in the PR description to link them (the issue gets auto-closed when the PR is merged).

@Atomic-Germ were you going to continue? I'd be happy to help out.

@glennj help would be welcome, thank you

@Atomic-Germ I took the liberty of cloning your repo and committing to it.

@Atomic-Germ I took the liberty of cloning your repo and committing to it.

Thank you!

@Atomic-Germ Thanks so much for helping and getting the ball rolling on this one!