text:
Locations endpoint throwing 400 and 500 errors

Hi -
For each endpoint except for locations, I'm able to request all of the possible fields and I get the data I would expect. When I request all of the retrievable fields for the locations endpoint, I get either a 400 or 500 error. For example, see the example request below, which resulted in a 400 error. Do you know why this would be the case?
Thanks,
Chris
POST /api/locations/query HTTP/1.1
Host: www.patentsview.org
Content-Type: application/x-www-form-urlencoded
user_agent: chriscrewbaker@gmail.com
Cache-Control: no-cache
Postman-Token: eb64a699-7996-5964-2b33-f630879b243a

{"q":{"patent_number":"5116621"},"f":["app_country","app_date","app_number","app_type","appcit_app_number","appcit_category","appcit_date","appcit_kind","appcit_sequence","assignee_first_name","assignee_first_seen_date","assignee_id","assignee_last_name","assignee_last_seen_date","assignee_lastknown_city","assignee_lastknown_country","assignee_lastknown_latitude","assignee_lastknown_location_id","assignee_lastknown_longitude","assignee_lastknown_state","assignee_num_patents_for_location","assignee_organization","assignee_total_num_inventors","assignee_total_num_patents","assignee_type","cited_patent_category","cited_patent_date","cited_patent_kind","cited_patent_number","cited_patent_sequence","cited_patent_title","citedby_patent_category","citedby_patent_date","citedby_patent_kind","citedby_patent_number","citedby_patent_title","cpc_category","cpc_first_seen_date","cpc_group_id","cpc_group_title","cpc_last_seen_date","cpc_num_patents_for_location","cpc_section_id","cpc_sequence","cpc_subgroup_id","cpc_subgroup_title","cpc_subsection_id","cpc_subsection_title","cpc_total_num_assignees","cpc_total_num_inventors","cpc_total_num_patents","govint_contract_award_number","govint_org_id","govint_org_level_one","govint_org_level_three","govint_org_level_two","govint_org_name","govint_raw_statement","inventor_first_name","inventor_first_seen_date","inventor_id","inventor_last_name","inventor_last_seen_date","inventor_lastknown_city","inventor_lastknown_country","inventor_lastknown_latitude","inventor_lastknown_location_id","inventor_lastknown_longitude","inventor_lastknown_state","inventor_num_patents_for_location","inventor_total_num_patents","ipc_action_date","ipc_class","ipc_classification_data_source","ipc_classification_value","ipc_first_seen_date","ipc_last_seen_date","ipc_main_group","ipc_section","ipc_sequence","ipc_subclass","ipc_subgroup","ipc_symbol_position","ipc_total_num_assignees","ipc_total_num_inventors","ipc_version_indicator","location_city","location_country","location_id","location_key_id","location_latitude","location_longitude","location_state","location_total_num_assignees","location_total_num_inventors","location_total_num_patents","nber_category_id","nber_category_title","nber_first_seen_date","nber_last_seen_date","nber_num_patents_for_location","nber_subcategory_id","nber_subcategory_title","nber_total_num_assignees","nber_total_num_inventors","nber_total_num_patents","patent_abstract","patent_average_processing_time","patent_date","patent_firstnamed_assignee_city","patent_firstnamed_assignee_country","patent_firstnamed_assignee_id","patent_firstnamed_assignee_latitude","patent_firstnamed_assignee_location_id","patent_firstnamed_assignee_longitude","patent_firstnamed_assignee_state","patent_firstnamed_inventor_city","patent_firstnamed_inventor_country","patent_firstnamed_inventor_id","patent_firstnamed_inventor_latitude","patent_firstnamed_inventor_location_id","patent_firstnamed_inventor_longitude","patent_firstnamed_inventor_state","patent_id","patent_kind","patent_num_cited_by_us_patents","patent_num_cited_by_us_patents_for_location","patent_num_claims","patent_num_combined_citations","patent_num_foreign_citations","patent_num_us_application_citations","patent_num_us_patent_citations","patent_number","patent_processing_time","patent_title","patent_type","patent_year","rawinventor_first_name","rawinventor_last_name","uspc_first_seen_date","uspc_last_seen_date","uspc_mainclass_id","uspc_mainclass_title","uspc_num_patents_for_location","uspc_sequence","uspc_subclass_id","uspc_subclass_title","uspc_total_num_assignees","uspc_total_num_inventors","uspc_total_num_patents","wipo_field_id","wipo_field_title","wipo_sector_title","wipo_sequence"],"o":{"include_subentity_total_counts":false,"matched_subentities_only":true,"page":1,"per_page":25},"s":{}}

@crew102 FWIW the presence of cpc_sequence is the cause of the 400 error.  X-Status-Reason: Invalid field specified: cpc_sequence and setting the matched_subentities_only to true causes the 500 error.  The query works using all the fields on the location's api page except for cpc_sequence when matched_subentities_only=false.
I hope this helps narrow down these problems in the api.
-> POST /api/locations/query HTTP/1.1
-> Host: www.patentsview.org
-> User-Agent: https://github.com/ropensci/patentsview
-> Accept-Encoding: gzip, deflate
-> Accept: application/json, text/xml, application/xml, */*
-> Content-Length: 4393
-> >> {"q":{"patent_number":"5116621"},"f":["app_country","app_date","app_number","app_type","appcit_app_number","appcit_category","appcit_date","appcit_kind","appcit_sequence","assignee_first_name","assignee_first_seen_date","assignee_id","assignee_last_name","assignee_last_seen_date","assignee_lastknown_city","assignee_lastknown_country","assignee_lastknown_latitude","assignee_lastknown_location_id","assignee_lastknown_longitude","assignee_lastknown_state","assignee_num_patents_for_location","assignee_organization","assignee_total_num_inventors","assignee_total_num_patents","assignee_type","cited_patent_category","cited_patent_date","cited_patent_kind","cited_patent_number","cited_patent_sequence","cited_patent_title","citedby_patent_category","citedby_patent_date","citedby_patent_kind","citedby_patent_number","citedby_patent_title","cpc_category","cpc_first_seen_date","cpc_group_id","cpc_group_title","cpc_last_seen_date","cpc_num_patents_for_location","cpc_section_id","cpc_subgroup_id","cpc_subgroup_title","cpc_subsection_id","cpc_subsection_title","cpc_total_num_assignees","cpc_total_num_inventors","cpc_total_num_patents","detail_desc_length","examiner_first_name","examiner_group","examiner_id","examiner_last_name","examiner_role","forprior_country","forprior_date","forprior_docnumber","forprior_kind","forprior_sequence","govint_contract_award_number","govint_org_id","govint_org_level_one","govint_org_level_three","govint_org_level_two","govint_org_name","govint_raw_statement","inventor_first_name","inventor_first_seen_date","inventor_id","inventor_last_name","inventor_last_seen_date","inventor_lastknown_city","inventor_lastknown_country","inventor_lastknown_latitude","inventor_lastknown_location_id","inventor_lastknown_longitude","inventor_lastknown_state","inventor_num_patents_for_location","inventor_total_num_patents","ipc_action_date","ipc_class","ipc_classification_data_source","ipc_classification_value","ipc_first_seen_date","ipc_last_seen_date","ipc_main_group","ipc_section","ipc_sequence","ipc_subclass","ipc_subgroup","ipc_symbol_position","ipc_total_num_assignees","ipc_total_num_inventors","ipc_version_indicator","lawyer_first_name","lawyer_first_seen_date","lawyer_id","lawyer_last_name","lawyer_last_seen_date","lawyer_organization","lawyer_sequence","lawyer_total_num_assignees","lawyer_total_num_inventors","lawyer_total_num_patents","location_city","location_country","location_county","location_county_fips","location_id","location_key_id","location_latitude","location_longitude","location_state","location_state_fips","location_total_num_assignees","location_total_num_inventors","location_total_num_patents","nber_category_id","nber_category_title","nber_first_seen_date","nber_last_seen_date","nber_num_patents_for_location","nber_subcategory_id","nber_subcategory_title","nber_total_num_assignees","nber_total_num_inventors","nber_total_num_patents","patent_abstract","patent_average_processing_time","patent_date","patent_firstnamed_assignee_city","patent_firstnamed_assignee_country","patent_firstnamed_assignee_id","patent_firstnamed_assignee_latitude","patent_firstnamed_assignee_location_id","patent_firstnamed_assignee_longitude","patent_firstnamed_assignee_state","patent_firstnamed_inventor_city","patent_firstnamed_inventor_country","patent_firstnamed_inventor_id","patent_firstnamed_inventor_latitude","patent_firstnamed_inventor_location_id","patent_firstnamed_inventor_longitude","patent_firstnamed_inventor_state","patent_id","patent_kind","patent_num_cited_by_us_patents","patent_num_cited_by_us_patents_for_location","patent_num_claims","patent_num_combined_citations","patent_num_foreign_citations","patent_num_us_application_citations","patent_num_us_patent_citations","patent_number","patent_processing_time","patent_title","patent_type","patent_year","pct_102_date","pct_371_date","pct_date","pct_docnumber","pct_doctype","pct_kind","rawinventor_first_name","rawinventor_last_name","uspc_first_seen_date","uspc_last_seen_date","uspc_mainclass_id","uspc_mainclass_title","uspc_num_patents_for_location","uspc_sequence","uspc_subclass_id","uspc_subclass_title","uspc_total_num_assignees","uspc_total_num_inventors","uspc_total_num_patents","wipo_field_id","wipo_field_title","wipo_sector_title","wipo_sequence"],"o":{"include_subentity_total_counts":false,"matched_subentities_only":false,"page":1,"per_page":25},"s":{}}

<- HTTP/1.1 200 OK

I wrote a scritp to incrementally add location fields to the query.  I found that with matched_subentities_only=true the assignee, cpc, nbr, raw fields and uspc fields shown below caused 500 errors.  Below the list is the largest subset of fields that worked, adding any more caused a 500 error. @crew102  Perhaps these fields could be unmapped from the R package until the api is fixed for this endoint?
   # 400 invalid field specified: cpc_sequence  others caused 500 errors
   troublesome = c("cpc_sequence", "assignee_first_name","assignee_first_seen_date","assignee_id","assignee_last_name","assignee_last_seen_date","assignee_lastknown_city","assignee_lastknown_country","assignee_lastknown_latitude","assignee_lastknown_location_id","assignee_lastknown_longitude","assignee_lastknown_state","assignee_num_patents_for_location","assignee_organization","assignee_total_num_inventors","assignee_total_num_patents","assignee_type","cpc_category","cpc_first_seen_date","cpc_group_id","cpc_group_title","cpc_last_seen_date","cpc_num_patents_for_location","cpc_section_id","cpc_subgroup_id","cpc_total_num_assignees","cpc_subgroup_title","cpc_subsection_id","cpc_subsection_title","cpc_total_num_inventors","cpc_total_num_patents","nber_category_id","nber_category_title","nber_first_seen_date","nber_last_seen_date","nber_num_patents_for_location","nber_subcategory_id","nber_subcategory_title","nber_total_num_assignees","nber_total_num_inventors","nber_total_num_patents","rawinventor_first_name","rawinventor_last_name","uspc_first_seen_date","uspc_last_seen_date","uspc_mainclass_id","uspc_mainclass_title","uspc_num_patents_for_location","uspc_sequence","uspc_subclass_id","uspc_subclass_title","uspc_total_num_assignees","uspc_total_num_inventors","uspc_total_num_patents")

-> POST /api/locations/query HTTP/1.1-> Host: www.patentsview.org
-> User-Agent: https://github.com/ropensci/patentsview
-> Accept-Encoding: gzip, deflate-> Accept: application/json, text/xml, application/xml, */*
-> Content-Length: 3124->
 >> {"q":{"patent_number":"5116621"},"f":["app_country","app_date","app_number","app_type","appcit_app_number","appcit_category","appcit_date","appcit_kind","appcit_sequence","cited_patent_category","cited_patent_date","cited_patent_kind","cited_patent_number","cited_patent_sequence","cited_patent_title","citedby_patent_category","citedby_patent_date","citedby_patent_kind","citedby_patent_number","citedby_patent_title","detail_desc_length","examiner_first_name","examiner_group","examiner_id","examiner_last_name","examiner_role","forprior_country","forprior_date","forprior_docnumber","forprior_kind","forprior_sequence","govint_contract_award_number","govint_org_id","govint_org_level_one","govint_org_level_three","govint_org_level_two","govint_org_name","govint_raw_statement","inventor_first_name","inventor_first_seen_date","inventor_id","inventor_last_name","inventor_last_seen_date","inventor_lastknown_city","inventor_lastknown_country","inventor_lastknown_latitude","inventor_lastknown_location_id","inventor_lastknown_longitude","inventor_lastknown_state","inventor_num_patents_for_location","inventor_total_num_patents","ipc_action_date","ipc_class","ipc_classification_data_source","ipc_classification_value","ipc_first_seen_date","ipc_last_seen_date","ipc_main_group","ipc_section","ipc_sequence","ipc_subclass","ipc_subgroup","ipc_symbol_position","ipc_total_num_assignees","ipc_total_num_inventors","ipc_version_indicator","lawyer_first_name","lawyer_first_seen_date","lawyer_id","lawyer_last_name","lawyer_last_seen_date","lawyer_organization","lawyer_sequence","lawyer_total_num_assignees","lawyer_total_num_inventors","lawyer_total_num_patents","location_city","location_country","location_county","location_county_fips","location_id","location_key_id","location_latitude","location_longitude","location_state","location_state_fips","location_total_num_assignees","location_total_num_inventors","location_total_num_patents","patent_abstract","patent_average_processing_time","patent_date","patent_firstnamed_assignee_city","patent_firstnamed_assignee_country","patent_firstnamed_assignee_id","patent_firstnamed_assignee_latitude","patent_firstnamed_assignee_location_id","patent_firstnamed_assignee_longitude","patent_firstnamed_assignee_state","patent_firstnamed_inventor_city","patent_firstnamed_inventor_country","patent_firstnamed_inventor_id","patent_firstnamed_inventor_latitude","patent_firstnamed_inventor_location_id","patent_firstnamed_inventor_longitude","patent_firstnamed_inventor_state","patent_id","patent_kind","patent_num_cited_by_us_patents","patent_num_cited_by_us_patents_for_location","patent_num_claims","patent_num_combined_citations","patent_num_foreign_citations","patent_num_us_application_citations","patent_num_us_patent_citations","patent_number","patent_processing_time","patent_title","patent_type","patent_year","pct_102_date","pct_371_date","pct_date","pct_docnumber","pct_doctype","pct_kind","wipo_field_id","wipo_field_title","wipo_sector_title","wipo_sequence"],"o":{"include_subentity_total_counts":false,"matched_subentities_only":true,"page":1,"per_page":25},"s":{}}

<- HTTP/1.1 200 OK

Hi @mustberuss, I suspect that setting matched_subentities_only=true means that the API doesn't actually have to worry about returning some of the fields that you identified in the "largest subset," due to the fact that there aren't any matching subentries to return (at least for patent number 5116621), though I could be wrong about this. Regarding unmapping the fields in the patentsview r package, are you suggesting that, for example, patentsview::get_fields(endpoint = "inventors") returns only those fields that are in the "largest working subset" that you identified? If so, I think I would prefer that the package implement the following instead:
If both of these are true:

The user has included at least one "problematic field" in their query to the to the inventors endpoint

problematic field = any field that has been resulting in the unexpected errors that I mentioned in my original post on this issue - i.e., the 400 or 500 errors that are occurring for the inventors endpoint. A non-problematic field is a queryable field for the inventors endpoint that doesn't throw an error regardless of the value of matched_subentities_only

The HTTP request actually results in a 400 or 500 error.

..Then search_pv() should throw a custom error message that explains to the user that some queryable fields for the inventors endpoint are actually not working at the moment, and then lists the subentity groups that have been problematic.
Let's move any further discussion into a new issue at ropensci/patentsview

i.e., the 400 or 500 errors that are occurring for the inventors endpoint.

@crew102 just to clarify, I believe you mean the locations endpoint

In looking at this further, I don't believe there are any troublesome fields.  It's the number of groups present that seems to be the problem.  With the exception of cpc_sequence's 400, I can query for each group's fields in individual calls to the location endpoint.  I now think the complexity of the sql in entitySpecs.php for $LOCATION_ENTITY_SPECS is the problem when multiple groups are present.   I get back this X-Status-Reason header with the 500.
<- HTTP/1.1 500 Internal Server Error
<- X-Status-Reason: Query execution failed.

I'm wondering if the call times out and throws the 500 when too many groups are present.  As @crew102 mentioned originally, for other endpoints he can request every possible field successfully in a single api call.  It's just the locations endpoint that has this problem.
Successful individual request:
"f":["appcit_app_number","appcit_category","appcit_date","appcit_kind","appcit_sequence"]
"f":["app_country","app_date","app_number","app_type"]
"f":["cited_patent_category","cited_patent_date","cited_patent_kind","cited_patent_number","cited_patent_sequence","cited_patent_title"]
"f":["citedby_patent_category","citedby_patent_date","citedby_patent_kind","citedby_patent_number","citedby_patent_title"]
"f":["cpc_category","cpc_first_seen_date","cpc_group_id","cpc_group_title","cpc_last_seen_date","cpc_num_patents_for_location","cpc_section_id","cpc_subgroup_id","cpc_subgroup_title","cpc_subsection_id","cpc_subsection_title","cpc_total_num_assignees","cpc_total_num_inventors","cpc_total_num_patents"]
"f":["examiner_first_name","examiner_group","examiner_id","examiner_last_name","examiner_role"]
"f":["forprior_country","forprior_date","forprior_docnumber","forprior_kind","forprior_sequence"]
"f":["govint_contract_award_number","govint_org_id","govint_org_level_one","govint_org_level_three","govint_org_level_two","govint_org_name","govint_raw_statement"]
"f":["inventor_first_name","inventor_first_seen_date","inventor_id","inventor_last_name","inventor_last_seen_date","inventor_lastknown_city","inventor_lastknown_country","inventor_lastknown_latitude","inventor_lastknown_location_id","inventor_lastknown_longitude","inventor_lastknown_state","inventor_num_patents_for_location","inventor_total_num_patents"]
"f":["ipc_action_date","ipc_class","ipc_classification_data_source","ipc_classification_value","ipc_first_seen_date","ipc_last_seen_date","ipc_main_group","ipc_section","ipc_sequence","ipc_subclass","ipc_subgroup","ipc_symbol_position","ipc_total_num_assignees","ipc_total_num_inventors","ipc_version_indicator"]
"f":["lawyer_first_name","lawyer_first_seen_date","lawyer_id","lawyer_last_name","lawyer_last_seen_date","lawyer_organization","lawyer_sequence","lawyer_total_num_assignees","lawyer_total_num_inventors","lawyer_total_num_patents"]
"f":["location_city","location_country","location_county","location_county_fips","location_id","location_key_id","location_latitude","location_longitude","location_state","location_state_fips","location_total_num_assignees","location_total_num_inventors","location_total_num_patents"]
"f":["nber_category_id","nber_category_title","nber_first_seen_date","nber_last_seen_date","nber_num_patents_for_location","nber_subcategory_id","nber_subcategory_title","nber_total_num_assignees","nber_total_num_inventors","nber_total_num_patents"]
"f":["detail_desc_length","patent_abstract","patent_average_processing_time","patent_date","patent_firstnamed_assignee_city","patent_firstnamed_assignee_country","patent_firstnamed_assignee_id","patent_firstnamed_assignee_latitude","patent_firstnamed_assignee_location_id","patent_firstnamed_assignee_longitude","patent_firstnamed_assignee_state","patent_firstnamed_inventor_city","patent_firstnamed_inventor_country","patent_firstnamed_inventor_id","patent_firstnamed_inventor_latitude","patent_firstnamed_inventor_location_id","patent_firstnamed_inventor_longitude","patent_firstnamed_inventor_state","patent_id","patent_kind","patent_num_cited_by_us_patents","patent_num_cited_by_us_patents_for_location","patent_num_claims","patent_num_combined_citations","patent_num_foreign_citations","patent_num_us_application_citations","patent_num_us_patent_citations","patent_number","patent_processing_time","patent_title","patent_type","patent_year"]
"f":["pct_102_date","pct_371_date","pct_date","pct_docnumber","pct_doctype","pct_kind"]
"f":["rawinventor_first_name","rawinventor_last_name"]
"f":["uspc_first_seen_date","uspc_last_seen_date","uspc_mainclass_id","uspc_mainclass_title","uspc_num_patents_for_location","uspc_sequence","uspc_subclass_id","uspc_subclass_title","uspc_total_num_assignees","uspc_total_num_inventors","uspc_total_num_patents"]
"f":["wipo_field_id","wipo_field_title","wipo_sector_title","wipo_sequence"]

with credit to @crew102 for suggesting we look at the (now vindicated) troublesome groups.

Now I'm seeing a 500 error thrown on three of the endpoints (cpc_subsections, nber_subcategories, uspc_mainclasses) when matched_subentities_only is false and all possible fields are requested.
library(patentsview)

  z <- lapply(get_endpoints(), function(x) {

  tryCatch(
  {
     search_pv(
      '{"patent_number":"5116621"}',
      endpoint = x,
      mtchd_subent_only = FALSE,
      fields = get_fields(x)
     )
     print(paste("success",x))
  },
  error = function(e) {print(paste("error",x,e))}
  )
})

[1] "success assignees"
[1] "error cpc_subsections Error in xheader_er_or_status(resp): Internal Server Error (HTTP 500).\n"
[1] "success inventors"
[1] "success locations"
[1] "error nber_subcategories Error in xheader_er_or_status(resp): Internal Server Error (HTTP 500).\n"
[1] "success patents"
[1] "error uspc_mainclasses Error in xheader_er_or_status(resp): Internal Server Error (HTTP 500).\n"

If I set mtchd_subent_only=TRUE then only the locations endpoint throws a 500 as we saw before.

Thanks for pointing this out -- this is definitely an issue and we are looking into it! We'll get back to you once we've fixed the issue!

authors: crew102 mustberuss sarahkelley

repo: CSSIP-AIR/PatentsView-API


text:
Sending reminders to users does not check whether they are within the server

An additional check is required before sending a user a reminder message to ensure they are still within the server. This is due to there possibly being a delay between the user being logged & the user needing the reminder sent. (So the check is not necessary for every place the bot ever sends a message to a user, just for reminder tasks.)
A log message should be sent if the bot finds a user that needs reminding but no longer is in the server. However, this log should be at level info to prevent spamming the log channels.

Should be noted I don't know if it's 100% the fact they weren't in the server anymore - just a random guess

It'll be a good check to make nonetheless and if the issue persists moree debugging can be done from that point forwards👍🏻

source: gharchive/issue

authors: CarrotManMatt MattyTheHacker

license_type: permissive

license_source: github-api


text:
TinySluggable should order by custom field than create field

Reported by dien | April 4th, 2011 @ 08:24 PM
From
$prev = $Model->find('first', array(
        'contain' => array(),
        'fields' => array("{$Model->alias}.{$Model->tinySlug}", "{$Model->alias}.created"),
        'order' => "{$Model->alias}.created DESC"));

to
$prev = $Model->find('first', array(
                        'contain' => array(),
                        'fields' => array("{$Model->alias}.{$Model->tinySlug}", "{$Model->alias}." . $this->settings[$Model->alias]['order']),
                        'order' => "{$Model->alias}.{$this->settings[$Model->alias]['order']} DESC"));

new setting default:
protected $_defaults = array(

      'tinySlug' => 'tiny_slug',
      'codeset' => '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ',
      'order' => 'created'
  );

Just made the change and committed it to the develop branch.

authors: ajibarra burzum

repo: CakeDC/utils

license: mit

license_source: bigquery


text:
Dump tests only if they've been changed

The best way to do this is to add a modified property method in the Serializable class. Simply having setattr toggle an attribute is probably not enough; consider creating a "snapshot" of the initialization and comparing when dumping tests.

As @kvchen brought up recently, I'd rather see the test progress being tracked in a separate file so that tests don't have to be rewritten. It's especially annoying when the test files are under version control, since OK will reformat the tests during each run.

Closing in favor of #194


text:
Fix styling for content

Left: original, right: now

There is some padding missing for textual content.

Fixed in #27


text:
new HTML body renderer

currently there is no need for using SVG. plain HTML Divs would do the same job

part of the feature_cell_renderer branch

part of latest release_1 branch


text:
Remove Block from Main View and Filter

When the user clicks on the cross icon, the corresponding block should be removed from main view and filter view.

[ ] When the block is added several times to the Main view, check the count and only remove it from filter view after the last instance in Main view is removed

Done on this commit
https://github.com/Caleydo/mothertable/commit/65438acbb711d012dad27ee873cb20323ca9db6b

authors: bikramkawan katush

repo: Caleydo/mothertable


text:
Split multiform Issue #157

This is the beta test. I would like to get the feedback now so as to improve for further steps. I will be working on improving the height adaptation of multiform.
For now please do not merge until I fix the height of visualizations.

@thinkh @katush I would like you to test this.  There is the strange behavior of string multiform despite all other forms. I would like you to check other feature not only the scaling. Since I have reimplemented update method of multiform. So there might be some bug in functional issue, and please let me know if there is another functional issue before you merge.
I have removed the dragging for this PR not to make too much complex. I will add that in new PR after this works on your PC.

@bikramkawan Please resolve the conflicts before I can merge.

source: gharchive/pull-request

authors: bikramkawan thinkh


text:
baseline functions differ in R and Python

Hello!
I am translating the Cox model from R to Python and found that baseline functions in R differs from the baseline functions in Python.
Based on the data from the file test.xlsx, the results are as follows:

It seemed strange to me, considering that the lifelines library is based on the codes of functions from R (if I understand correctly).
At the same time, the characteristics of the Cox model and the coefficient before regressor “var_const” turned out to be the same in R and Python (coef[var_cost] = 0,05295).
Tell me please why baseline functions may differ in R and Python?
Code in R:
library("survival")
library(survminer)

#### Data download:
test_R <- read_excel("test.xlsx")

#### Data preparation:
test_R$start = test_R$months
test_R$stop = test_R$start + 1

#### Run the model:
res.cox1 <- coxph(Surv(start, stop, event)~ var_const, data = test_R, method = 'efron')
summary(res.cox1)

#### Calculate baseline cumulative hazard function:
bhest = basehaz(fit = res.cox1)
basehaz_predict <- data.frame(time = bhest$time,
                              hazard = bhest$hazard)

#### Calculate baseline survival function
cox_survival = survfit(res.cox1)
surv_predict <- data.frame(time = cox_survival$time,
                           survival = cox_survival$surv)

Code in Python:
import pandas as pd
import numpy as np
from lifelines.utils import to_long_format
from lifelines import CoxTimeVaryingFitter

#### Data download:
df = pd.read_excel('test.xlsx')

#### Data preparation:
df_model = df_model[['id', 'event', 'months', ‘var_const’]]
df_model = to_long_format(df_model, duration_col = "months")
df_model['start'] = df_model['stop']
df_model['stop'] = df_model['start']+1

#### Run the model:
ctv = CoxTimeVaryingFitter()
ctv.fit(df_model, id_col ='id', event_col='event', start_col = 'start', stop_col = 'stop')
ctv.print_summary()

#### Calculate baseline cumulative hazard function:
ctv.baseline_cumulative_hazard_

#### Calculate baseline survival function:
ctv.baseline_survival_

Hi @Valery2511
At first thought, I'm not sure. I do have tests in the project comparing lifelines baseline vs R's baseline. I will have to do some digging.
Are you comfortable providing me the dataset you are using? That would help me source the difference.

CamDavidsonPilon, thank you for answering!
I attached the dataset at the beginning of the question but just in case I attach it again:
https://github.com/CamDavidsonPilon/lifelines/files/5305589/test.xlsx

@CamDavidsonPilon, may be you will be interested, I also apply a file with the results of comparison of the baseline functions not only of R and Python but also of STATA (the dataset is the same - test.xlsx):
Compare_baseline_functions_R_Python_STATA.xlsx
The most interesting thing is that all three programs give three slightly different results:)
Code in STATA:
#### Data download:
import excel "test.xlsx", sheet("Sheet1") firstrow
sort id months

#### Run the model:
stset months, id(id) failure(event) enter(months==1)
stcox var_const, efron  // В Питоне Кокс считается только по методу Efron (в стате по умолчанию стоит метод Breslow)

#### Calculate baseline cumulative hazard function:
predict S0_hazard_cumulative, basechazard

#### Calculate baseline survival function:
predict S0_baseline_survivor, basesurv

Hello - I'm having a similar issue. I've fit the same model in CoxTimeVaryingFitter and R's Survival coxph function. Coefficients are the same (or similar enough) but baseline cumulative hazards are quite different. This post caught my eye and I was wondering if anything ever came of it?

Hi @PortlandMichelle. Hard to say what might be going on without seeing the dataset used. Can you reproduce it with a small synthetic dataset?

Hello - TBH I discovered the difference using a data set that I would not be able to share (due to confidentiality concerns), so I replicated it with the data provided in this post by the original poster. I find the identical results they did (in their original screen shot at the top of this post). That's why I was hoping there'd been some analysis using that data set that helped illuminate the issue back in 2020. But if you're able to do some investigation now, if we could both use the original data when this question was originally made, that would be great.

repo: CamDavidsonPilon/lifelines


text:
Why ~10% Cure Rate in This Example?

At the bottom of this page, we see the following chart:

The commentary is: Under this model, it suggests that only ~10% of subjects are ever cured (however, there is a lot of variance in the estimate of the p parameter).
I see the above chart as suggesting ~20-70% of patients are ever cured. Am I interpreting this incorrectly or is this an error in the documentation? If an error, I can submit a PR.

The 10% comes from the parameter estimates (p):

If we were to extend out the plot to infinity, the survival function would be asymptotic to 0.1

d'oh! thank you.


text:
How can i use this?

omg... i didnt write using... work properly thanks

I cannot use the using statement. The library is not found in the code. :( The library is installed, but I also cannot find something related to the lib when searching in the project for "env" or "candycoded"

repo: CandyCoded/env

license: MIT


text:
demiworld, graveless

This pull request was generated by the 'mq' tool

/trunk merge

repo: Canva/mergequeue-trunk


text:
Controll Hub Downgrade

Issue for pinning the project to 8.2.0
Just opening an issue here, thought it would be a good way to organize ideas.
My initial thoughts where, after @blarghmatey changed the dependencies,
dependencies {
    implementation 'org.firstinspires.ftc:Inspection:8.2.0'
    implementation 'org.firstinspires.ftc:Blocks:8.2.0'
    implementation 'org.firstinspires.ftc:RobotCore:8.2.0'
    implementation 'org.firstinspires.ftc:RobotServer:8.2.0'
    implementation 'org.firstinspires.ftc:OnBotJava:8.2.0'
    implementation 'org.firstinspires.ftc:Hardware:8.2.0'
    implementation 'org.firstinspires.ftc:FtcCommon:8.2.0'
    implementation 'org.firstinspires.ftc:Vision:8.2.0'
    implementation 'androidx.appcompat:appcompat:1.2.0'
}

To then change the version of the Android Gradle plugin from (7.2.0) to (4.1.3) thinking that when downgrading the andoird version you'd need to use an older version of the Android Gradle plugin.
classpath 'com.android.tools.build:gradle:4.1.3'

In addition I tried to change the minSdkVersion, targetSdkVersion and compileSdkVersion in build.gradel(FTC_Robot_controller) and set it to 27, this means we'd be building for Android 8.1+ (API level 27), which is the closest match to Android 8.2.0 I could find.

android {
    defaultConfig {
        minSdkVersion 27  // For Android 8.1+ (API level 27)
        targetSdkVersion 27  // Targeting Android 8.1 (API level 27)
        buildConfigField "String", "APP_BUILD_TIME", '"' + (new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSZ", Locale.ROOT).format(new Date())) + '"'
    }

    compileSdkVersion 27  // Compile against Android 8.1 (API level 27)

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
    namespace = 'com.qualcomm.ftcrobotcontroller'
}

--ALSO --
I ran into another major issue (maybe) when trying to use an older version of the android gradle plugin, it looks like I'm not able to use Java 12, and instead I need to use Java 8?
> BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 66

So I'm pretty unsure as to how to deal with this, I'm not sure If changing the Android Gradle plugin is the best approach here, but I think if it is there might be some more major issues that might come up.
Asking for assistance here, wondering if someone could run this on their machine?

 Get bot software back to working state for Fall Fest

So this confirms what I was noticing before, to downgrade to the last supported version of Android on our controller, we would need to downgrade our entire codebase to Java 8-11, currently, we're using Java 17.

Is that hard to do?
On Sun, Sep 22, 2024 at 18:50 Torin Etheridge @.***>
wrote:

So this confirms what I was noticing before, to downgrade to the last
supported version of Android on our controller, we would need to
downgrade our entire codebase to Java 8-11, currently, we're using Java
17.
Screenshot.2024-09-22.at.6.48.33.PM.png (view on web)
https://github.com/user-attachments/assets/a74a6881-cbde-4ec5-af43-7a5bc9dcb50b
—
Reply to this email directly, view it on GitHub
https://github.com/CapitalRobotics/Janxs_Brain/issues/3#issuecomment-2367000978,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5DXPAIIXSR7ZLJTYEFBNI3ZX5CR5AVCNFSM6AAAAABOTBJW36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRXGAYDAOJXHA
.
You are receiving this because you were assigned.Message ID:
@.***>

I don't think so, but since we're using Java 17 we'd lose access to all the Java 17-specific features and libraries (idk if we're using any now) and it might make future development harder, I think you wouldn't be able to use sealed classes, pattern matching for instanceof, records, text blocks (multi-line strings) switch expressions, and the NullPointerException messages. probably missing some other ones. So idk if there's another way to do this, but I think this is kinda a big problem if we don't get the driver hub soon.

Currently we arent using it now, and its not supposed to be a long term
solution I’d imagine, its for the fall fest mostly right?
On Sun, Sep 22, 2024 at 19:05 Torin Etheridge @.***>
wrote:

I don't think so, but since we're using Java 17 we'd lose access to all
the Java 17-specific features and libraries (idk if we're using any now)
and it might make future development harder, I think you wouldn't be able
to use sealed classes, pattern matching for instanceof, records, text
blocks (multi-line strings) switch expressions, and the
NullPointerException messages. probably missing some other ones. So idk
if there's another way to do this, but I think this is kinda a big problem
if we don't get the driver hub soon.
—
Reply to this email directly, view it on GitHub
https://github.com/CapitalRobotics/Janxs_Brain/issues/3#issuecomment-2367005307,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5DXPANB5QLWGYNSWME5HELZX5EMXAVCNFSM6AAAAABOTBJW36VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRXGAYDKMZQG4
.
You are receiving this because you were assigned.Message ID:
@.***>

authors: cheesebroccoli slombardo31 torinriley


text:
🛑 Funky Ducks - Client is down

In 0f2d4f6, Funky Ducks - Client (https://client.funkyducks.ml/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Funky Ducks - Client is back up in 70802af.

repo: CaptainQWasTaken/funkyducks-status


text:
Values mixed with challenges

While reading the paper, I had the feeling that the Values section was very short, while the Challenges was not particularly connected to the Values.
Not sure how to fix this, as I am not sure what was meant here.

We should reiterate!!

authors: CaptainSifff MakisH


text:
应用级别悬浮窗问题

你好，集成这个库以后实现视频悬浮窗getActivityContext因为拿不到值就会崩溃，有什么解决方法可以支持应用级别悬浮窗么

@CarGuo

你可以继承后重写getActivityContext()的返回，不过可能有点麻烦，在判断上。
你用的那个库试下你的悬浮窗，我试试做兼容

新版本demo中以增加支持 WindowActivity 和 FloatingVideo

repo: CarGuo/GSYVideoPlayer


text:
Collection and dictionary items are always assumed to be of the same type

As of now, CollectionSerializer and DictionarySerializer assume that the items in the collection/keys and values in the dictionary are of the exact same type as their generic type arguments.
That is to say, CollectionSerializer assumes that a List<A>'s items are all of type A, even if some may actually be of type B (where B : A). A similar assumption is made by DictionarySerializer when it comes to keys and values.
This is obviously not always going to be the case, and so it is necessary to ensure that the correct type is used during (de)serialization.
The most obvious fix is to simply include a Type attribute in the item, key, or value nodes as necessary, and prevent passing the item/key/value Type in case the Type attribute is found on said nodes. This will allow Serializer to (de)serialize them as the correct type.

Closed wtih https://github.com/Carnagion/GDSerializer/commit/5fa3416bd5feb3a7de7d11d92644c6f6cf0a424c.

repo: Carnagion/GDSerializer


text:
Upgrade CTA when user is close to the limits is not placed correctly

Failing in any page, profile, account, api-keys, ...

Being fixed in https://github.com/CartoDB/cartodb/pull/12174/commits/8b9d08d7c16c38471903ce316687d1e709eb075c.

Uhm... that staging user... 👮

authors: javitonino xavijam

repo: CartoDB/cartodb


text:
Pending issues from user migration (user and organization)

We did some cheating to get user migrator out as soon as possible. We need to handle some missing stuff:

[ ] Visualization

[x] Mapcaps (split to #12407)
[ ] DataImport models and friends (split to #12408)
[ ] Data library? (ExternalSource) (split to #12408)
[x] Mark as vizjson v2 (split to  #12407)

[ ] User

[x] Received notifications
[x] Import viewers with visualizations
[x] Redis (dataservices usage, mapviews)
[ ] SearchTweets (requires exporting data_imports, might be complicated) (split to #12408)

[x] Organizations

[x] Notifications
[x] Groups

Closing this one since all subtasks are in their own issue.


text:
Give feedback when user inserts a non valid domain in whitelisted email domains input

Related to #5339

cc/ @josecruz @javierarce

Same ticket here -> https://github.com/CartoDB/cartodb/issues/5345


text:
close privacy shuldn't close metadata when editing dataset metadata

after filled all the information in the metadata modal, then opening the privacy modal, when clicking cancel it closed both modals, so frustrating
str

go to map
click edit metadata
click privacy at the bottom
click cancel

expected behaviour

close privacy, keep metadata

actual behaviour

closed everything :(

Closing due to new builder ;).

authors: matallo xavijam


text:
[META] Improve performance

Pick slower editor actions and optimize.

There has been no activity on this issue for more several months. We are closing it. If you think this still needs to be addressed please open a new issue.

authors: juanignaciosl xavijam


text:
Deprecate old visualization enpoint

Closes #3045

@juanignaciosl CR please!

\o/

:+1: for the changes. Have you checked whether all errors because of visualizations.id format are because of this endpoint?

Frontend tests were OK :+1: (details)

No, not all are from here, but I wanted first to remove this from the equation. Now I'll check the others and fix at another ticket.

Ok, great :-)

Frontend tests were OK :+1: (details)

authors: Cartofante Kartones javisantana juanignaciosl


text:
Use indexOf (vanilla JS) instead of contains (jQuery)

Fixes #6678
CR @juanignaciosl
cc @xavijam

:+1: :fire:

Hey, aren't you supposed to commit the grunt generated vendor/assets/javascripts/cartodb.uncompressed.js as well?
https://github.com/CartoDB/cartodb/blob/master/CONTRIBUTING.md#update-cartodbjs

authors: gfiorav javitonino juanignaciosl


text:
8207 return success on visualization import

Fixes #8207

CR @rafatower

:+1:

authors: javitonino rafatower


text:
Make torque layer with Carto.js v4

Hello guys,I have a question~
It is possible to animate Map datas with the new carto.js v4.0 .  I want to find the example used torque.js with carto.js v4.0 , but I can't find it.

cc: @CartoDB/frontend

@dgaubert Thank you,I find the way to build the example just now : )
This is the example
`

Carto V4 with Torque.js

<!-- Include Leaflet -->
<script src="https://unpkg.com/leaflet@1.3.1/dist/leaflet.js"></script>
<link href="https://unpkg.com/leaflet@1.3.1/dist/leaflet.css" rel="stylesheet">
<!-- Include torque.js -->
<script src="./dist/torque.full.uncompressed.js"></script>
<!-- Include CARTO.js V4 -->
<script src="https://cartodb-libs.global.ssl.fastly.net/carto.js/v4.0.2/carto.min.js"></script>

authors: DTbelieveIT dgaubert

repo: CartoDB/torque


text:
NoMethodError - undefined method `class_name' for nil:NilClass: when using scoped through association

I'm trying to follow this tip from the wiki:
"Right now, searching deeper than one association away is not supported. You can work around this by setting up a series of :through associations to point all the way through."
I have:
class Activity < ActiveRecord::Base
  has_many :equipment, class_name: ActivityEquipment, inverse_of: :activity, dependent: :destroy
  has_many :terminal_equipment, through: :equipment

  pg_search_scope :search_all, :against => [:title, :description], using: {tsearch: {prefix: true}}, associated_against: {terminal_equipment: [:title]}
end

when I try something like:
Activity.search_all("foo")

I get the stack trace below. Hopefully I'm just being a dolt, but I've tried varying this a number of different ways and am not able to perturb it :). If I just search against :equipment instead of :terminal_equipment, that works fine, but it doesn't have the fields I need there.
Stack trace:
NoMethodError - undefined method `class_name' for nil:NilClass:
  (gem) activerecord-3.2.11/lib/active_record/reflection.rb:530:in `derive_class_name'
  (gem) activerecord-3.2.11/lib/active_record/reflection.rb:127:in `class_name'
  (gem) activerecord-3.2.11/lib/active_record/reflection.rb:172:in `klass'
  (gem) activerecord-3.2.11/lib/active_record/reflection.rb:187:in `table_name'
  (gem) pg_search-0.5.7/lib/pg_search/configuration/association.rb:17:in `table_name'
  (gem) pg_search-0.5.7/lib/pg_search/configuration/association.rb:25:in `subselect_alias'
  (gem) pg_search-0.5.7/lib/pg_search/configuration/foreign_column.rb:20:in `expression'
  (gem) pg_search-0.5.7/lib/pg_search/configuration/column.rb:20:in `to_sql'
  (gem) pg_search-0.5.7/lib/pg_search/features/tsearch.rb:64:in `block in tsdocument'
  (gem) pg_search-0.5.7/lib/pg_search/features/tsearch.rb:63:in `map'
  (gem) pg_search-0.5.7/lib/pg_search/features/tsearch.rb:63:in `tsdocument'
  (gem) pg_search-0.5.7/lib/pg_search/features/tsearch.rb:88:in `tsearch_rank'
  (gem) pg_search-0.5.7/lib/pg_search/features/tsearch.rb:23:in `rank'
  (gem) pg_search-0.5.7/lib/pg_search/scope_options.rb:66:in `block in rank'
  (gem) pg_search-0.5.7/lib/pg_search/scope_options.rb:65:in `gsub'
  (gem) pg_search-0.5.7/lib/pg_search/scope_options.rb:65:in `rank'
  (gem) pg_search-0.5.7/lib/pg_search/scope_options.rb:14:in `apply'
  (gem) pg_search-0.5.7/lib/pg_search.rb:37:in `block in pg_search_scope'
  (gem) activerecord-3.2.11/lib/active_record/relation/delegation.rb:14:in `block in search_all'

thanks @michaelnatkin it helped me

authors: grossadamm michaelnatkin


text:
multisearch slow

Struggling to get multisearch to work in a timely manner. I have approx 60k rows to search across, and results are taking 7-10 seconds.
My models look like:
multisearchable :against => [:heading, :tagline, :tags],
  :order_within_rank => "stories.created_at DESC",
  :ignoring => :accents,
  :using => {
    :tsearch => {:dictionary => "english"},
    :trigram => {:dictionary => "english"}
  },
  :if => :published?

My dev log shows:
   (3846.2ms)  SELECT COUNT(*) FROM "pg_search_documents" WHERE (((to_tsvector('simple', unaccent(coalesce("pg_search_documents"."content"::text, '')))) @@ (to_tsquery('simple', ''' ' || unaccent('g20') || ' '''))) OR ((unaccent(coalesce("pg_search_documents"."content"::text, ''))) % unaccent('g20')))
  Rendered application/_search.html.haml (1.2ms)
  CACHE (0.0ms)  SELECT COUNT(*) FROM "pg_search_documents" WHERE (((to_tsvector('simple', unaccent(coalesce("pg_search_documents"."content"::text, '')))) @@ (to_tsquery('simple', ''' ' || unaccent('g20') || ' '''))) OR ((unaccent(coalesce("pg_search_documents"."content"::text, ''))) % unaccent('g20')))
  PgSearch::Document Load (3872.0ms)  SELECT "pg_search_documents".*, ((ts_rank((to_tsvector('simple', unaccent(coalesce("pg_search_documents"."content"::text, '')))), (to_tsquery('simple', ''' ' || unaccent('g20') || ' ''')), 0))) AS pg_search_rank FROM "pg_search_documents" WHERE (((to_tsvector('simple', unaccent(coalesce("pg_search_documents"."content"::text, '')))) @@ (to_tsquery('simple', ''' ' || unaccent('g20') || ' '''))) OR ((unaccent(coalesce("pg_search_documents"."content"::text, ''))) % unaccent('g20'))) ORDER BY pg_search_rank DESC, "pg_search_documents"."id" ASC LIMIT 10 OFFSET 0

Why a simple count query is taking 4 seconds is beyond me. I've also tried storing the searchable data in a tsv_vector column as mentioned in https://github.com/Casecommons/pg_search/wiki/Building-indexes but it made no difference. Can anyone help point me as to what I'm doing wrong?
Thanks

reading the docs further, I don't think I was using tsv_vector columns properly. The readme only shows examples for pg_search_scope - does it work for multisearch too?

+1

I'm Having a similar issue, did you guys found the root cause? Or any optimization/workaround? Thx!

If anyone is still getting some performance issues, and has already stored/indexed the tsv data. Then I would recommend removing the trigram option from the pg_search_scope. My queries went from ~3500ms to < 20ms for ~70000 documents.

Did you guys find a solution?

I'm having a similar issue

I ended up switching search to a Elasticsearch instance

Had to do the same

I'm wondering if there's a particular reason that the pg_search_documents.content isn't a tsvector field?  Haven't dug into it too deep, but seems to me that keeping this as a text field and doing the heavy lifting every time is pretty naive?

I'm wondering if there's a particular reason that the pg_search_documents.content field isn't of tsvector type? Haven't dug into it too deep, but seems to me that keeping this as a text field and doing the heavy lifting every time is pretty naive?

I am not using pg_search yet, but I was looking at the migration it created and wondering exactly the same thing.

Not all pg_search scopes use tsearch.
That said, using a tsvector is a great idea. I've been wanting to move towards generating the multisearch Active Record model instead of bundling PgSearch::Document directly in the gem, but I haven't gotten around to it yet.

authors: Edwardzyc arcreative benoror brandnewmedia charle692 dungnguyenpowergate grncdr mojobiri nertzy robbieshepherd umerfarooq


text:
Restrict qualifier applied wrongly.

Hi,
The "__restrict__" qualifier is for linux only and applied to the start of the decl_string, rather than the end.
`
#if defined( _MSC_VER )
#define RESTRICT_ALIAS __restrict
#define RESTRICT_ALIAS_RETURN __restrict
#else
#define RESTRICT_ALIAS __restrict__
#define RESTRICT_ALIAS_RETURN
#endif
class Rest {
protected:
float* RESTRICT_ALIAS restVar;   ----- (1)
...
};
`
(1) The return_type.decl_string output produces the following ie.
::ns::Rest::restVar __restrict__ float *
From class restrict_t
    def build_decl_string(self, with_defaults=True):         return '__restrict__ ' + self.base.build_decl_string(with_defaults)
Code using the decl_string does not compile, the restrict qualifier should be applied to the pointer/ref/function not the variable, e.g.
    def build_decl_string(self, with_defaults=True):         if os.name == 'nt':             return self.base.build_decl_string(with_defaults) + ' __restrict'         else:             return self.base.build_decl_string(with_defaults) + ' __restrict__'

Any news on this?

Any news on this?

Starting work on this now. Can I use your above example in a test case?

repo: CastXML/pygccxml


text:
得到的模型文件如何部署到线上用有案例吗

得到的模型文件如何部署到线上用有案例吗

直接线上写公式就可以了

authors: Hioneowner code-fy

repo: CastellanZhang/alphaFM


text:
bugs in 0F C[X] -> bswap [REG32] (32 bit mode)

log
BUG -> bytes: [0F, 0E] -> must have len: 2 -> have len: 0 -> mnemonic: femms
BUG -> bytes: [0F, C9] -> must have len: 2 -> have len: 0 -> mnemonic: bswap ecx
BUG -> bytes: [0F, CA] -> must have len: 2 -> have len: 0 -> mnemonic: bswap edx
BUG -> bytes: [0F, CB] -> must have len: 2 -> have len: 0 -> mnemonic: bswap ebx
BUG -> bytes: [0F, CC] -> must have len: 2 -> have len: 0 -> mnemonic: bswap esp
BUG -> bytes: [0F, CD] -> must have len: 2 -> have len: 0 -> mnemonic: bswap ebp
BUG -> bytes: [0F, CE] -> must have len: 2 -> have len: 0 -> mnemonic: bswap esi
BUG -> bytes: [0F, CF] -> must have len: 2 -> have len: 0 -> mnemonic: bswap edi

Hello,
It seems like the bswap instruction bytes are marked as invalid in both x86 and x64 tables for some reason. That should be a simple fix.
I can't find femms (0F0E) in the reference I used, but I can see some information here. It seems to be related to the old MMX registers? Are these important to you?
Also thanks for finding some typos in the x86 tests referring in comments to 64bit register names.

this one
extern crate capstone;
extern crate lde;
extern crate zydis;

use capstone::prelude::*;

fn main() {
    println!("START X32 tests");
    test(&zydis32, &capstone32, &lde32);

    println!("\n\n\nSTART X64 tests");
    test(&zydis64, &capstone64, &lde64);
}

fn test(
    zydis: &Fn(&[u8]) -> (String, usize),
    capstone: &Fn(&[u8]) -> (String, usize),
    lde: &Fn(&[u8]) -> usize,
) {
    let mut last_mnem = String::new();
    let mut bytes = [0x00; 15];
    for i in 0x00..=0xFF {
        bytes[0] = i;
        for j in 0x00..=0xFF {
            bytes[1] = j;
            ////
            let mut lde_len: usize = lde(&bytes);

            let (zydis_mnem, zydis_len) = zydis(&bytes);
            let (capstone_mnem, capstone_len) = capstone(&bytes);

            if last_mnem == zydis_mnem {
                break;
            }

            last_mnem = zydis_mnem.clone();

            // if capstone_len != zydis_len && capstone_len != 0 && zydis_len != 0 {
            //     println!("{}: {} != {}", "WTF??!", capstone_len, zydis_len);
            // }

            let t_bytes = if zydis_len != 0 && capstone_len != 0 {
                if zydis_len != 0 {
                    bytes[..zydis_len].to_vec()
                } else {
                    bytes[..capstone_len].to_vec()
                }
            } else {
                bytes.to_vec()
            };

            if lde_len != zydis_len && lde_len != capstone_len {
                println!(
                    "{:02X?} -> len_eq: {}, need: {} -> have: {} -> mnem: {:?} -> {:?}",
                    t_bytes,
                    zydis_len == capstone_len,
                    zydis_len,
                    lde_len,
                    zydis_mnem,
                    capstone_mnem
                );
            }
            ////
        }
    }
}

fn lde32(bytes: &[u8]) -> usize {
    lde::X86.ld(&bytes) as usize
}

fn lde64(bytes: &[u8]) -> usize {
    lde::X64.ld(&bytes) as usize
}

fn zydis32(bytes: &[u8]) -> (String, usize) {
    let formatter = zydis::Formatter::new(zydis::gen::ZYDIS_FORMATTER_STYLE_INTEL).unwrap();
    let dec = zydis::Decoder::new(
        zydis::gen::ZYDIS_MACHINE_MODE_LONG_COMPAT_32,
        zydis::gen::ZYDIS_ADDRESS_WIDTH_32,
    ).unwrap();
    let info = dec.decode(&bytes, 0);
    match info {
        Ok(info) => match info {
            Some(info) => (
                formatter
                    .format_instruction(&info, 200, None)
                    .unwrap()
                    .trim()
                    .to_string(),
                info.length as usize,
            ),
            None => (String::new(), 0),
        },
        Err(_) => (String::new(), 0),
    }
}

fn zydis64(bytes: &[u8]) -> (String, usize) {
    let formatter = zydis::Formatter::new(zydis::gen::ZYDIS_FORMATTER_STYLE_INTEL).unwrap();
    let dec = zydis::Decoder::new(
        zydis::gen::ZYDIS_MACHINE_MODE_LONG_64,
        zydis::gen::ZYDIS_ADDRESS_WIDTH_64,
    ).unwrap();
    let info = dec.decode(&bytes, 0);
    match info {
        Ok(info) => match info {
            Some(info) => (
                formatter
                    .format_instruction(&info, 200, None)
                    .unwrap()
                    .trim()
                    .to_string(),
                info.length as usize,
            ),
            None => (String::new(), 0),
        },
        Err(_) => (String::new(), 0),
    }
}

fn capstone32(bytes: &[u8]) -> (String, usize) {
    let mut cs = Capstone::new()
        .x86()
        .mode(arch::x86::ArchMode::Mode32)
        .syntax(arch::x86::ArchSyntax::Intel)
        .detail(true)
        .build()
        .unwrap();

    let insns = cs.disasm_all(&bytes, 0).unwrap();

    let mut capstone_mnem: String = String::new();
    let mut capstone_len: usize = 0;
    for i in insns.iter() {
        capstone_mnem = (i.mnemonic().unwrap().to_string() + " " + i.op_str().unwrap()).to_string();
        capstone_len = i.bytes().len();
        break;
    }

    (capstone_mnem.trim().to_string(), capstone_len)
}

fn capstone64(bytes: &[u8]) -> (String, usize) {
    let mut cs = Capstone::new()
        .x86()
        .mode(arch::x86::ArchMode::Mode64)
        .syntax(arch::x86::ArchSyntax::Intel)
        .detail(true)
        .build()
        .unwrap();

    let insns = cs.disasm_all(&bytes, 0).unwrap();

    let mut capstone_mnem: String = String::new();
    let mut capstone_len: usize = 0;
    for i in insns.iter() {
        capstone_mnem = (i.mnemonic().unwrap().to_string() + " " + i.op_str().unwrap()).to_string();
        capstone_len = i.bytes().len();
        break;
    }

    (capstone_mnem.trim().to_string(), capstone_len)
}

give this log
START X32 tests
[0F, 0E] -> len_eq: true, need: 2 -> have: 0 -> mnem: "femms" -> "femms"
[26, 9B] -> len_eq: true, need: 2 -> have: 4 -> mnem: "fwait" -> "wait"
[2E, 9B] -> len_eq: true, need: 2 -> have: 4 -> mnem: "fwait" -> "wait"
[36, 9B] -> len_eq: true, need: 2 -> have: 4 -> mnem: "fwait" -> "wait"
[3E, 9B] -> len_eq: true, need: 2 -> have: 4 -> mnem: "fwait" -> "wait"
[62, C0, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[64, 9B] -> len_eq: true, need: 2 -> have: 4 -> mnem: "fwait" -> "wait"
[66, 9B] -> len_eq: true, need: 2 -> have: 4 -> mnem: "fwait" -> "wait"
[8C, 30, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[8D, C0, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[8E, 30, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[8F, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[9B] -> len_eq: true, need: 1 -> have: 3 -> mnem: "fwait" -> "wait"
[C4, C0, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[C5, C0, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[C6, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 3 -> mnem: "" -> ""
[C7, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 6 -> mnem: "" -> ""
[D9, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DA, E0, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DB, 20, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DD, 28, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DE, D8, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DE, DA, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DF, E1, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[F0, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 3 -> mnem: "" -> ""
[F2, 9B] -> len_eq: true, need: 2 -> have: 4 -> mnem: "fwait" -> "wait"
[F6, 08, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [eax], 0x00" -> "test byte ptr [eax], 0"
[F6, 09, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [ecx], 0x00" -> "test byte ptr [ecx], 0"
[F6, 0A, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [edx], 0x00" -> "test byte ptr [edx], 0"
[F6, 0B, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [ebx], 0x00" -> "test byte ptr [ebx], 0"
[F6, 0C, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [eax+eax*1], 0x00" -> "test byte ptr [eax + eax], 0"
[F6, 0D, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [0x00000000], 0x00" -> "test byte ptr [0], 0"
[F6, 0E, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [esi], 0x00" -> "test byte ptr [esi], 0"
[F6, 0F, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [edi], 0x00" -> "test byte ptr [edi], 0"
[F6, 48, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [eax], 0x00" -> "test byte ptr [eax], 0"
[F6, 49, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [ecx], 0x00" -> "test byte ptr [ecx], 0"
[F6, 4A, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [edx], 0x00" -> "test byte ptr [edx], 0"
[F6, 4B, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [ebx], 0x00" -> "test byte ptr [ebx], 0"
[F6, 4C, 00, 00, 00] -> len_eq: true, need: 5 -> have: 4 -> mnem: "test byte ptr [eax+eax*1], 0x00" -> "test byte ptr [eax + eax], 0"
[F6, 4D, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [ebp], 0x00" -> "test byte ptr [ebp], 0"
[F6, 4E, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [esi], 0x00" -> "test byte ptr [esi], 0"
[F6, 4F, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [edi], 0x00" -> "test byte ptr [edi], 0"
[F6, 88, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [eax], 0x00" -> "test byte ptr [eax], 0"
[F6, 89, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [ecx], 0x00" -> "test byte ptr [ecx], 0"
[F6, 8A, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [edx], 0x00" -> "test byte ptr [edx], 0"
[F6, 8B, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [ebx], 0x00" -> "test byte ptr [ebx], 0"
[F6, 8C, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 8 -> have: 7 -> mnem: "test byte ptr [eax+eax*1], 0x00" -> "test byte ptr [eax + eax], 0"
[F6, 8D, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [ebp], 0x00" -> "test byte ptr [ebp], 0"
[F6, 8E, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [esi], 0x00" -> "test byte ptr [esi], 0"
[F6, 8F, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [edi], 0x00" -> "test byte ptr [edi], 0"
[F6, C8, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test al, 0x00" -> "test al, 0"
[F6, C9, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test cl, 0x00" -> "test cl, 0"
[F6, CA, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test dl, 0x00" -> "test dl, 0"
[F6, CB, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test bl, 0x00" -> "test bl, 0"
[F6, CC, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test ah, 0x00" -> "test ah, 0"
[F6, CD, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test ch, 0x00" -> "test ch, 0"
[F6, CE, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test dh, 0x00" -> "test dh, 0"
[F6, CF, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test bh, 0x00" -> "test bh, 0"
[F7, 08, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [eax], 0x00" -> "test dword ptr [eax], 0"
[F7, 09, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [ecx], 0x00" -> "test dword ptr [ecx], 0"
[F7, 0A, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [edx], 0x00" -> "test dword ptr [edx], 0"
[F7, 0B, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [ebx], 0x00" -> "test dword ptr [ebx], 0"
[F7, 0C, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [eax+eax*1], 0x00" -> "test dword ptr [eax + eax], 0"
[F7, 0D, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [0x00000000], 0x00" -> "test dword ptr [0], 0"
[F7, 0E, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [esi], 0x00" -> "test dword ptr [esi], 0"
[F7, 0F, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [edi], 0x00" -> "test dword ptr [edi], 0"
[F7, 48, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [eax], 0x00" -> "test dword ptr [eax], 0"
[F7, 49, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [ecx], 0x00" -> "test dword ptr [ecx], 0"
[F7, 4A, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [edx], 0x00" -> "test dword ptr [edx], 0"
[F7, 4B, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [ebx], 0x00" -> "test dword ptr [ebx], 0"
[F7, 4C, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 8 -> have: 4 -> mnem: "test dword ptr [eax+eax*1], 0x00" -> "test dword ptr [eax + eax], 0"
[F7, 4D, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [ebp], 0x00" -> "test dword ptr [ebp], 0"
[F7, 4E, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [esi], 0x00" -> "test dword ptr [esi], 0"
[F7, 4F, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [edi], 0x00" -> "test dword ptr [edi], 0"
[F7, 88, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [eax], 0x00" -> "test dword ptr [eax], 0"
[F7, 89, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [ecx], 0x00" -> "test dword ptr [ecx], 0"
[F7, 8A, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [edx], 0x00" -> "test dword ptr [edx], 0"
[F7, 8B, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [ebx], 0x00" -> "test dword ptr [ebx], 0"
[F7, 8C, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 11 -> have: 7 -> mnem: "test dword ptr [eax+eax*1], 0x00" -> "test dword ptr [eax + eax], 0"
[F7, 8D, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [ebp], 0x00" -> "test dword ptr [ebp], 0"
[F7, 8E, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [esi], 0x00" -> "test dword ptr [esi], 0"
[F7, 8F, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [edi], 0x00" -> "test dword ptr [edi], 0"
[F7, C8, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test eax, 0x00" -> "test eax, 0"
[F7, C9, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test ecx, 0x00" -> "test ecx, 0"
[F7, CA, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test edx, 0x00" -> "test edx, 0"
[F7, CB, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test ebx, 0x00" -> "test ebx, 0"
[F7, CC, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test esp, 0x00" -> "test esp, 0"
[F7, CD, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test ebp, 0x00" -> "test ebp, 0"
[F7, CE, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test esi, 0x00" -> "test esi, 0"
[F7, CF, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test edi, 0x00" -> "test edi, 0"
[FE, 10, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[FF, 38, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""

START X64 tests
[0F, 0E] -> len_eq: true, need: 2 -> have: 0 -> mnem: "femms" -> "femms"
[8C, 30, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[8D, C0, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[8E, 30, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[8F, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[9B] -> len_eq: true, need: 1 -> have: 3 -> mnem: "fwait" -> "wait"
[C6, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 3 -> mnem: "" -> ""
[C7, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 6 -> mnem: "" -> ""
[CE, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 1 -> mnem: "" -> ""
[D9, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DA, E0, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DB, 20, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DD, 28, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DE, D8, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DE, DA, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[DF, E1, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[F0, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 3 -> mnem: "" -> ""
[F6, 08, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [rax], 0x00" -> "test byte ptr [rax], 0"
[F6, 09, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [rcx], 0x00" -> "test byte ptr [rcx], 0"
[F6, 0A, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [rdx], 0x00" -> "test byte ptr [rdx], 0"
[F6, 0B, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [rbx], 0x00" -> "test byte ptr [rbx], 0"
[F6, 0C, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [rax+rax*1], 0x00" -> "test byte ptr [rax + rax], 0"
[F6, 0D, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [0x0000000000000007], 0x00" -> "test byte ptr [rip], 0"
[F6, 0E, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [rsi], 0x00" -> "test byte ptr [rsi], 0"
[F6, 0F, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test byte ptr [rdi], 0x00" -> "test byte ptr [rdi], 0"
[F6, 48, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [rax], 0x00" -> "test byte ptr [rax], 0"
[F6, 49, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [rcx], 0x00" -> "test byte ptr [rcx], 0"
[F6, 4A, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [rdx], 0x00" -> "test byte ptr [rdx], 0"
[F6, 4B, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [rbx], 0x00" -> "test byte ptr [rbx], 0"
[F6, 4C, 00, 00, 00] -> len_eq: true, need: 5 -> have: 4 -> mnem: "test byte ptr [rax+rax*1], 0x00" -> "test byte ptr [rax + rax], 0"
[F6, 4D, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [rbp], 0x00" -> "test byte ptr [rbp], 0"
[F6, 4E, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [rsi], 0x00" -> "test byte ptr [rsi], 0"
[F6, 4F, 00, 00] -> len_eq: true, need: 4 -> have: 3 -> mnem: "test byte ptr [rdi], 0x00" -> "test byte ptr [rdi], 0"
[F6, 88, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [rax], 0x00" -> "test byte ptr [rax], 0"
[F6, 89, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [rcx], 0x00" -> "test byte ptr [rcx], 0"
[F6, 8A, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [rdx], 0x00" -> "test byte ptr [rdx], 0"
[F6, 8B, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [rbx], 0x00" -> "test byte ptr [rbx], 0"
[F6, 8C, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 8 -> have: 7 -> mnem: "test byte ptr [rax+rax*1], 0x00" -> "test byte ptr [rax + rax], 0"
[F6, 8D, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [rbp], 0x00" -> "test byte ptr [rbp], 0"
[F6, 8E, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [rsi], 0x00" -> "test byte ptr [rsi], 0"
[F6, 8F, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 6 -> mnem: "test byte ptr [rdi], 0x00" -> "test byte ptr [rdi], 0"
[F6, C8, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test al, 0x00" -> "test al, 0"
[F6, C9, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test cl, 0x00" -> "test cl, 0"
[F6, CA, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test dl, 0x00" -> "test dl, 0"
[F6, CB, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test bl, 0x00" -> "test bl, 0"
[F6, CC, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test ah, 0x00" -> "test ah, 0"
[F6, CD, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test ch, 0x00" -> "test ch, 0"
[F6, CE, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test dh, 0x00" -> "test dh, 0"
[F6, CF, 00] -> len_eq: true, need: 3 -> have: 2 -> mnem: "test bh, 0x00" -> "test bh, 0"
[F7, 08, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [rax], 0x00" -> "test dword ptr [rax], 0"
[F7, 09, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [rcx], 0x00" -> "test dword ptr [rcx], 0"
[F7, 0A, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [rdx], 0x00" -> "test dword ptr [rdx], 0"
[F7, 0B, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [rbx], 0x00" -> "test dword ptr [rbx], 0"
[F7, 0C, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [rax+rax*1], 0x00" -> "test dword ptr [rax + rax], 0"
[F7, 0D, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [0x000000000000000A], 0x00" -> "test dword ptr [rip], 0"
[F7, 0E, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [rsi], 0x00" -> "test dword ptr [rsi], 0"
[F7, 0F, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test dword ptr [rdi], 0x00" -> "test dword ptr [rdi], 0"
[F7, 48, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [rax], 0x00" -> "test dword ptr [rax], 0"
[F7, 49, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [rcx], 0x00" -> "test dword ptr [rcx], 0"
[F7, 4A, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [rdx], 0x00" -> "test dword ptr [rdx], 0"
[F7, 4B, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [rbx], 0x00" -> "test dword ptr [rbx], 0"
[F7, 4C, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 8 -> have: 4 -> mnem: "test dword ptr [rax+rax*1], 0x00" -> "test dword ptr [rax + rax], 0"
[F7, 4D, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [rbp], 0x00" -> "test dword ptr [rbp], 0"
[F7, 4E, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [rsi], 0x00" -> "test dword ptr [rsi], 0"
[F7, 4F, 00, 00, 00, 00, 00] -> len_eq: true, need: 7 -> have: 3 -> mnem: "test dword ptr [rdi], 0x00" -> "test dword ptr [rdi], 0"
[F7, 88, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [rax], 0x00" -> "test dword ptr [rax], 0"
[F7, 89, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [rcx], 0x00" -> "test dword ptr [rcx], 0"
[F7, 8A, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [rdx], 0x00" -> "test dword ptr [rdx], 0"
[F7, 8B, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [rbx], 0x00" -> "test dword ptr [rbx], 0"
[F7, 8C, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 11 -> have: 7 -> mnem: "test dword ptr [rax+rax*1], 0x00" -> "test dword ptr [rax + rax], 0"
[F7, 8D, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [rbp], 0x00" -> "test dword ptr [rbp], 0"
[F7, 8E, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [rsi], 0x00" -> "test dword ptr [rsi], 0"
[F7, 8F, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 10 -> have: 6 -> mnem: "test dword ptr [rdi], 0x00" -> "test dword ptr [rdi], 0"
[F7, C8, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test eax, 0x00" -> "test eax, 0"
[F7, C9, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test ecx, 0x00" -> "test ecx, 0"
[F7, CA, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test edx, 0x00" -> "test edx, 0"
[F7, CB, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test ebx, 0x00" -> "test ebx, 0"
[F7, CC, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test esp, 0x00" -> "test esp, 0"
[F7, CD, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test ebp, 0x00" -> "test ebp, 0"
[F7, CE, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test esi, 0x00" -> "test esi, 0"
[F7, CF, 00, 00, 00, 00] -> len_eq: true, need: 6 -> have: 2 -> mnem: "test edi, 0x00" -> "test edi, 0"
[FE, 10, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""
[FF, 38, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] -> len_eq: true, need: 0 -> have: 2 -> mnem: "" -> ""

some bugs with prefixes to

Thanks! I'll take a look at it later.

authors: CasualX KosBeg

repo: CasualX/lde


text:
🛑 Website is down

In e20d33a, Website (https://www.catacloud.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Website is back up in b6ba617 after 1 minute.

repo: Catacloud/statuspage


text:
🛑 Alist is down

In 53af69a, Alist (https://alist.hiripple.com) was down:

HTTP code: 530
Response time: 387 ms

Resolved: Alist is back up in 9abe5ec after 3 hours, 19 minutes.

repo: CelestialRipple/ripplelog


text:
🛑 Nextcloud is down

In bba8185, Nextcloud (https://nextcloud.hiripple.com) was down:

HTTP code: 502
Response time: 420 ms

Resolved: Nextcloud is back up in 84d914c after 10 minutes.


text:
🛑 Alist is down

In 5fbe97a, Alist (https://alist.hiripple.com) was down:

HTTP code: 530
Response time: 272 ms

Resolved: Alist is back up in 28ca3a9 after 1 hour, 23 minutes.


text:
Create MSBuild tasks for Yardarm

Motivation
Provide MSBuild tasks which can execute collect-dependencies and
generate commands.
Modifications

Move existing solution to the "main" subdirectory.
Add Yardarm.Build.Tasks to a new "sdk" subdirectory.

/merge

repo: CenterEdge/Yardarm


text:
[Feature] admin registrations

Proposal
Adds a list of registrations, uses #4960 and #5013 to make a simple but effective base.
Repercussions
Will make some PRs duplicates.

There seems to be no support for horizontal scrolling. This becomes a problem when the screen is really small (not that big of a deal), or when a registration has a retraction.
Retraction seem to just be dumped as a JSON string, which at times widens the column so much it prevents contributors column from rendering:

The complete stringified retraction dictionary seems unnecessary, as it is very hard to read and contains information such as approval_token, I would suggest a simplified representation in the list view (which would also help deter the column stretch problem) , and a better representation such as a table on the detail view.

Allowing horizontal scroll would also fix the problem if this is already defined functionality.

Quick question about desired functionality: how come Node tab and registration tabs work very differently? Unless I'm missing something, there is no way to filter the registration list view, which means if I was to look for a specific registration I would need to scroll until finding it. Seems to defeat the purpose of the admin dashboard. I would suggest either some filtering/searching, or a guid input field.

@Ghalko pass complete

@hmoco To address your comments backwards:

Desired functionality was for a list of registrations displaying most of the info displayed. Basically this is the desired list. All of these nodes are also in the Node search so if you have a guid you can find it in the nodes interface. As for searching/filtering beyond guids that is definitely a future improvement.
I didn't know what Sara wants to know about a retraction. On this list view I will just change it to True. But I will ask about details wanted in the node view. That should take care of horizontal scrolling issues.
The empty status is just because I am reusing a paginator that is also used for spam that requires a status. Refactoring the way spam works currently might enable less variable use.

All that was requested was is_retracted for retractions. So value will show up as True or False no more very long string dumps.

Cool!

authors: Ghalko hmoco


text:
[Hold][Feature] Refactor figshare [OSF-(4993, 5599, 5917, 6712)]

Purpose
Figshare is the last remaining third-party service addon to not use the ExternalAccount architecture. Also, their v1 API was deprecated in January 2016, and support for it will be removed ... sometime soon, probably, given that their v1 docs were taken down several months ago.
Changes

Figshare models updated to comply with generalized conventions, use general architecture.
Figshare views ″
Figshare frontend ″
Figshare serializer added
Figshare client rewritten to use their v2 API
Rename log and param for folder selecting (migration added)
APIv2 folder listing/setting support added
Generalized OSF/API tests added
Remove dead rubeus-type code

Side effects

All existing Figshare credentials on the OSF will be unusable, and we cannot migrate that data to reauthorize with their v2 API (received confirmation of this from a Figshare developer). This will affect approximately 300 users and 150 nodes.
OAuth mechanism may or may not work with figshare, see ticket 6712
It is unknown whether or not their OAuth2 implementation has expiring tickets -- whether or not we can / need to refresh them. This is difficult to determine because figshare has disallowed non-https OAuth callback urls, effectively prohibiting local development.

Notes

Log migration:

python -m scripts.figshare.migrate_folder_logs --dry

(Reason for [Hold]) Currently, Waterbutler does not support the Figshare v2 API, and expects v1 credentials from serialize_waterbutler_credentials. Things that rely on WaterButler (file listing, streaming, etc) will not work until it's updated.

Tickets
OSF-4933
OSF-5599
OSF-5917
OSF-6712
Maybe more ¯\_(ツ)_/¯

It's Autumn Cleaning time, so I'm closing this PR. Feel free to re-open when development becomes active again.

This is blocked by updating the WaterButler provider to figshare's v2 API, which is under active development. @TomBaxter expects that to hit CR sometime next week, maybe sooner. When that happens, this will no longer be blocked.

@mfraezz Conflicts need resolving.

@brianjgeiger Noted. It looks like just the fact that ownCloud went in recently -- a list in settings/defaults.py needs update.

Conflicting files
api/base/settings/defaults.py

authors: brianjgeiger mfraezz


text:
Output in the same order as defined

Is there any practical reason, or laid out by the spec, on why the fields get ordered when manifesting?
I plan on using the order of the fields to determine how kct applies resources to the cluster. But as the fields get ordered during manifestation, I'm a bit lost and can't find an alternative on what else to use. Honestly, setting my interests with kct aside, I find it a little strange to have the rendered fields in a different order than what I defined in my templates.
I checked that the official implementation does the same, and it seems that you aim to have similar output. I hope it isn't too much of a stretch to ask for this, but can we leave the order of the fields as defined in the templates?

I tried submitting the PR only to later realize that there are no guarantees over the order of the keys in the this_entries HashMap. Not even serde_json maintains the shape of the initial JSON - it orders the fields also.
use serde_json::Value;

fn main() {
	let data = r#"
	{
		"name": "John Doe",
		"age": 43,
		"phones": [
			"+44 1234567",
			"+44 2345678"
		]
	}"#;

	// Parse the string of data into serde_json::Value.
	let v: Value = serde_json::from_str(data).unwrap();

	let s: String = serde_json::to_string(&v).unwrap();

	println!("{}", s)
}

I'll elaborate on a better design for kct. Sorry for even bothering you with this beginner question. I'm still discovering Rust and remembering practices from college days when I worked directly with data structures. If you happen to have any idea, I'll be more than pleased to hear it and learn from you.

By jsonnet spec - fields in manifest should be ordered by alphanumeric
Also, json itself doesn't guarantee field order, per RFC 7159

An object is an unordered collection of zero or more name/value
pairs, where a name is a string and a value is a string, number,
boolean, null, object, or array.

Released this feature as experimental in https://github.com/CertainLach/jrsonnet/releases/tag/v0.5.0-pre1-test
Lets move all additional discussions to https://github.com/google/jsonnet/issues/903, as this i can't stabilize this in only mine implementation, it also should be implemented somewhere else

repo: CertainLach/jrsonnet


text:
Update ion token for performance tests

They can't run without a valid ion token. Looks like we missed updating it on the last release.
Also update the release documentation that mentions a separate google key. This is no longer needed.
https://github.com/CesiumGS/cesium-unreal/blob/Update-ion-token-for-performance-tests/Documentation/release-process.md#verify-the-code

Thanks @csciguy8! Sorry I forgot to update this during the release process.

repo: CesiumGS/cesium-unreal


text:
Error on mobile devices with lower RAM

Hello, I am using React Native WebView with Cesium.js and I am facing this error “Expected width to be greater than 0, actual value was 0” or “drawingBufferWidth must be greater than zero” on mobile devices with lower RAM. Now I am testing on Xiaomi Redmi 9A (2GB RAM) and this error always shows when I am trying to show the 3D tiles or sometimes when I want to camera fly to my current location.
My Cesium3DTileset options are:
   maximumScreenSpaceError: 64,    maximumMemoryUsage: 128,    dynamicScreenSpaceError: true,    skipLevelOfDetail: true,    immediatelyLoadDesiredLevelOfDetail: true,
*This error always shows when I am trying to open 3D Tileset Photogrammetry sandcastle on this device (in Chrome).

Hi @vlkpa, that error can show up when the WebGL context is lost, which can happen when the browser, or in this case the WebView, determines too many resources are being used.

2GB RAM

While WebGL has no minimum requirements, this is very much on the low end of hardware, so you will need to be careful about your configuration for the best performance on this device. I see you've already adjusted the maximumScreenSpaceError which is great. Here's a post on our community forum which goes through some additional configuration options for low-end hardware. The most important of those is probably decreasing Viewer.resolutionScale, which will render the scene at a lower resolution loading less data overall.
Cesium is a big project, and we use GitHub for feature requests and bug tracking exclusively. I'm going to close this issue, but please feel free to ask more on the Cesium Forum, where there are members of the community and developers from the team who can help. Thanks!

authors: ggetz vlkpa

repo: CesiumGS/cesium


text:
Update to flat configs and eslint 9

This PR updates to the new eslint standard of flat config files. This is a complete breaking change in favor of the new style. Let me know if there is any need for backwards compatibility here.

Since the extends property has been removed, the configs are now structured differently. The default export is now an object with a configs property for each type of configuration. This mirrors @eslint/js, the replacement for "eslint:recommended". The common rules got moved instead to common.js to facilitate.
Also note env has been removed in favor of specifying the sourceType and globals parameters. Where not already "inherited", we now specify these properties instead.

@mramato Would you mind taking a look?

Thanks, @ggetz. I'm happy to review. Do you have a branch in CesiumJS (or elsewhere) using this yet? I think seeing it end-to-end will be an extra level of checking to ensure we didn't miss anything. (I will also update one of my own projects as part of reviewing this)

Close to the top of my list now, sorry for the delay.

@ggetz Looks good to me. @jjspace would you like to give his a once over?

@jjspace Do you have some time to take a look?

Only took a quick look and nothing jumps out at me. Just had one small question above but it's not blocking. feel free to merge without me

authors: ggetz jjspace mramato

repo: CesiumGS/eslint-config-cesium


text:
SyntaxError: Unexpected token '.'

WSL ubuntu 22.04
I have already installed node.js,whose version is 12.22.12 and installed packages according to the guideline.
When I run obj2gltf command line,
it shows:
/usr/local/lib/node_modules/obj2gltf/node_modules/cesium/Build/CesiumUnminified/index.cjs:28559
} else if (defined_default(import_meta?.url)) {
^
SyntaxError: Unexpected token '.'
at wrapSafe (internal/modules/cjs/loader.js:915:16)
at Module._compile (internal/modules/cjs/loader.js:963:27)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
at Module.load (internal/modules/cjs/loader.js:863:32)
at Function.Module._load (internal/modules/cjs/loader.js:708:14)
at Module.require (internal/modules/cjs/loader.js:887:19)
at require (internal/modules/cjs/helpers.js:74:18)
at Object. (/usr/local/lib/node_modules/obj2gltf/node_modules/cesium/index.cjs:13:18)
at Module._compile (internal/modules/cjs/loader.js:999:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
How can I solve it?
Thanks for your help!

Hi @yeah222222. obj2gltf requires Node 14 or above. Are you able to upgrade?

I met the same error. How do I update?

Solved by updating node

authors: hiyyg lilleyse yeah222222


text:
Broken IGNORE/REJECT metrics

Describe the bug
Starting from v1.10.0 we're not able to see IGNORE/REJECT by topics, instead it's just IGNORE/REJECT in general. This is likely an issue of gossipsub after we upgraded in v1.10.0

This is from unstable 1k node

This is from stable test mainnet node

Expected behavior
Should be able to view IGNORE/REJECT messages by topic
Steps to reproduce
No response
Additional context
No response
Operating system
Linux
Lodestar version or commit hash
v1.10.0

This is a breaking change from https://github.com/ChainSafe/js-libp2p-gossipsub/pull/433/files
with this change, it's not possible to know which topic has % of ignore/reject/accept

waiting for #5869 to update these metrics on grafana

closed via #5899

repo: ChainSafe/lodestar


text:
Add DB metrics charts

Motivation
Add charts for https://github.com/ChainSafe/lodestar/pull/2741
Description
Last row in dashboard. Charts below are from Prater

Zoom in chart, clearly we are doing a lot of reads at epoch boundaries

Below with delta() function it shows the absolute value difference between scrapes. We read 2000-4000 blocks. Are the metrics right? Is our archiving function inefficient?


text:
Faster fastMsgIdFn using xxhash

Motivation

We want faster fastMsgIdFn(), it turns out it has a big impact on the I/O lagged issue

Description

Same to #4630 (use xx-hash for better performance compared to as-sha256) but use h64 instead of h32 to reduce hash collision, hence no memory issue

Closes #4603
could close #4600 due to its significantly faster sumitPoolAttestations request time
TODO

[ ] monitor the metrics on feat1 group

it's been 8h since I tested this branch on feat1 (vs feat2, both configured after_block_delay_slot_fraction as 3 in order to submit attestations right at 1/3 of slot, that's a very busy time to reproduce the missed attestation issue on goerli)

feat1 (this branch)

feat2 (unstable)

feat1 (this branch) - submitPoolsAttestation request time

feat2 (unstable) - submitPoolsAttestation request time

all other metrics are the same

also posting the benchmark in this PR
network / gossip / fastMsgIdFn
    ✔ fastMsgIdFn sha256 / 200 bytes                                      232180.2 ops/s    4.307000 us/op        -      84581 runs  0.404 s
    ✔ fastMsgIdFn h32 xxhash / 200 bytes                                   178[89](https://github.com/ChainSafe/lodestar/actions/runs/3205610042/jobs/5238344436#step:9:90)09 ops/s    559.0000 ns/op        -    1215000 runs   1.11 s
    ✔ fastMsgIdFn h64 xxhash / 200 bytes                                   1455604 ops/s    687.0000 ns/op        -     [90](https://github.com/ChainSafe/lodestar/actions/runs/3205610042/jobs/5238344436#step:9:91)8438 runs   1.01 s
    ✔ fastMsgIdFn sha256 / 1000 bytes                                     74906.37 ops/s    13.35000 us/op        -      57568 runs  0.808 s
    ✔ fastMsgIdFn h32 xxhash / 1000 bytes                                  1436782 ops/s    696.0000 ns/op        -     666281 runs  0.707 s
    ✔ fastMsgIdFn h64 xxhash / 1000 bytes                                  1142857 ops/s    875.0000 ns/op        -     731729 runs  0.[91](https://github.com/ChainSafe/lodestar/actions/runs/3205610042/jobs/5238344436#step:9:92)4 s
    ✔ fastMsgIdFn sha256 / 10000 bytes                                    8846.896 ops/s    113.0340 us/op        -       1779 runs  0.316 s
    ✔ fastMsgIdFn h32 xxhash / 10000 bytes                                441891.3 ops/s    2.263000 us/op        -     109369 runs  0.303 s
    ✔ fastMsgIdFn h64 xxhash / 10000 bytes                                554323.7 ops/s    1.804000 us/op        -     275290 runs  0.610 s

<3 thanks @tuyennhv !

This PR only reduce fastMsgIdFn time, it does not help I/O lag issue in #4600
For some reasons, metrics in feat1 is better than feat2 even I deploy unstable to both of them

authors: philknows tuyennhv


text:
feat: beacon node process electra attestations EIP-7549

Update validation for electra attestations from block
getBeaconCommittees() to retrieve multiple committees from a single attestation
getAttestingIndices() to retrieve a list of indices of validators who attested in the provided attestation

Part of #6341 and #6689

@tuyennhv all your feedbacks have been addressed, and the changes are reflected in nc/7549. Please continue the review in #6689 .

:tada: This PR is included in v1.22.0 :tada:


text:
Cow: Watch one2note.com

Cow requests the watch of the watch_keyword one2note\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

one2note\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Nick in Charcoal HQ

authors: SmokeDetector metasmoke

repo: Charcoal-SE/SmokeDetector


text:
Fastnlight: Watch immigrationquestion[\W_]*+com(?<!immigrationquestion.com)

Fastnlight requests the watch of the watch_keyword immigrationquestion[\W_]*+com(?<!immigrationquestion\.com). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

immigrationquestion[\W_]*+com(?<!immigrationquestion\.com) has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


text:
Revert "Restrict new user messages"

No longer needed, now that MS allows us to silence these messages.

Coverage remained the same at 65.558% when pulling 51197f0c581fa1ecc928f4fae4b2a667ea2c3dfb on NobodyNada:patch-1 into ba5809ff85aeea297e0f6041d5467a016b8aa83a on Charcoal-SE:master.

It wasn't about seeing them, it was about rate-limiting Smokey.

!!/approve

authors: ArtOfCode- K-Davis1 NobodyNada coveralls


text:
Mast: Watch pillsvilla.com

Mast requests the watch of the watch_keyword pillsvilla\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

pillsvilla\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Daniil in Charcoal HQ

Approved by Daniil in Charcoal HQ


text:
Ollie: Watch cryptoalertscam.com

Ollie requests the watch of the watch_keyword cryptoalertscam\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

cryptoalertscam\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Spevacus in Charcoal HQ


text:
Ethan: Watch embersummers519(?:@gmail.com)?

Ethan requests the watch of the watch_keyword embersummers519(?:@gmail\.com)?. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

embersummers519(?:@gmail\.com)? has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


text:
Pilot6: Watch e-gifts.by

Pilot6 requests the watch of the watch_keyword e-gifts\.by. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

e-gifts\.by has been seen in 2 true positives, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


text:
[Bug] The environment variable GOOGLE-API_KEY has been set, but an error message will appear indicating Request failed

Bug Description
The environment variable GOOGLE-API_KEY has been set, but an error message will appear indicating Request failed
ANTHROPIC-API_KEY is also the same
Steps to Reproduce
1.visit vercel.com ,add environment variable GOOGLE-API_KEY
2.use nextchat get error
Expected Behavior
want to use gemini
Screenshots
No response
Deployment Method

[ ] Docker
[x] Vercel
[ ] Server

Desktop OS
No response
Desktop Browser
No response
Desktop Browser Version
No response
Smartphone Device
No response
Smartphone OS
No response
Smartphone Browser
No response
Smartphone Browser Version
No response
Additional Logs
No response

plz check you internet connection

authors: chenjiangbo fred-bf

repo: ChatGPTNextWeb/ChatGPT-Next-Web


text:
Merge 2 resolver.CustomURLManager objects into 1 in twitch's custom resolver

Currently we declare two separate custom resolvers for twitch clips Which is inefficient.
This can be easily avoided by applying simiar approach with regular expression like in Discord resolver or a domain map in BetterTTV one.
I could try fixing this on my own to learn something new
Code I'm talking about:
https://github.com/Chatterino/api/blob/5bc8059a719035d7169d2b127aad19c234c2fa5c/internal/resolvers/twitch/resolver.go#L74-L106

By the way, should I include Check and Run function split into separate files in one PR or should it be done separetly?

repo: Chatterino/api