NSME in ErrorVerifier._checkForMissingRequiredParam.

When trying to repro issues with @required (https://github.com/flutter/flutter/issues/3843), I was greeted with this (using Adam's patch).
NoSuchMethodError: method not found: 'getField'
Receiver: null
Arguments: ["reason"]
#0      Object._noSuchMethod (dart:core-patch/object_patch.dart:42)
#1      Object.noSuchMethod (dart:core-patch/object_patch.dart:45)
#2      ErrorVerifier._checkForMissingRequiredParam (package:analyzer/src/generated/error_verifier.dart:4260)
#3      ErrorVerifier.visitInstanceCreationExpression (package:analyzer/src/generated/error_verifier.dart:832)
#4      InstanceCreationExpressionImpl.accept (package:analyzer/src/dart/ast/ast.dart:6127)
#5      ConditionalExpressionImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:2557)
#6      RecursiveAstVisitor.visitConditionalExpression (package:analyzer/dart/ast/visitor.dart:1455)
#7      ErrorVerifier.visitConditionalExpression (package:analyzer/src/generated/error_verifier.dart:543)
#8      ConditionalExpressionImpl.accept (package:analyzer/src/dart/ast/ast.dart:2551)
#9      NamedExpressionImpl.visitChildren (package:analyzer/src/dart/ast/ast.dart:7396)
#10     RecursiveAstVisitor.visitNamedExpression (package:analyzer/dart/ast/visitor.dart:1749)
#11     NamedExpressionImpl.accept (package:analyzer/src/dart/ast/ast.dart:7391)

It looks like in this case the constantValue for the @required annotation is null. In error_verifier:
ElementAnnotationImpl annotation = _getRequiredAnnotation(param);
...
DartObject constantValue = annotation.constantValue;
String reason = constantValue.getField('reason')?.toStringValue();

Easy to guard against but before I do, I'd be curious why this is happening (and only sometimes).
@scheglov @bwilkerson : thoughts?

Is the param from a different library than the one being verified?
If so, then this is a well known issue. The short story is that we evaluate constants in two cases: (1) when producing a fully resolved AST in a library all of the constants in that library will have had values computed for them, and (2) if the value is needed in order to compute the value of another constant required for the first reason.
As a result, if you're accessing the value of a constant outside the current library you have to first ensure that the library containing the constant has been fully resolved. However, requiring that as part of the task model will have some negative implications for performance, so we should talk about how best to accomplish this.

Thanks Brian.  You're spot-on that this param is defined in a separate library (flutter).  Unfortunately this is by far the common case and compromises the value of the "details" field in @required.
We should talk about approaches but in the short term I'll add a guard unless you have other thoughts.
Aside: in this specific case will the value be in the summary when we summarize the flutter library?

... in the short term I'll add a guard ...

Sounds good to me.

... will the value be in the summary ...

I think the current answer is "no", summaries don't contain constant values, but do have everything necessary to evaluate them.

I think the current answer is "no", summaries don't contain constant values, but do have everything necessary to evaluate them.

I'm thick.  (Or didn't ask the right question 😄 .)  Does this mean summaries will help here or not?

No, they won't help.

😞
I keep imagining that summaries will come barreling over the horizon to solve ALL of our problems!  Ah well.  In that case, yes, let's talk about how to get this fixed or remove the "details" param from @required.

Yeah, summaries are not a silver bullet.
The heart of the issue here is that we need to do as little work as necessary to get the results we need, but this is a case where we need more work to be done than previously. If we can do the work lazily then we'll can still minimize the amount of work we have to do. If not, then we end up doing the work in case we need it, which we won't most of the time.

Guard landed in https://github.com/dart-lang/sdk/commit/63b7b6f3c2524435a5d24776ef36ad5e32a776c9.
Bumping over to you @bwilkerson to update once you've got the new API we discussed in place.
Thanks!

That API was added in https://codereview.chromium.org/1966323002/, but has not yet been published.

Fixed as of https://github.com/dart-lang/sdk/commit/23b02bc35112ebb955e006b87b3fbe03c5e071d7; tested w/ https://github.com/dart-lang/sdk/commit/e1fad5cddbbf23cf3c6c4592d76e0654171f0f3a.
We should be good to go for the next DEV release. 👍
cc: @abarth


How to get the area breakdown of plugins in Vexii?

Hi,
I'm trying to check the area breakdown of the plugins in Vexii (like the area of IntAlu, Lsu or Branch).
Is there a way to generate plugins as separate verilog modules? Or are there any other ways to analyze their area?

Hi,
I would say, the only way is to run the synthesis flow between a configuration with and without a feature to get its "real" ressource usage. It may not be faisable for everything thing as there may be some coupling between a few plugins.
Using verilog module to contains logic feature get messed up a lot with hierarchy flattening.

Just made some data analysis on the impact of generation options on the area (LUTs+FFs):

Basically, I generated 1024 Vexii designs with random configurations and ran a Vivado script to synthesize them, then got the area report. For boolean options (like with-late-alu), the blue points are those that set the option to true, and the red ones are false. For integer options (like xlen and lanes), the red points are with higher values.
Could be a reference for those who want to resize their Vexii I hope 🤔.

Nice :D
Thanks ^^
1024 designs, how long did that toke XD ?

5 minutes per design, so around 4 days in total XD.
Can be faster if do it in parallel.


[5.4] Fix Blade @parent issue

This is an attempt to fix https://github.com/laravel/framework/issues/10068, currently if a variable was passed to the view that contains the string @parent, Blade tries to compile this string as a @parent directive causing appending the parent content into the view if a parent section exists, or if not the @parent string will be stripped from the response.
This PR attempts to fix this by replacing the actual @parent directive with a different placeholder, the change is breaking because any @parent that exists in the blade file will be replaced, so for example this echo {{ '@parent' }} won't work.

But the new placeholder can still be abused though, right?

Yeah if you have a ##parent-placeholder## string it'll be a problem, but I don't think this string is common, unlike @parent.

It doesn't fix the potential security problem we have here were users can inject this string.

We've never actually found that this is a "security" problem, tbh. I do agree however that it would be nice if we could just totally eliminate the issue instead of changing to a different string. I've forgotten why that is somewhat difficult.

@taylorotwell well the point is that the replacement of @parent has to happen after the sections actually render, so if any of the dynamic content contains the string @parent it'll be replaced.
This PR https://github.com/laravel/framework/pull/10122 was trying to fix using ob_get_length() but was reverted for some reason, I assume this approach won't work if you use @include inside a section thus the length of the content changes causing the replacement to break.
This PR replaces a common string @parent with a less common one ##parent-placeholder## and thus decreases the possibility of encountering the issue.

Maybe you could add some random suffix, e.g. '##parent-placeholder-'.Str::random(16).'##', this shouldn't be too hard to implement and we would be sure to be on the safe side.

The random token may work to further make it tougher to run into the issue and prevent people from easily guessing the token. Though I'm not sure there is really even a security issue.

I don't think it should be considered as a security issue, I consider it a limitation on using the string @parent which will be replaced with '' or the value of the parent section content if any.

Refs subsequent https://github.com/laravel/framework/commit/16f72a5a580b593ac804bc0b2fdcc6eb278e55b2 :)

To fit the issue, can you consider somehow putting @parent related placeholders outside the string so no one can dynamically inject it?


Add support for translate.google.cn

The cn domain is available in mainland China. It's much faster than the proxy solution. Could you please add support for that? Thanks!

The API we use is actually on a separate domain translate.googleapis.com (rather than google.com), which should be available in mainland China already.
Or are you having problems accessing translate.googleapis.com?

That url is a 404 for me here. Does that mean it's blocked?

404 is normal, and it implies that the API server is approachable.
It seems to me trans should work for you without any proxy.

Thanks for clarification! I remember It didn't work last year. Anyway, it works now. Thanks for this great app!
谢谢！


Managing multiple sites

Is it possible to manage multiple sites using the same admin instance in netlify? If not, how complicated would it be to add such a feature (and is it on the roadmap already?)? I don't have much experience with Ember, but this is one feature I'm looking for. The multiple backends feature that netlify has seems really cool., and generally, it seems like a very nice looking UI for static site generation.

Hi, i'm closing this due to inactivity. Please feel free to reopen if you want to add to the discussion.


Step-by-step instructions for serving opt-175b on alpa

System information

Alpa version: Latest
Are you willing to contribute it (Yes/No):
Yes

Describe the new feature and the current behavior/state
I have only access to a slurm cluster with v100s. I wonder whether there is step-by-step instructions on setting up ray and alpa for using slurm. BTW, the following link for running ray with slurm seems to be broken.
https://alpa.ai/tutorials/opt_serving.html#:~:text=Before running the command below%2C start Ray on the cluster following this guide. You can check
Will this change the current API? How?
No,
Describe alternatives you've considered
Additional context

@zfchenUnique could you follow this tutorial to deploy Ray: https://docs.ray.io/en/master/cluster/vms/user-guides/community/slurm.html ?

@ddxxdd-code Per our conversation, your effort on Slurm will help address this issue.

closed due to inactivity


Docker Container

for all the people who require to run pfasta in a containerized way
-> i prepared a simple container to do such:
https://hub.docker.com/repository/docker/plaquette/pfasta/
thank you for the tool - it has been quite useful!
best,
j.

Thank you, I didn't know that any actually uses this project. I'll add a link to your container in the readme.


Upgraded to Cake 0.26.1, StyleCop.MSBuild 5.0.0

Upgraded to Cake 0.26.1, StyleCop.MSBuild 5.0.0

pull request stalled - closing


Simplify for scalability

This adapater is for sql-server, add syntax works on sql server, but not on fabric, its expensive to do drop and recreate big tables

@axellpadilla can you take a look at the 1.8.0rc1 and see if that address this issue?

@cody-scott from my understanding of the changes yes, need to merge and deploy it to my local to test it but looks ok, closed because any problem should patched on the new 1.8.0rc1


Signout URL not matching the one suggested

Hi!
Was going through the tutorial, thank you a lot for your great work.
Noticed the logout URL does not match the one suggested on the registration page: https://docs.microsoft.com/en-gb/azure/active-directory/develop/scenario-web-app-sign-user-app-registration?tabs=aspnetcore
Also, tweaked the image name from logo_net.png to logo_NET.png as I noticed the preview in GitHub "Preview Changes" wasn't fetching it.
Hope it helps, thank you.
Alberto

@albertodenatale : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@jmprieur Hi, could you review the proposed changes to your article? Thanks.

#sign-off

Thanks @albertodenatale
and thanks @ktoliver for the reminder.
We are changing the public API of Microsoft.Identity.Web (per the ASP.NET Core team's request), and therefore the articles will be updated soon. I postponed work on these articles. But I agree that this one was long overdue.

Thanks @albertodenatale
and thanks @ktoliver for the reminder.
We are changing the public API of Microsoft.Identity.Web (per the ASP.NET Core team's request), and therefore the articles will be updated soon. I postponed work on these articles. But I agree that this one was long overdue.

Thank you @ktoliver, @jmprieur
@jmprieur I had watched your videos at Identity Videos, congratulations for the great content.


Set serverRegistryResourceProviderEnabled to false in the default fhir-server-config

Is your feature request related to a problem? Please describe.
Our performance guide recommends disabling this for performance reasons, and our default (if its not specified) is to have it off I think.  But our default fhir-server-config.json that gets installed has it on (presumably for CI testing reasons).
Describe the solution you'd like
Set this to false in our default fhir-server-config.json (the one that gets used by default after installing a new server / executing docker run).
Describe alternatives you've considered
keep it set to true in this default config file
Acceptance Criteria

GIVEN [a precondition]
AND [another precondition]
WHEN [test step]
AND [test step]
THEN [verification step]
AND [verification step]

Additional context
Add any other context or screenshots about the feature request here.

I thought about this a bit... perhaps this should be part of an epic to identify what we want our default to really be...

QA plan:

build the docker image with our default config
confirm the default/fhir-server-config.json has serverRegistryResourceProviderEnabled set to false

Separately:  remove the value from the config and confirm the value still defaults to false.

Started container as described in fhir-install/README.md.
Run
podman exec -ti fhir-server bash
vi config/default/fhir-server-config.json

Confirmed that
"serverRegistryResourceProviderEnabled": false,

Also, after enabling trace for FINE, we can see the search query executed when serverRegistryResourceProviderEnabled=true but not when it is set to false. Similarly, it is confirmed that the search query is not executed when the parameter is removed, thus confirming the default behavior is serverRegistryResourceProviderEnabled=false.


Listing Management Table View - Owner and Org sorting are broken

In Table View, owner and org sorting are broken if the list includes a Draft that is missing an Owner or Org.
Drafts can be saved without specifying an Owner or an Org.

Passed testing in Master (IE9/11, FF, CH). Admin creates draft listing (without owner org), Admin selects Menu/Listing Management, From Table View ensure Column Settings include Organization, Select Organization column and confirm draft listing is first (null Org listing).


Google+ button markup needs data-href specified

Code needs to be changed to

since otherwise the button is prepopulated with the wrong URL when your site is using hashbangs (or anchors).

Better late than never!


ZSYTRF yields wrong result when OpenBLAS is built using CMake

Brief
For version 0.3.16 - 0.3.21, if I build OpenBLAS with cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON, ZSYTRF can yield wrong result.
But the result is correct for version 0.3.15, or if I simply build OpenBLAS with make.
How to Reproduce
It can be tested with the following code
#include <complex>
#include <iostream>
#include <lapacke.h>

int main()
{
    std::complex<double> A[9]{
        {2, 2}, {0, 0}, {1, 1},
        {0, 0}, {2, 2}, {0, 0},
        {1, 1}, {0, 0}, {2, 2}
    };
    lapack_int ipiv[3]{ 0 };

    auto info = LAPACKE_zsytrf(LAPACK_COL_MAJOR, 'L', 3, (lapack_complex_double*)A, 3, ipiv);

    std::cout << "info = " << info << '\n';
    std::cout << "ipiv = " << ipiv[0] << ", " << ipiv[1] << ", " << ipiv[2] << '\n';
    std::cout << "A =\n";
    std::cout << A[0] << '\n';
    std::cout << A[1] << ", " << A[4] << '\n';
    std::cout << A[2] << ", " << A[5] << ", " << A[8] << '\n';

    return 0;
}

It prints
info = 0
ipiv = 1, 2, 3
A =
(2,2)
(0,0), (2,2)
(0.5,0), (0,0), (2,2)

Whereas the correct A after factorization should be
(2,2)
(0,0), (2,2)
(0.5,0), (0,0), (1.5,1.5)

It's not the only error case, I just picked a simple one for demonstration. And I can reproduce it on various platforms, including Linux+GCC, Windows+MinGW64, Intel 8700, Intel E5 2620 v3, AMD Ryzen 5900HX
My Question
Is my way of build OpenBLAS using CMake wrong, or there are some bugs in the project's CMake scripts?

Offhand the only difference between the build systems should be that a CMAKE "Release" build defaults to -O3 while the Makefile predefines only -O2

@martin-frbg I tried adding -DCMAKE_C_FLAGS_RELEASE=-O2 -DCMAKE_Fortran_FLAGS_RELEASE=-O2 to CMake Release build, the result was still wrong. (I checked with the terminal output that it is using -O2 instead of -O3)
I also tried CMake Debug build, it didn't work neither.
I haven't figured out how to let make build with -O3 for cross verification.
Another thing I just noticed is that when linked against OpenBLAS built by CMake, the above sample programm can take up to about 2 seconds if OMP_NUM_THREADS and OPENBLAS_NUM_THREADS are unspecified, but it finished instantaneously when the 2 envs are set to 1. Whereas when linked against OpenBLAS built by make, it always finished instantaneously no matter whether the 2 envs are set to 1 or unspecified.

Reproduced but no idea yet (you can uncomment the COMMON_OPT line in Makefile.rule and set -O3 there but it appears to be unrelated)

RelWithDebInfo build type is -O2

bisecting now. (There also appears to be a problem with the HAVE_feature settings in the universal intrinsics when building for a specific TARGET with cmake, could even be related)

Bisect points to my commit d6d7a668 of May 27, 2021 "Add shortcuts for (small) cases that do not need expensive buffer allocation" although the choice of build system should play no role there.

Looks like the Makefile build does not actually override the (Z)SYR from LAPACK with OpenBLAS' reimplementation (that has been there since the days of GotoBLAS), while the CMAKE build does. The change in the Makefile build occured with #1046 , the update of LAPACK to 3.7.0 six years ago - for some unknown reason that contributor decided to disable a number of OpenBLAS functions that are also present in the netlib LAPACK. (Incidentally this was also one of the last commits from this long-time contributor before contact with him was lost)

@martin-frbg Thanks. That's really useful knowledge.

@martin-frbg is the intent to eventually fully move to CMake?

No, the plan is for both to be supported and equivalent (which means I will prepare a PR to add the NO_WARMUP=1 default), and perhaps even add support for one of the newer alternatives like meson at some later time.


Decoder trace generation

This PR implements decoder trace generation and related changes. This includes:

[x] Implement trace generation for most columns the decoder component. Trace for 5 more decoder columns is left for another PR. These columns do not affect decoder logic and will be mostly used for degree reductions.
[x] Add merge() and hash_span_block() methods to the hasher component. (will need to create an issue for adding tests for these functions).
[x] Update hasher trace generation so that row address always starts at 1. (will need to create an issue for adding a boundary constraint for this).
[x] Implement tests for the decoder trace.

I meant to ask about one other thing - do we need to have a boundary constraint on the starting row address of the hasher? I haven't thought about this in depth (and I think we're ok), but it crossed my mind as I was reviewing, and you may have thoughts since you've been looking at this deeply, so it seemed worth mentioning

do we need to have a boundary constraint on the starting row address of the hasher?

I think we do because we are now assuming that the address starts at 1 (if the prover sets it to higher values, it's not a problem, but setting it to 0 may lead to some unintended consequences). I actually mention this in the 3rd point in the PR description above :)

do we need to have a boundary constraint on the starting row address of the hasher?

I think we do because we are now assuming that the address starts at 1 (if the prover sets it to higher values, it's not a problem, but setting it to 0 may lead to some unintended consequences). I actually mention this in the 3rd point in the PR description above :)

Ah, so you do! Sorry, I didn't reread the description after finishing the review, so it's been a couple days. Yep, that makes sense - we definitely do need the constraint.


International Soil Radiocarbon Database v1.0 - Lawrence 2019

URL for data package:

https://zenodo.org/records/2613911

Full citation:

Lawrence, C. R., Beem-Miller, J., Hoyt, A. M., Monroe, G., Sierra, C. A., Stoner, S., Heckman, K., Blankinship, J. C., Crow, S. E., McNicol, G., Trumbore, S., Levine, P. A., Vindušková, O., Todd-Brown, K., Rasmussen, C., Hicks Pries, C. E., Schädel, C., McFarlane, K., Doetterl, S., Hatté, C., He, Y., Treat, C., Harden, J. W., Torn, M. S., Estop-Aragonés, C., Asefaw Berhe, A., Keiluweit, M., Della Rosa Kuhnen, Á., Marin-Spiotta, E., Plante, A. F., Thompson, A., Shi, Z., Schimel, J. P., Vaughn, L. J. S., von Fromm, S. F., and Wagai, R.: An open-source database for the synthesis of soil radiocarbon data: International Soil Radiocarbon Database (ISRaD) version 1.0, Earth Syst. Sci. Data, 12, 61–76, https://doi.org/10.5194/essd-12-61-2020, 2020.

Abstract given to describe the data:

Radiocarbon is a critical constraint on our estimates of the timescales of soil carbon cycling that can aid in identifying mechanisms of carbon stabilization and destabilization and improve the forecast of soil carbon response to management or environmental change. Despite the wealth of soil radiocarbon data that have been reported over the past 75 years, the ability to apply these data to global-scale questions is limited by our capacity to synthesize and compare measurements generated using a variety of methods. Here, we present the International Soil Radiocarbon Database (ISRaD; http://soilradiocarbon.org/, last access: 16 December 2019), an open-source archive of soil data that include reported measurements from bulk soils, distinct soil carbon pools isolated in the laboratory by a variety of soil fractionation methods, samples of soil gas or water collected interstitially from within an intact soil profile, CO2 gas isolated from laboratory soil incubations, and fluxes collected in situ from a soil profile. The core of ISRaD is a relational database structured around individual datasets (entries) and organized hierarchically to report soil radiocarbon data, measured at different physical and temporal scales as well as other soil or environmental properties that may also be measured and may assist with interpretation and context. Anyone may contribute their own data to the database by entering it into the ISRaD template and subjecting it to quality assurance protocols. ISRaD can be accessed through (1) a web-based interface, (2) an R package (ISRaD), or (3) direct access to code and data through the GitHub repository, which hosts both code and data. The design of ISRaD allows for participants to become directly involved in the management, design, and application of ISRaD data. The synthesized dataset is available in two forms: the original data as reported by the authors of the datasets and an enhanced dataset that includes ancillary geospatial data calculated within the ISRaD framework. ISRaD also provides data management tools in the ISRaD-R package that provide a starting point for data analysis; as an open-source project, the broader soil community is invited and encouraged to add data, tools, and ideas for improvement. As a whole, ISRaD provides resources to aid our evaluation of soil dynamics across a range of spatial and temporal scales. The ISRaD v1.0 dataset is archived and freely available at https://doi.org/10.5281/zenodo.2613911 (Lawrence et al., 2019).

Links to any papers associated with the data:

Data description paper: https://essd.copernicus.org/articles/12/61/2020/

How the dataset was found:

Conversation with Dr. Kathe Todd-Brown and Dr. Katherine Heckman. Sent by Dr. Heckman.

Dataset points of contact:

Primary/official contact: Corey R. Lawrence from the US Geological Survey, Geosciences and Environmental Change Science Center. Can be reached via email at<EMAIL_ADDRESS>Secondary contacts: Dr. Kathe Todd-Brown<EMAIL_ADDRESS>from the University of Florida and Dr. Katherine Heckman<EMAIL_ADDRESS>from the US Forest Service.

Data license and intellectual rights:

This work is licensed under the Creative Commons Attribution 4.0 International, which allows re-distribution and re-use of a licensed work on the condition that the creator is appropriately credited. Read more about it at: https://creativecommons.org/licenses/by/4.0/legalcode

Link to corresponding GitHub:

https://github.com/International-Soil-Radiocarbon-Database/ISRaD/

Excellent. We know that ISRaD has layer level SOC variables (and a whole lot more!). These annotations will likely build off of metadata already in ISRaD. When you are ready to tackle this come talk with me for additional instructions.

I updated the ISRaD annotations 1f1e2201576ee1140d81c1bc3640d9cc1236a0e6 and move the R scripts over to an RMD file instead 13eb4389475193f5840561706c3d1314f0dba808
@Kate-Heckman what I see as next steps are to

[ ] merge the column annotations (where with_entry == '--') with the table to create a long format; checking column names match annotation file and control vocabulary on the is_type and of_variable to make sure there are no typos
[ ] add ISRaD metadata to the annotations file including download URL and full citation.
[ ] move this over this over to a readISRaD function
[ ] create basic plot and report out on the content of the data in the report
[ ] send over to ISCN4 branch for soc mapping and merge

Thoughts?

Kate is clarifying for herself:

merge the column annotations (where with_entry == '--') with the table to create a long format; checking column names match annotation file and control vocabulary on the is_type and of_variable to make sure there are no typos
With the data
Long format  = stick transposed data to annotations

add ISRaD metadata to the annotations file including download URL and full citation.
Look at other read functions - they return data and then annotations - keep them separate

move this over this over to a readISRaD function

create basic plot and report out on the content of the data in the report
Example of "basic plot" in ISCN4 code:
https://github.com/ktoddbrown/SoilDRaH/tree/28-iscn4/vignettes/articles

send over to ISCN4 branch for soc mapping and merge


feat(dap): add extra for dap js

Did you check the existing dap integration?
https://github.com/LazyVim/LazyVim/blob/main/lua/lazyvim/plugins/extras/lang/typescript.lua#L66

nvim-dap-vscode-js is actually no longer needed with the latest microsoft-jsdebug. IT's now a full-blown dap server.

Ok so I will close this PR and if I find a nice way to add the test config to the existing integration I will then open a new PR. Thanks


Reading and processing android sensor data using python with CSV read()

Article checklist
Attention
Our Peer Reviewer and Content Moderator teams do NOT provide any revisions services. All revisions and edits should be completed on your own forked repo (as to not take up room in the queue) in order for our team to review them all in a timely manner.
ANY ARTICLE SUBMITTED WITH GLARING ERRORS WILL BE IMMEDIATELY CLOSED.

As a rule of thumb - please be sure to only submit articles (pull requests) that are fully polished and ready to be published. Be sure to go through our resources documents for extra and 3rd party (vetted) resources to help improve overall technical writing.

Pre-submission checks

Please ensure that you have only one open topic suggestion (issue) + in-review article (linked pull request) at a time. This will ensure that we complete the review process in a timely manner from inception to publishing

If you have not already, please go over our Resources Page for more tips and tricks on how to improve your overall technical writing so reviews are swifter, increase the chance of a payout and provide more value to our readers.

For first-time contributors and for more details on our submission guidelines, see our Contributing Guidelines.

Formatting and structure checks

[x] Have you used the correct folder and file structure? - see Contribution Guidelines

[x] Is your article properly formatted in Markdown? - see Github Markdown guide

[x] Have you used our preferred heading structure? - H3 (###) and up

[x] Does your article follow any of the suggested structure formats? - see example formats

[x] Is your article over 750 words? - Tool: Wordcounter.net

[x] Is the article you are submitting an in-depth and unique article? Does it go beyond what is in the official docs and what is covered in other blog sites. See these articles as examples.

[x] Does your article provide enough value and detail about your topic? - Articles should be clear, accurate, and fully explained.

[x] Can your article be understood by beginners? - Assume the audience is smart but has no prior exposure to the common terminology in your article.

[x] Have you included a hero image that is 600x400 pixels, under 300KB in size, and have the copyright to use it? - Tools: Pixlr Image Editor for resizing and Unsplash for Creative Commons images

Grammar & plagiarism checks

[x] Have you spellchecked and grammar checked your article? - Tools: Write&Improve - ProWritingAid - Grammarly
[x] Please place your article through a 3rd party plagiarism checker. We suggest using Quetext, this tool is free and has a daily limit. We typically accept articles with 10% or less.
[x] Have you checked your article for readability? - Tool: Hemmingway
[x] Have you added sources for quotes and images that aren't yours?

Technical checks

[x] Are your code snippets properly formatted for syntax highlighting - see Syntax guide
[x] Have you checked your code runs correctly and you've highlighted all necessary dependencies for installation?
[x] Are the software programs and packages you're highlighting in your article up to date, using current versions and not deprecated?

Topic suggestion this closes

Remove the backticks and add the issue number below to link and close your Topic Suggestion (issue) when your article has been published (PR has been merged). See this video for more details.

`This closes #6159

Finally, delete the article checklist notes in blockquotes and submit your PR. We look forward to reviewing your article.

Hello @josephodhis ,
Thanks for submitting this PR.
Your PR has entered our reviewing queue. Please wait until a peer-reviewer pings you to get started.
Meanwhile, we suggest you to go through existing approved PRs/published articles to see if you have missed out anything.
Thanks.

Plagiarism check complete

@paulodhiambo changes made.

Hello @Kayere I made the corrections, didn't notice the contributor made some changes after completing tech review.

Hi @josephodhis, I am done with the final review. Just one request before I merge this PR. Please change your author avatar - upload a professional picture.

@Kayere i have uploaded a new avatar.


Problem in converting ASDU not topical to pivot

There is a conversion issue when converting from ASDU Not Topical to Pivot
If NT (Not Topical) flag is set to 1 in the incoming ASDU, then in the resulting Pivot object should be Validity = "questionnable" as per the spec but currently Validity = "good",
Here is a pivot object example:
{
   "GTIS":{
      "ComingFrom":"iec104",
      "SpsTyp":{
         "stVal":1,
         "q":{
            "DetailQuality":{
               "oldData":1
            },
            "Source":"process",
            "Validity":"good"
         },
         "t":{
            "SecondSinceEpoch":1677674607,
            "FractionOfSecond":2197815,
            "TimeQuality":{
               "clockFailure":1,
               "leapSecondKnown":1,
               "timeAccuracy":10
            }
         }
      },
      "Identifier":"S25105471",
      "Cause":{
         "stVal":3
      },
      "TmOrg":{
         "stVal":"genuine"
      },
      "TmValidity":{
         "stVal":"invalid"
      }
   }
}

I guess this is the issue that has already been fixed: https://github.com/fledge-power/fledgepower-filter-iec104topivot/commit/4495396bbff010b01037105bbd6b18bc6015d396
I created a PR to merge the fix to main.

OK, then I can close this issue


Add privacy preserving tutorial

Look at “view file”And yes, “make html”Envoyé de mon iPhoneLe 26 sept. 2023 à 13:04, Jordan Fréry @.***> a écrit :
@jfrery commented on this pull request.
In doc/tutorials/privacy_preserving.rst:

@@ -0,0 +1,97 @@
+#############################################
+Privacy Preserving Inference with Concrete ML
+#############################################

+Concrete ML is a specialized library allowing the execution of machine learning models on encrypted data through Fully Homomorphic Encryption (FHE) <https://www.youtube.com/watch?v=FFox2S4uqEo>, thereby preserving data privacy.
How do you verify that? make docs?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>


Add protobq.MessageSaver

feat: add protobq.MessageSaver
feat: update API to match other proto encoding APIs

I suppose you'll squash the commits before merging?

@Jassob Not necessary IMO, they all make sense individually

@Jassob Not necessary IMO, they all make sense individually

Maybe, but they don't contribute much either. I don't think it is interesting to see eventual missteps in a project, unless they are already committed. As such I prefer to squash commits to reduce the number of commits in a PR and the history, thereby increasing signal-to-noise ratio.

I see your point, but in this case I don't think a single squashed commit will make sense given the series of commits, so I will keep them as is.

I don't advocate a single commit, rather that some are squashed and some are left as is, but don't let me stop you.

Thanks! :raised_hands:


ValueError while loading Cosmo_23.5 from tensorflow_datasets

In notebooks/PartII-GenerativeModels.ipynb, the first code cell under Step I: Preparing training data and the first code cell under Bonus: Denoising Score Matching should be
dset = tfds.load('Cosmos/Cosmos_23.5', split=tfds.Split.TRAIN)

but it should be
dset = tfds.load('Cosmos/23.5', split=tfds.Split.TRAIN)

Otherwise we'll see the error:
ValueError: Failed to construct dataset cosmos: BuilderConfig Cosmos_23.5 not found. Available: ['23.5', '25.2']

It should be fixed now, thanks @jwuphysics for the issue!


DP-108 Add mock implementations for messaging and persistence

This introduces a new project, cheddar-integration-mocks. These mocks are intended for use in service (component) tests. The mocks are all in-process, allowing for simple test verification by examining the mock state.
Signed-off-by: Steffan Westcott<EMAIL_ADDRESS>

@clicktravel-steffan : Completed review. No obvious issues , although it it is fairly difficult to visualises and confirm the package structure in the GIT layout but on first pass it all looks in the right place. I checked very small amount of the actual code as the classes and tests have already been reviewed. Ready to go in when ready.


Set up CI to test PRs for all TCKs

We have workflows defined to test PRs against a subset of the modules in this repository. We should cover them all.

Note, I've changed the title to setup "CI" as in some cases we might want to use TeamCity instead. However, we can still run those on PR's.


thank you

Open source project is very useful, thanks. Please continue to develop. :)

+1!

Thank You Note is not an issue. Hence closing the issue


[CAMEL-15530] fixes bug in camel aws2-s3 component

JIRA issue: https://issues.apache.org/jira/browse/CAMEL-15530

Can you create acpr for 3.4.x too?

thanks for checking so fast @oscerd, here is the PR on 3.4.x https://github.com/apache/camel/pull/4210


MathematicalSystems

There is a common system representation that is shared by a few control projects such as JuliaReach and Dionysos.jl in https://github.com/JuliaReach/MathematicalSystems.jl/. As discussed after your talk in Paris, it would be useful if OptimalControl.jl was supporting the system to be representing in this form.
cc @adrienbanse @schillic @mforets

Thanks for the comment, we will take a look at it.  This seems effectively a nice idea.

@blegat Hi Benoît, many thanks for the feedback. Sure, it definitely makes sense to be able to exchange between various high level representations / modelling formats. We were aware of MTK.jl, not of MathematicalSystems.jl which looks very nice and general. Two points here:
(i) The ConstrainedBlackBoxControlContinuousSystem type seems tailored to describe general (deterministic and explicit) systems
$$ \dot{x}(t) = f(x(t), u(t)) $$
plus state constraints, $x(t) \in X$, and control constraints, $u(t) \in U$. Is it also possible to add

finite dimensional parameters to be optimised (such as the final time, $t_f$, whenever it's free)
boundary constraints, $(x(0), x(t_f)) \in B \subset \mathbf{R^{2n}}$ (where $n$ is the state dim)
mixed constraints, $(x(t), u(t)) \in Z \subset \mathbf{R}^n \times \mathbf{R}^m$ (where $m$ is the control dim)

For instance, how would you describe this example with MathematicalSystems.jl?
@def ocp begin
    tf ∈ R, variable
    t ∈ [ 0, tf ], time
    x ∈ R², state
    u ∈ R, control
    tf ≥ 0
    -1 ≤ u(t) ≤ 1
    q = x₁
    v = x₂
    q(0) == 1
    v(0) == 2
    q(tf) == 0
    v(tf) == 0
    0 ≤ q(t) ≤ 5
    -2 ≤ v(t) ≤ 3
    q^2(t) + v^2(t) + u^2(t) ≤ 100
    ẋ(t) == [ v(t), u(t) ]
    tf → min
end

(ii) A strong motivation for us to map OptimalControl.jl models towards other descriptions is the availability of associated optimal control solvers; or, more specifically, of discretisation tools from an abstract optimal control description towards a mathematical program (that can eventually feed an optimisation solver). Are such tools available in MathematicalSystems.jl ecosystem?

The aim in MathematicalSystems.jl has been to make it as thin or lightweight as possible, yet with expressive power to specialize on system types if the developer needs so (hence the ugly struct names, though there is a macro meant to simplify the process of defining the system).
Addressing some of your questions:

The package has some discretize features meant to go from *Continuous to *Discrete systems.

Additional functionalities are a bit scattered around such as in ReachabilityAnalysis.jl which has methods to apply automatic differentiation leveraging MTK, or even to solve associated ODEs. Again, this is a bit scattered so if someone is using this in their package it would probably be nicer to just outsource some functionalities to a separate Julia pkg (or integrate them into MathematicalSystems as optional deps).

Hi @mforets ; thanks for the input. I see that there are indeed some discretisation features for affine control systems. Going to general nonlinear systems is key to us (most of our applications are indeed from nonlinear optimal control), plus having a good blend of differential geometric tools to address both direct and indirect methods. There has been very nice progress on top of JuMP with InfiniteOpt.jl, though the description remains a bit far from what a mathematician would write.
That the DSL is smoothly operating with efficient solvers (optimisation, in particular) is also very important for us. At the moment, this is not completely true for MTK, e.g. Convergence will occur 🤞🏾


Feature/39 user callbacks

Introduction of JavaScript callbacks, solving ticks tooltip formatting (#39, #48)

Hey, how about update some test/example to use this new way to pass functions do chart.js?

Thanks... some very simple examples can be found here:
https://github.com/moberwasserlechner/vaadin-chartjs-demo/pull/5

Thanks for this looks cool. Is it ready to be merged?

Sry for the silence. You say that

The approach is pretty much the same as the one Vaadin Charts is using internally.

Is it the same. Could there be problem with the licence Vaadin Charts is commerical and incompatible with MIT.
Do you or anyone else know?

My 2 cents:
Approach is same, source doesn't.
I don't believe that Vaadin has the patent of it, because it is a common way to work with distributed services (client/server arch).
Conclusion: no licensing problem.
Some time ago Oracle (Java) tried to issue Google (Android) using a common way to handle IO:
int readed;
byte[] buffer =  new byte[1024];
while ((readed = input.read(buffer)) != -1) {
   // use data
}

Oracle lost, because it is a common way to work with Java IO.

@kegoe @dyorgio thanks for your answers.


Change span type and names to fit with convention

Goal

Testing

Release Notes

WHAT:
WHY:
WHO:

#484  👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bidetofevil and the rest of your teammates on  Graphite


Error handling

Catching and displaying errors caught from iobio backend, and mosaic backend.  For each error, report my interpretation of the problem, action items, help contact information, and the console/ service error.  Also removed references to the old backend in EndpointCmd.js

quarantest build successful. Demo link at
http://1a201f8f.quarantest.iobio.io


Contradictory Documentation

Details
I'm looking at the privacy page.
There's a note that says that private documentation is still viewable if someone has a URL.
But then, down below, under the Private header, it says that it will 404 if an unauthorized user tries to look.
These seem contradictory to me. But, I don't know much about the project so I'm hesitant to make a PR.
If someone gives me some direction, I'll change the wording to whichever one is true.

The first paragraph is about the generated documentation, the second is about the project page. For example, the docs project https://docs.readthedocs.io/en/latest/ anyone who knows that url can view the docs, but only authorized users can see the project page https://readthedocs.org/projects/docs/.
The docs project is public by the way.

@samlobel hi, with the above explanation it is cleared enough? or maybe we can be more explicit about that on the docs? We will love for you to help us improve the docs if you consider.

Closing this as the user hasn't responded or given more information, feel free to reopen with more information if you are still having this problem :).


Server performance with multiple camera sensors

CARLA Version: 0.9.10
OS: Linux Ubuntu 18.04
Hello,
I am interested in using CARLA to create multiple camera sensors and render all their perspectives at a high resolution, for instance 1920x1232 pixels. For this reason, I have run some performance tests to assess the performance of the simulator according to the number of cameras. The client used to connect to the server and create the camera sensors was programmed in C++.
The tests were performed in a i9-9900K<EMAIL_ADDRESS>32GB RAM; RTX 2080Ti. The simulation was running on epic mode since the graphic quality is important.
At first, the server was running with 60 FPS with one client but no sensor. It immediately dropped to 30 FPS with the creation of one camera sensor. With two camera sensors, it dropped to 20 FPS. And with three camera sensors, approximately to 15 FPS. When the desired number of 4 camera sensors was include on the simulation the FPS dropped to around 13 FPS.
I also experimented reducing the sensor resolution and increasing the number of camera sensors in a way that the total number of generated pixels covered the same area as for 4 cameras. For instance:  4x1920x1232 = 16x960x616. So, 16 cameras were created with a resolution of 960x616 and the server dropped to 7 FPS. Then, with 64 cameras at 480x308, to 2 FPS.
The FPS measurements were done with a static ego and no other actor in the scenario (Town03). The results can be seen on the graph below:

We observed that the GPU memory usage (%) tend to increase as the number of cameras at high resolution increases. However, drastically increasing the number of camera sensors does not result in a higher consume of GPU resources, despite achieving the worst FPS in these scenarios. In fact, the highest number of cameras (64) with the lowest resolution consumed the least GPU memory and demanded about 70% of the GPU usage. Meanwhile, the four cameras at high resolution only consumed only 25% of GPU memory, but demanded about 90% of the GPU usage. These results can be seen on the graphs bellow:

The average CPU usage (%) remained basically constant, no matter the resolution or the number of cameras. The RAM memory usage (%) varied slightly, achieving the maximum with the four cameras at high resolution.

Having these results presented, I would like do discuss a few things:

Does this limitation strictly rely on the Unreal Engine implementation?
What could be done to achieve higher FPS with high resolution cameras (at least with 4)?

I would appreciate your feedback.
Thank you,
Fabio Reway
Maikol Drechsler

Another thing you might have to look out for is IO bottlenecks when saving allot of data to disk.  We tried running several captures on a local non-SSD (i.e. magnetic drive) and a (remote) NFS share and ran into bottlenecks.

Another thing you might have to look out for is IO bottlenecks when saving allot of data to disk.  We tried running several captures on a local non-SSD (i.e. magnetic drive) and a (remote) NFS share and ran into bottlenecks.

Another thing you might have to look out for is IO bottlenecks when saving allot of data to disk. We tried running several captures on a local non-SSD (i.e. magnetic drive) and a (remote) NFS share and ran into bottlenecks.

I'm not saving the image data to the disk, but streaming it.

Another thing you might have to look out for is IO bottlenecks when saving allot of data to disk. We tried running several captures on a local non-SSD (i.e. magnetic drive) and a (remote) NFS share and ran into bottlenecks.

I'm not saving the image data to the disk, but streaming it.

Hello!
we noticed a similar behaviour, when using multiple RGB cameras (3). The server frame rate drops to 5 FPS, every camera "costs" 15 frames/sec. :(
When additional traffic actors are spawned, the situation gets even worse.
We are not saving data to disk, they are grabbed by the C++-API and streamed to a network. The simulation is also running in asynchronous mode....
We use a RTX3070, which is utilized by 25%.
The i9-10 Core CPU is utilized by 75%.
Carla keeps much of the resources unused...
Any ideas?
Regards,
Chris

@bernatx could you have a look at this please?

Hello!
I am also experiencing a similar problem with LiDAR sensors.
I am using an RTX 5000 GPU.
Carla Version: 0.9.10
Scenario and settings:
Without spawning any vehicles and adding LiDAR sensors to the infrastructure (all sensors are added through a single client).
Synchronous mode with fixed delta seconds as 0.1
Server FPS (appx):
With 0 LiDARs: 80 fps
With 1 LiDARs: 55 fps
With 4 LiDARs: 35 fps
With 3 LiDARs: 21 fps
With 4 LiDARs: 15 fps
GPU Utilization (appx):
With 0 LiDARs: 35%
With 1 LiDARs: 29%
With 4 LiDARs: 20%
With 3 LiDARs: 15%
With 4 LiDARs: 12%
Carla is not utilizing the resources completely.
Any ideas?
Regards,
Karthik

Hi!
Is there a way to support you analyzing the problem?
We would like to use the simulation as a "real-time" application and would like to get a achieve a higher framerate...
What framerates can be achieved?

We found that the performance running carla on Ubuntu 20.04 is better, but the main problem still exists....

Hi, we're experiencing similar issues and found out using Wireshark, that at high data bandwith the boost TCP communication is the bottleneck, especially when running in sync mode. The larger the data, the more packages need to be sent - we think that shared memory communication could help tackling this issue.

Hi, we are also experiencing a similar problem. Following results is tested with carla/PythonAPI/util/performance_benchmark.py in a computer with Ubuntu 18.04, i9-11th, 32G RAM, RTX-3080ti.

Hi,we are also experiencing similar problem.Is there any update information?

@dongkeyan Carla 0.9.14 has be published. It add multi-gpu feature, which is very helpful for rendering performance.

@JosenJiang would you be willing to post some statistics on multiple GPU usage? I am planning to purchase some extra GPU-s for multiple RGB sensor rendering. What sort of FPS are you getting with different sensor setups? 2, 3, 4, 5, 6 cameras. Thank you.

That would be very interesting for me, too!

same question. I wonder whether can carla use GPU up to 100% utils to increase performance?


bug: Warning: Command @parboxrestore  has changed.

I get the following warning when running the code from the documentation:
test.tex|| LaTeX Warning: Command \@parboxrestore  has changed.

To reproduce, download convtran.sty into the directory, call it with \usepackage{} and run the following:
\begin{convtran}
  \turn{D:} O:h (I k-)=
  \turn{A:} =Dz that make any sense to you?
  \turn{C:} Mn mh. I don’ even know who she is.
  \turn{A:} She’s that’s, the Sister Kerrida, [who,
  \turn{D:} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[.hhh
  \turn{D:} Oh [\underline{that’s} the one you to:ld [me you bought
  \turn{C:} ~~~[Oh-~~~~~~~~~~~~~~~~~~~~~~[
  \turn{A:} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[\underline{Ye:h}
\end{convtran}

It still compiles and I can safely ignore it for now.
Also I just want to say this is an excellent package and I hope it can be included in ctan / texlive eventually.

I'm glad you are finding the package useful.  Can you confirm that you get that warning when you run this minimal example?
\documentclass{article}
\usepackage{convtran}
\begin{document}
\begin{convtran}
  \turn{D:} O:h (I k-)=
  \turn{A:} =Dz that make any sense to you?
  \turn{C:} Mn mh. I don’ even know who she is.
  \turn{A:} She’s that’s, the Sister Kerrida, [who,
  \turn{D:} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[.hhh
  \turn{D:} Oh [\underline{that’s} the one you to:ld [me you bought
  \turn{C:} ~~~[Oh-~~~~~~~~~~~~~~~~~~~~~~[
  \turn{A:} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[\underline{Ye:h}
\end{convtran}
\end{document}

I ask because I don't get the warning on that document (though I can make the warning appear if I change some other things).

Ah my fault, I should have tested it more before reporting.
The minimal configuration you provided worked fine.
It seems to be a conflict with  \usepackage{csquotes} which is required for the apa7 class. The following also compiles without warning, it is only when \usepackage{csquotes} is added that it becomes an issue:
\documentclass[man]{apa7}
\usepackage[style=apa]{biblatex}
\usepackage{convtran}
\title{test}
\begin{document}
\maketitle
\section{Test}
\subsection{Test}
Here is an example of a Jeffersonian transcription using \verb!contrav.sty!.
\begin{convtran}
  \turn{D:} O:h (I k-)=
  \turn{A:} =Dz that make any sense to you?
  \turn{C:} Mn mh. I don’ even know who she is.
  \turn{A:} She’s that’s, the Sister Kerrida, [who,
  \turn{D:} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[.hhh
  \turn{D:} Oh [\underline{that’s} the one you to:ld [me you bought
  \turn{C:} ~~~[Oh-~~~~~~~~~~~~~~~~~~~~~~[
  \turn{A:} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[\underline{Ye:h}
\end{convtran}
\end{document}

As an aside, it might be beneficial to mention in section 2.3 of the documentation that gb4e needs to be called after convtran for it to work properly for the numbered examples.

On Feb 8, 2024, at 01:17, walkergareth @.***> wrote:
I'm glad you are finding the package useful. Can you confirm that you get that warning when you run this minimal example?
\documentclass{article}
\usepackage{convtran}
\begin{document}
\begin{convtran}
\turn{D:} O:h (I k-)=
\turn{A:} =Dz that make any sense to you?
\turn{C:} Mn mh. I don’ even know who she is.
\turn{A:} She’s that’s, the Sister Kerrida, [who,
\turn{D:} ~~~~~~~~~~~~~~[.hhh
\turn{D:} Oh [\underline{that’s} the one you to:ld [me you bought
\turn{C:} ~[Oh-[
\turn{A:} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[\underline{Ye:h}
\end{convtran}
\end{document}
I ask because I don't get the warning on that document (though I can make the warning appear if I change some other things).
—
Reply to this email directly, view it on GitHub https://github.com/walkergareth/latex/issues/1#issuecomment-1933863964, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF2IXWWRRBQZNN3ES3WCHX3YSSX4ZAVCNFSM6AAAAABC5UOEMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZTHA3DGOJWGQ.
You are receiving this because you authored the thread.

Yes, it seems like the warning appears if csquotes is loaded before lineno (SE). I've put a note in the documentation, and added a note about gb4e.


Docs for server timing

I love seeing some server timings in enhance, but I can't find any documentation about what they each mean.
Would it be possible to get some docs for what each of these are measuring:

enhance-api
enhance-elements
enhance-html
enhance-preflight

In particular enhance-elements and enhance-html as those two are the ones that take the longest (at least in my current situation).

That's a great callout!
I'll outline those here and we can add to the docs shortly.

enhance-preflight

times your preflight function (if one exists)
src

enhance-api

times your route's api function (if one exists)
src

enhance-elements

times the search and load for your elements, and possibly Enhance's defaults like <head>
src

enhance-html

times the call the enhance-ssr given that the elements have been loaded and initial state is ready
src

Note: these enhance-* timers do not overlap, but not all timers that are present are exclusive of each other. Basically, they don't all have to add up to the total server time.

What sort of times are you seeing for elements and html?
-elements scales as your element count goes up. Should be linear. I believe it's cached; so requests when the server is "warm" should show quicker times.
That said, we have been working on ways to speed that up - but it hasn't been too painful in our tests... yet.
I have found -html to slow down when each element has its own <style> block. It's definitely something I'd like to make faster but I think it relates to our CSS parsing, so that may be a bigger change.

Yeah, it definitely does cache. When it's not cached, I've been seeing some in the 300-400ms range, but I'm not super worried about it because the caching seems pretty solid and frankly the bigger issue are the dynamoDB queries themselves.

Just wanted to say this was wildly helpful, @tbeseda. I stumbled on a route with very high TTFB. Looking at the server timings, enhance-api as killing me (2+ seconds). I wrapped my route methods in my own server timing codes, and they were nowhere near that 2s (~240ms). Got me thinking about what else might be an issue and got a hunch that maybe it was the data added to the response.
Sure enough, stumbled on a massive chunk of data that was being added, that I wasn't even using at all. Removed that, the 2s enhance-api dropped to 300ms. 💪


added new bridges

Hi,
I added some new bridges. These are my first but thoroughly tested.
Kind regards
Holger

Thank you! Next time I will use phpcs before committing.


Add TaskSeq.tryitem, item, tryLast, last, tryHead, head, tryPick, pick, tryFind, find, choose, filter, isEmpty and more

First batch of the functions mentioned in #22, see title.
Implemented the following (WIP):

[x] isEmpty
[x] tryExacltyOne
[x] exactlyOne
[x] head
[x] tryHead
[x] last
[x] tryLast
[x] item
[x] tryItem
[x] filter
[x] filterAsync
[x] choose
[x] chooseAsync
[x] pick
[x] pickAsync
[x] tryPick
[x] tryPickAsync
[x] find
[x] tryFind
[x] findAsync
[x] tryFindAsync

The signatures ~(WIP, will update)~ completed:
val tryHead: taskSeq: taskSeq<'T> -> Task<'T option>
val head: taskSeq: taskSeq<'T> -> Task<'T>

val tryLast: taskSeq: taskSeq<'T> -> Task<'T option>
val last: taskSeq: taskSeq<'T> -> Task<'T>  // may raise

val tryItem: index: int -> taskSeq: taskSeq<'T> -> Task<'T option>
val item: index: int -> taskSeq: taskSeq<'T> -> Task<'T>  // may raise

val tryExactlyOne: source: taskSeq<'T> -> Task<'T option>
val exactlyOne: source: taskSeq<'T> -> Task<'T>  // may raise

val choose: chooser: ('T -> 'U option) -> source: taskSeq<'T> -> taskSeq<'U>
val chooseAsync: chooser: ('T -> #Task<'U option>) -> source: taskSeq<'T> -> taskSeq<'U>
val filter: predicate: ('T -> bool) -> source: taskSeq<'T> -> taskSeq<'T>
val filterAsync: predicate: ('T -> #Task<bool>) -> source: taskSeq<'T> -> taskSeq<'T>

val tryPick: chooser: ('T -> 'U option) -> source: taskSeq<'T> -> Task<'U option>
val tryPickAsync: chooser: ('T -> #Task<'U option>) -> source: taskSeq<'T> -> Task<'U option>
val pick: chooser: ('T -> 'U option) -> source: taskSeq<'T> -> Task<'U>  // may raise
val pickAsync: chooser: ('T -> #Task<'U option>) -> source: taskSeq<'T> -> Task<'U>  // may raise

val tryFind: predicate: ('T -> bool) -> source: taskSeq<'T> -> Task<'T option>
val tryFindAsync: predicate: ('T -> #Task<bool>) -> source: taskSeq<'T> -> Task<'T option>
val find: predicate: ('T -> bool) -> source: taskSeq<'T> -> Task<'T>  // may raise
val findAsync: predicate: ('T -> #Task<bool>) -> source: taskSeq<'T> -> Task<'T>  // may raise

Important note: I have disabled parallel test runs due to a race condition that was hard to pin down. Dozens of commits and reverts have been squashed back into one, to keep a clean history.
See #25 for further investigation.


chore: add optional schema prop to plugins

Following conversations with maintainers of third-party clients using SVGO, something that has come up is that SVGO does not expose its default behavior or accepted parameters in a way other clients can act on.
This PR introduces a new optional property for plugins called schema, which is a JSON Schema that describes the parameters a plugin accepts and any constraints it may have.
This is intended to imitate Option Schemas in ESLint. Custom Rules in ESLint can expose a schema property, which is a JSON Schema that describes the options the rule supports. Exactly what this PR is adding.
This has numerous uses:

Third-party clients can now check what parameters are available or validate against them.
Parameter documentation will live closer to the parameters.

svg/svgo.dev will have to move the exported schema property to the plugins respective documentation page.

We can improve the help pages in CLI by describing the parameters in more detail, including constraints.

This is just a minimal migration/implementation of these types, but there is more to do to clean things up, improve constraints, etc.
To notable things we should also do (doesn't have to be in the JSON Schema):

Provide human-readable names for plugins.
Expose which plugins are enabled by default. (preset-default doesn't do this atm)

Related

https://github.com/jakearchibald/svgomg/issues/431#issuecomment-1874980317
https://github.com/sonnyp/OhMySVG/pull/10#discussion_r1452783046

CC
@jakearchibald

I would rather schema be generated from TS or TS be generated from schemas than have both in the same codebase.

@KTibow See: https://github.com/jakearchibald/svgomg/issues/431#issuecomment-1834054041

Right, well there are libraries that let you get a typedef rather easily from the JSON schemas introduced in this PR.

FromSchema
The FromSchema method lets you infer TS types directly from JSON schemas:
import { FromSchema } from "json-schema-to-ts";

const dogSchema = {
  type: "object",
  properties: {
    name: { type: "string" },
    age: { type: "integer" },
    hobbies: { type: "array", items: { type: "string" } },
    favoriteFood: { enum: ["pizza", "taco", "fries"] },
  },
  required: ["name", "age"],
} as const;

type Dog = FromSchema<typeof dogSchema>;
// => Will infer the same type as above

Interesting, that has a really cool interface. Though, that would also mean shipping a dependency on json-schema-to-ts which is a bit eh.
In general, I would prefer a static solution if we were going to do something like that. Regardless, I've given this one a brief look, and it looks like it only works in TypeScript sources, so the particular library isn't going to work for us anyway
I can get the library to work easily in TypeScript sources, but in JavaScript, nope. I can literally take the same JavaScript file, and tsc will be fine if the plugin ends with .ts but will complain if it ends with .js even though I have the same and valid code in both cases.

I'll work on the schemas. I guess there'll be some work to make the docs pull from these schemas too?
Right now, title is only in the mdx files. I'm going to move that into the plugin module too, since I need that text in SVGOMG.

Is there a particular reason applyTransforms.js doesn't have an exported name?

@jakearchibald @KTibow
It was not forgotten. The plan was to eventually make it a standalone plugin, and the logic was migrated out of convertPathData until it's considered ready to be used as such.
I don't know what was pending before it's considered ready to be a standalone plugin, though. However, it is not part of the public API.

Cool. I'll use the absence of the name to detect plugins that aren't public.

Ohh nice! Is the order of plugins important? preset-default seems to have them in a specific order, whereas builtin has them in alphabetical order.

Ohh nice! Is the order of plugins important? preset-default seems to have them in a specific order, whereas builtin has them in alphabetical order.

Shoot… you're right. I was actually thinking about doing the following as part of the requirement:

Expose which plugins are enabled by default. (preset-default doesn't do this atm)

We can update the createPrefix utility in SVGO to add a property which we'll export, containing an array of plugins in the preset in the order they execute in. The createPreset function also receives said array, so it's just a matter of returning it.
For example, the following, though I'm happy to discuss the interface. We could just use a preset property which is immediately assigned to the plugin array rather than separate properties.
  export const createPreset = ({ name, plugins }) => {
    return {
      name,
+     preset: true,
+     plugins
      fn: (ast, params, info) => {
        const { floatPrecision, overrides } = params;
        const globalOverrides = {};
        if (floatPrecision != null) {
          globalOverrides.floatPrecision = floatPrecision;
        }
        if (overrides) {
          const pluginNames = plugins.map(({ name }) => name);
          for (const pluginName of Object.keys(overrides)) {
            if (!pluginNames.includes(pluginName)) {
              console.warn(
                `You are trying to configure ${pluginName} which is not part of ${name}.\n` +
                  `Try to put it before or after, for example\n\n` +
                  `plugins: [\n` +
                  `  {\n` +
                  `    name: '${name}',\n` +
                  `  },\n` +
                  `  '${pluginName}'\n` +
                  `]\n`,
              );
            }
          }
        }
        invokePlugins(ast, info, plugins, overrides, globalOverrides);
      },
    };
  };

Currently I'm exporting the plugins from preset-default: https://github.com/jakearchibald/svgo/blob/chore/schema/plugins/preset-default.js#L39-L76
Then over in SVGOMG:
import { plugins as defaultPlugins } from 'svgo/plugins/preset-default';
import presetDefault from 'svgo/plugins/preset-default';
import { builtin } from 'svgo/lib/builtin';

const builtinSet = new Set(builtin);
builtinSet.delete(presetDefault);

const allPlugins = new Set([
  // Get the initial order from preset-default
  ...defaultPlugins,
  // Add the rest in whatever order
  ...builtinSet,
]);

I'm happy to keep doing this, or the preset/plugins thing.

Before continuing, just want to say thank you for taking this on!

Currently I'm exporting the plugins from preset-default: https://github.com/jakearchibald/svgo/blob/chore/schema/plugins/preset-default.js#L39-L76

I would prefer if we took the approach I proposed (which would achieve a similar interface) as it's easier to maintain on our side in the case that we make more presets, which is an idea that's been thrown around a few times.
With the way you did it, while it does mean the list is defined once which is great, it's simpler if presets didn't have to know to export another property imo.
Then you'd do:
import presetDefault from 'svgo/plugins/preset-default';
import { builtin } from 'svgo/lib/builtin';

const builtinSet = new Set(builtin);
builtinSet.delete(presetDefault);

const allPlugins = new Set([
  // Get the initial order from preset-default
  ...presetDefault.plugins,
  // Add the rest in whatever order
  ...builtinSet,
]);

No problem, I'll do that.

I'm going to add a title export from each plugin, which will be the same as the title used in the mdx pages.
For description, how do you feel about:
export const description = `Adds attributes to the outer most [`<svg>`](https://developer.mozilla.org/docs/Web/SVG/Element/svg) element in the document. This is not an optimization and will increase the size of SVG documents.`;

As in, supporting markdown here. I don't mind either way.

@jakearchibald

I'm going to add a title export from each plugin, which will be the same as the title used in the mdx pages.

I'm not into the idea tbh. I'm happy for SVGO to make itself easier for frontend applications to wrap around, but I don't want to expose that much of a public interface that we'd be exporting the same property multiple times for different clients.
I'd like for our plugins to keep JS friendly plugin IDs, then you could either map them on your end, or use a function to create a UI friendly name from the plugin ID.
It's not the perfect solution, but I think it's better than introducing things that don't serve SVGO's needs into our public API. A frontend application's interface is very flexible, but as a library once we introduce new properties, we're pretty much stuck with it for a while, and exporting a name and title separately isn't something I want stuck in SVGO for now.
I was also hesitant to add UI-friendly names for individual parameters when I started working on this, but I opted to run with it since the parameter is meant to be a JSON Schema and that's part of the spec.

For description, how do you feel about:

In general, I'm fine with this. However, we should probably save that for when SVGO is prepared to do it's v4 release. (Drastically changes the structure, length, and markup of the property, which is part of our public interface.)

A lot of this description only applies to the JS API, and wouldn't apply to the UI. I'm not sure what to do about that, because the docs need the JS details, but they don't make sense in SVGOMG.

You'd probably want to override specific strings on your side for when something we do doesn't make sense for you.
That way, you can use our docs when it's available, but you can override it when your adaptation/wrapper doesn't match our interface 1-2-1.
We definitely can't handle this on our side, as SVGOMG is just one example of a third-party client, and we can't maintain docs here that are specific to your client when other clients might represent this differently.
Probably something like your t() (function most i18n libraries export) that lets you swap out, normalize, or localize strings that SVGO give you.

I'm going to add a title export from each plugin, which will be the same as the title used in the mdx pages.

I'm not into the idea tbh. I'm happy for SVGO to make itself easier for frontend applications to wrap around, but I don't want to expose that much of a public interface that we'd be exporting the same property multiple times for different clients

My intent was that the docs would use this exported name too, rather than duplicating it.

My intent was that the docs would use this exported name too, rather than duplicating it.

When I said duplicating, I meant the name vs title, two properties that mean the same thing but aimed at different interfaces.
I don't want to clutter the JavaScript interface with these details. That should be managed outside of it, imo. For the docs, we'll either use the exported names, or map them to human-readable names in svgo.dev, but not pollute the JavaScript interface with properties exclusively for documentation/clients. That's better managed externally.


Workaround for  #10766

Checklist

[x] I'm asking a question
[x] I've looked through the README and FAQ for similar questions
[x] I've searched the bugtracker for similar questions including closed ones

Question

I have the problem described in https://github.com/ytdl-org/youtube-dl/issues/10766, but I had activated ISS only for curiosity, and since then, even after deactivating it (I don't need it), youtube-dl binaries on my PC fail with this error:
C:\Users\piez>youtube-dl -v [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['-v'] Traceback (most recent call last):   File "__main__.py", line 19, in <module>   File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmp378onz6j\build\youtube_dl\__init__.py", line 474, in main   File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmp378onz6j\build\youtube_dl\__init__.py", line 441, in _real_main   File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmp378onz6j\build\youtube_dl\YoutubeDL.py", line 419, in __init__   File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmp378onz6j\build\youtube_dl\YoutubeDL.py", line 2345, in _setup_opener   File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmp378onz6j\build\youtube_dl\utils.py", line 2288, in make_HTTPS_handler   File "C:\Python\Python34\lib\ssl.py", line 439, in create_default_context   File "C:\Python\Python34\lib\ssl.py", line 390, in load_default_certs   File "C:\Python\Python34\lib\ssl.py", line 377, in _load_windows_store_certs PermissionError: [WinError 5] Accesso negato
(unless I have administrative privileges). I need to use the youtube-dl exe version for compability with MPC-HC (https://github.com/clsid2/mpc-hc/issues/301), what I have to do to make youtube-dl work again?

https://github.com/ytdl-org/youtube-dl/issues/17048#issuecomment-407117427

But before it worked, and ISS now is deactivated. What has changed in my system?


Support multiple trajectories in LoadMap

Depends on #569. (merged) and probably #576 (closed, not merged) #603 (merged, replaces #576)
Also change the prototype of AddSubmapFromProto's argument "initial_pose" to "pose". The loaded pose may be the result of prior optimisation. "initial pose" is a term I associate with an unoptimized pose.
Partially replaces #541.
Note: LoadMap will be renamed in #554 to LoadState.

Updated, PTAL

Also, if there's too much stuff going on, feel free to suggest me to split the PR.

Updated.

Ok, should be ready. I also rebased on top of master.

Thanks for the PR @ojura!

No problem, that you for putting up with my PR spam :-)


When onMessage returns true it does not close the websocket

This is because there is a break, instead of websocket.close(), this is an easy fix.

this is an easy fix.

Have you jinxed yourself :eyes:

For your example, (am running this in bug-fix ebebb9e8a15afb9d0784602ca84c45fc1d7e1adc)
import times
import websocket // Used for connecting to WebSockets

let pub main = () |> ([] -> cmd[()] {
	let websocketTest = websocket.connect({
		onOpen: [send: websocket.send] -> cmd[bool] {
			print("Open!")
			let _ = send("hi")!
			while (true) {
				let _ = times.sleep(10000)!
			}
			return true
		}
		onMessage: [send: websocket.send message: str] -> cmd[bool] {
			print(message)
			let _ = send("hello")!
			return message == "hello"
		}
	}, "wss://echo.websocket.org")!
})

It appears to do the following:

Connection opens.
onOpen prints Open!.
onOpen sends hi then asynchronously sleeps indefinitely.
The server sends hi back.
N's native websocket module runs onMessage given hi.
onMessage prints hi.
onMessage sends hello.

Asynchronously, the server sends hello back. The Python websockets library queues this in the async iterator of messages.

onMessage returns False.
N's native websocket module runs onMessage given hello as given by the Python library's async iterator.
onMessage prints hello.
onMessage sends hello.

Asynchronously, the server sends hello back. This is also queued.

onMessage returns True.
The N websocket module thus closes the websocket connection. This is correct behaviour.
However, there's another hello message queued. We don't break the loop, so we continue and run onMessage on the remaining queued messages, in this case given hello.
onMessage prints hello.
onMessage sends hello. However, the websocket connection is closed, so this raises a runtime exception.

So the question is whether we should call onMessage on queued received messages after onMessage requests that the connection be closed. If so, then we can just break out of the loop on close.

Also, regardless, it'll still be possible to call send after the websocket connection closes (eg using parallel). This should not throw a runtime exception.
Ideally, had we had better foresight, we should've made send return a cmd[result[(), err]] where err is some error type (maybe it could just be some unspecified type that can't be read directly in N). However, send returns a cmd[()], so we can't really do anything about it if we want to preserve backwards compatibility. (Unless we want to consider this a bug and fix its type signature.)
It probably should be fine if send silently ignores errors. What do you think?

So if we choose to discard queued messages after onMessage decides to close the websocket connection, this should be a fairly trivial fix. We can just break out of the loop after closing it.
https://github.com/nbuilding/N-lang/blob/ebebb9e8a15afb9d0784602ca84c45fc1d7e1adc/python/libraries/websocket.py#L119-L120
                        if close:
                            await websocket.close()
                            break

We can silently ignore errors from sending to a closed websocket connection by try-excepting it.
https://github.com/nbuilding/N-lang/blob/ebebb9e8a15afb9d0784602ca84c45fc1d7e1adc/python/libraries/websocket.py#L93-L98
            async def send_msg(message):
                if debug:
                    print(
                        f"[{url}] {Fore.CYAN}send{Style.RESET_ALL} {Fore.GREEN}{message}{Style.RESET_ALL}"
                    )
                try:
                    await websocket.send(message)
                except:
                    # Ignore all runtime errors (eg when attempting sending to a closed websocket)
                    pass

Why can't we amend send to be a cmd[result[(), err]] as most people discard the value anyways and don't bother to type it, it does break backward compatibility but it is such a niche case that I think it does not matter.

My take on this is as so:

Change send to be a cmd[result[(), err]]
Don't queue messages after onMessage requests a disconnect

I agree. In that case, what should the error type be? We have several options:

We could make the error type () as well, as if to say, "There is only one error that can occur, and that is the sinister Error." This should be pretty easy to do.

An alternative to result[(), ()] is just bool, but perhaps err() is more clearly an error than false or true

We could make it a str and use the error message from the Exception thrown. This should be pretty easy to do as well.
We could make it an enum type kind of like json.value, where each error is a type of error that could be thrown. That way N code can deal with each error on a case by case basis.
We could make a special custom opaque type such that it can't be read directly by N code. This gives us room to change it in the future.

I feel like, for the sake of simplicity we should actually make it a result[int, err] as then we can pass the error code along with it.

What would the error code be?
By the way, the first type variable for result is the value for when sending is successful. Presumably send doesn't return anything useful so it can just be ()

Oh ok, than yeah result[(), err] is best

Oh ok, than yeah result[(), err] is best

He refers to these:

per https://github.com/Luka967/websocket-close-codes
with JS also has which I guess is fine

Perhaps we can have onOpen and onMessage continue running in parallel (since they are already) after connect resolves, which can happen when the websocket closes
I'll have to look into it more but presumably instead of awaiting the tasks for onOpen and onMessage, we can await a Python Future and then resolve that future when we close the websocket

So we can probably change
https://github.com/nbuilding/N-lang/blob/ebebb9e8a15afb9d0784602ca84c45fc1d7e1adc/python/libraries/websocket.py#L148-L152
to
            on_close = asyncio.Future()

            asyncio.create_task(on_message())
            asyncio.create_task(on_connect())

            await on_close
            await on_close

and then whenever we close the websocket, we can use the set_result method to resolve the Future.
https://github.com/nbuilding/N-lang/blob/ebebb9e8a15afb9d0784602ca84c45fc1d7e1adc/python/libraries/websocket.py#L133-L136
                    if isinstance(close, Cmd):
                        close = await close.eval()
                    if close:
                        await websocket.close()
                        on_close.set_result() # NOTE: I'm not sure if this requires the parameter to be given

The issue was that Ash was using N_WS_DEBUG=experimental it appears


Bubble, Doughnut, PolarArea, and Scatter Charts have old template properties

Bubble Chart
Has tooltip and multi-tooltip templates
Doughnut
Has a legend template
Polar Area
Has a legend template
Scatter
Has tooltip and multi-tooltip templates

Fixed in #1667 and #1670


expr: short-circuit evaluation for &

& can be short-circuit evaluated just like |. And add the corresponding test.

Thanks!

it makes the fuzzer run for longer, thanks
Next:
https://github.com/uutils/coreutils/issues/5406


Downgrade bdb-je version

What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：

Fixes #6634
Problem Summary(Required) ：

Finding the root cause and fixing the bug of disk expand take a long time, so we downgrade the bdb-je version first.
Add shutdown hook to avoid the bug of vlsn mismatch as much as possible.

[FE PR Coverage check]
:disappointed: fail : 0 / 25 (00.00%)
file detail

path
covered line
new line
coverage

:large_blue_circle:
com/starrocks/journal/bdbje/BDBEnvironment.java
0
4
00.00%

:large_blue_circle:
com/starrocks/StarRocksFE.java
0
21
00.00%

Please obey the rule about issue and commit about the title


No support for Streamdeck Mk 2

In the driver, there is no support for the Streamdeck Mk 2 :
Path:"0001:000b:00"
VendorID:4057 = 0xfd9
ProductID:128 = 0x80
Release:512 = 0x200
Serial:"DL34K1A04150"
Manufacturer:"Elgato"
Product:"Stream Deck MK.2"
UsagePage:0 = 0x0
Usage:0 = 0x0
Interface:0

Upstream is 10 commit ahead, and does support the Mk2.
Would it be possible to refresh the driver ?
Thanks.

Just updated the driver to the newest version, could you give it another try?

Yes, it's all good! You can release it. Thanks!

Hello. Could you publish a new release with this fix? I'm working on a couple of plugins, and I'd like to compile them against the latest version that includes the Mk 2. Thanks!

You know you can just use the SHA as version number right? :)

yes, but other people will most likely use the release version, and a plugin fails to load if it has been compiled with another version of streamdeckd.
i.e., I can use and compile my plugin using the SHA, but my friends won't be able to use it unless they also get the SHA'ed version of streamdeckd.

A new release has been made, v1.0.2

Awesome, thank you!


implementation of some cycle stuff

What does this PR do and why?
Provide a description of what this PR does. Link to any relevant GitHub issues, Notion tasks or Discord discussions.
Screenshots or screen recordings
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] (if relevant) I have tested this PR in all supported browsers.
[ ] (if relevant) I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #3611

PR #3612

PR #3613

PR #3614

PR #3615

PR #3616

PR #3617

PR #3621

Current dependencies on/for this PR:

main

PR #3611

PR #3612

PR #3613

PR #3614

PR #3615

PR #3616

PR #3617

PR #3621


Release 0.8.0

[x] Update submodules
[x] Test GNAT Studio plugin

Check verification, generation and display of message graph for example apps

[x] Add release to CHANGELOG
[x] Bring changes to main branch
[x] Add tag to git repository

Note: Commit IDs change when a PR is merged on GitHub, so it should be ensured that the right branch is checked out.
git tag -a vX.Y.Z -m ""

[x] Generate distribution archive

make dist

[x] Check distribution archive

Check content of archive
Install in new virtual environment
Ensure that no additional packages to rflx are installed
Test rflx executable

[x] Push tag

git push --follow-tags

[x] Upload to TestPyPI

twine upload --repository-url https://test.pypi.org/legacy/ dist/RecordFlux-X.Y.Z.tar.gz

[x] Check project on TestPyPI
[x] Test installation from TestPyPI

pip3 install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ RecordFlux

[x] Publish release on GitHub
[ ] Test installation from PyPI

pip3 install RecordFlux

https://pypi.org/project/RecordFlux/0.8.0/
The automatic deployment to PyPI is working as expected. :tada:


[Foundation] Discontiguous data slices should not heap corrupt

Byte access and methods that funnel to byte access for slices of discontiguous data (ala backed by dispatch_data_t) should void heap corruption and walking off the ends of buffers

The withUnsafeBytes(in:, apply:) internal method incorrectly handled discontiguous data backing when the slice region was used. This would potentially walk off the end of the buffer as well as grab incorrect byte offsets.

rdar://problem/35797359
https://bugs.swift.org/browse/SR-6515

@swift-ci please test macOS

Build failed
Swift Test OS X Platform
Git Sha - 49002e59681aa42e9c813bd6d19c4a7c53cdc3b6

@swift-ci please test macOS

Build failed
Swift Test OS X Platform
Git Sha - 49002e59681aa42e9c813bd6d19c4a7c53cdc3b6

@swift-ci please test macOS

Build failed
Swift Test OS X Platform
Git Sha - 90d3f895c8726c8382834c0391fd87f649e69ba1

@swift-ci please smoke test linux


How does this work?

I really like how the "trend indicator" works (like red arrow down, etc
I don't see any documentation of what queries you can create and what hidden features are underlying the frontend. Where I can find that info?

@silva96 it's quite simple - the first column is used as the "nominal" value and the second column (if exists) is used as the trend change value:
https://motor-admin.herokuapp.com/demo/queries/new#eyJzcWxfYm9keSI6IlNFTEVDVCAxMDAsIC0yMDA7IiwicHJlZmVyZW5jZXMiOnsidmlzdWFsaXphdGlvbiI6InZhbHVlIiwidmlzdWFsaXphdGlvbl9vcHRpb25zIjp7ImxhYmVsX2Zvcm1hdCI6ImRlY2ltYWwiLCJsYWJlbF9mb3JtYXRfb3B0aW9ucyI6e319LCJ2YXJpYWJsZXMiOltdfX0=
All the calculations should be done in the SQL because query visualization feature doesn't do any specific computations.
For now there are no any docs describing the query visualization feature - but the ultimate goal was to add guides and hints directly into the admin UI - so this is coming a bit later.

Great! understood.


Method not fournd: SystemCollections.Generic IEqualityComparer'1

Opened by jackfoxy on codeplex
12/18/14 daily build found this issue at runtime:
System.MissingMethodException : Method not fournd: SystemCollections.Generic IEqualityComparer'1
 let checkForColumnHeaderDifference (expected: seq<string>) (actual: seq<string>) =
    let expected = HashSet(expected, HashIdentity.StringIgnoreCase)

fails on "let expected = ..."
 System.Collections.Generic.HashSet

(Having problems getting the debugger to run to the affected line (VM issue) ...so I can't currently tell you the values of "expected" and "actual" coming into the function.)

comments
jackfoxy wrote Dec 23, 2014 at 7:55 PM [x]
Update: fixed my VM, and there is nothing remarkable about the data coming into the function, simply a string sequence of length 13.

latkin wrote Dec 23, 2014 at 10:20 PM [x]
Can you provide a ZIP of a repro solution?

A few other questions -- What version of FSharp.Core are you using? What .NET version/profile are you targeting? What is HashIdentity.StringIgnoreCase?

jackfoxy wrote Dec 24, 2014 at 10:13 AM [x]

I researched this issue on a VM on my work machine. I won't have access again until 1/5/15. If this issue is still open then I will attempt a repro solution.

The original app was built on FSharp.Core, <IP_ADDRESS>. I simply changed the Target F# runtime to F#4.0 within the project property page of VS 2015 preview and rebuilt the solution within VS.

A repro app "should" just consist of the following:

open System.Collections.Generic

let checkForColumnHeaderDifference (expected: seq<string>) (actual: seq<string>) =
    let expected = HashSet(expected, HashIdentity.StringIgnoreCase)
    expected

vladima wrote Dec 24, 2014 at 11:14 AM [x]

Given that FSharp.Core does not expose StringIgnoreCase on  HashIdentity module I suspect that repro should include something else (that presumably defines this extrinsic extension property)

jackfoxy wrote Dec 24, 2014 at 11:33 AM [x]

@vladima right you are. I found this additional code:

module HashIdentity =
        let ByProjection (f: 'A -> 'B) (eq: IEqualityComparer<'B>) : IEqualityComparer<'A> =
            let hasher x = eq.GetHashCode(f x)
            let equality x y = eq.Equals(f x, f y)
            HashIdentity.FromFunctions hasher equality
        let StringIgnoreCase =
            HashIdentity.Structural<string>
            |> ByProjection (fun (x: string) -> x.ToLower())

vladima wrote Dec 24, 2014 at 11:51 AM [x]

Is this code located in the same project or in different dll? For the latter case - what version of FSharp.Core is referenced in this assembly?

vladima wrote Dec 24, 2014 at 12:01 PM [x]

Ok, I have a guess: can you check if autogeneration of binding redirects is enabled in the repro project (http://msdn.microsoft.com/en-us/library/2fc472t2(v=vs.110).aspx), enable it if it is disabled and check if the problem still exists

jackfoxy wrote Dec 24, 2014 at 2:20 PM [x]
All the code is in the same project, and in fact in the same file.

There is no  specified in the fsproj file, but there is true

Like I said above, I will not be able to work on the VM I have created for testing F#4.0 again until 1/5/15.

dsyme wrote Today at 1:23 AM [x]

It looks important to get to the bottom of this in case it is somehow related to the perf improvements for hash/compare/equality in F# 4.0 (though I think the likely solution is to add AutoGenerateBindingRedirects)

jackfoxy wrote Today at 5:00 PM [x]

My most recent research led me to suspect this issue involves the Target Framework .NET Portable Subset (.NET Framework 4.5, Windows 8) and Target F# runtime F# 4.0 (FSharp.Core, <IP_ADDRESS>), but in attempting to set up a simple problem replication project that target framework is not available to me in VS2015, and the only target runtime available is F# 4.0 (FSharp.Core, <IP_ADDRESS>).

As another issue in creating a replication project, my test environment somehow regressed to where I am failing on issue https://visualfsharp.codeplex.com/workitem/176, and I currently cannot replicate this reported issue. Fixing 176 should take precedence.

Cannot replicate with Visual FSharp 4.0 Preview 01-15-2015, suggest closing this issue.

OK, I'm closing this


please, give a option to hide windows popup during Windows instalation...

Heloo ! its not realy a issue...or maybe just for my eyes :-P , please give option to hide these windows popup during Windows instalation ? thank you, I appreciate your work...

The windows are visible for the following reasons:

Custom scripts can very well contain Read-Host calls that prompt for user input. These windows must not be hidden or the setup process would stall.
Several PowerShell script (including those used to remove bloatware and UserOnce.ps1) make use of a visible progress bar. These should obviously not be hidden.
PowerShell error messages are rendered using a red font. While users won't be able to read the message, they may very well register that some error occurred and then check the logs.
Windows popping up might be somewhat distracting, but they clearly indicate that the Windows setup process is still running and has not stalled.

As a side note, https://github.com/cschneegans/unattend-generator/commit/499f40f92fcded1c4dbcabfd8f34e624305ff687 significantly reduces the number of windows popping up in the Windows PE phase of Windows Setup by combining several echo calls into a single line. This affects X:\defender.vbs and X:\diskpart.txt.


Sensor not working

Hi,
I was trying to setup my Ruuvitag in Hass.io 0.116.2, failed to succeed. I'm getting the following errors at start up:
Logger: simple_ruuvitag.decoder Source: /usr/local/lib/python3.8/site-packages/simple_ruuvitag/decoder.py:28 First occurred: 16.27.45 (16 occurrences) Last logged: 16.41.13 DATA TYPE 3 IS DEPRECATED - UPDATE YOUR TAG
 Logger: bleson Source: /usr/local/lib/python3.8/site-packages/bleson/core/hci/type_converters.py:193 First occurred: 16.28.46 (19 occurrences) Last logged: 16.41.13     TODO: Unhandled GAP type, pos=17 type=0x19 len=3     TODO: Unhandled GAP type, pos=21 type=0x0a len=2     TODO: Unhandled GAP type, pos=13 type=0x0a len=2
Logger: bleson Source: /usr/local/lib/python3.8/site-packages/bleson/core/hci/type_converters.py:194 First occurred: 16.28.46 (19 occurrences) Last logged: 16.41.13     Data: 01 00 00 54 52 02 db 2b 58 1a 02 01 06 03 03 0a 18 03 19 00 00 02 0a fe 0b 09 50 41 58 20 43 61 6c 69 6d 61     Data: 01 00 01 d7 d5 f9 2c 50 4d 11 02 01 1a 02 0a 18 0a ff 4c 00 10 05 09 18 46 71 93
Logger: bleson Source: /usr/local/lib/python3.8/site-packages/bleson/core/hci/type_converters.py:195 First occurred: 16.28.46 (19 occurrences) Last logged: 16.41.13     POS : 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35     POS : 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Logger: bleson Source: /usr/local/lib/python3.8/site-packages/bleson/providers/linux/linux_adapter.py:271 First occurred: 16.27.44 (166 occurrences) Last logged: 16.41.14     TODO: unhandled HCI Event packet, type=HCIPacket(event_name='Command_Status', event_code=15, subevent_code=None, data=b'\x01\x19', length=3)     TODO: unhandled HCI Event packet, type=HCIPacket(event_name='Command_Status', event_code=15, subevent_code=None, data=b'\x01\x01', length=3)
Cheers!

Hi @Zetor77 . Sorry for the delayed reponse.
First thing I see here is that DATA TYPE 3 IS DEPRECATED - UPDATE YOUR TAG
You should update your tag because the type 3 data frame (from older firmwares) might stop working on some platforms.
Also we have now updated the bleson package, so this should be fixed, and the logging be less verbose. Let me know if reinstating the custom component fixes that for you. Remember to all the contents of the custom_components/ruuvi folder, as there has been updates to the manifest.json


Establish an MSRV (minimum supported Rust version)

We currently only run CI on the latest stable. We should establish a minimum version we want to support, ensure we run CI on that version and advertise that in the README.

The crates written in 2018 edition syntax, so we couldn't drop below 1.31.0
However, miniz-oxide (flate2's Rust backend) uses std::convert::{TryFrom, TryInto} from 1.34.0.
We also use #[non_exhaustive] from 1.40.0, but it's not in the public API and could be removed without any probem. Without it, we can cargo test on 1.34.0

Only 3% of those who responded to the Rust survey said they use a previous stable version, so I don't think we need to be ultra conservative. I did an informal survey once of production users of Rust, and for only a very small percentage didn't track Rust releases within 6 weeks. I think having a hard minimum of 4 releases below the current stable release is pretty good as this gives users 6 months to upgrade. That being said, if it's not too inconvenient we can go back further.

How about treating MSRV changes as a minor version bump? I don't expect to need to go above 1.34.0, but like you said, there's no need to be strict about it.

Are we also ok with having MSRV be at least 4 below current stable and only breaking that if there's a security issue or a dependency forces us to?


Create eventhuboutput.md

Was the content reviewed before the PR got merged? @sandeshh @chaithu14 ?


[Claim Bypasses] New bugs in latest.

Related to #36
The immortal block. (Client server desync)
The user can use a stick piston to push block into a claim then back out to make that block claimed and unbreakable by non claim owners. however on the server the block is in the claim and bugged block interacts on client only until external block update: block placed inside of claim where pushed block should be, water is put next to the block.
Pistons can still push a block into claims.
The current changes only seem to check if its against a wall but if there is air in the border of the claim a piston can still push the block there.
lava casting can still work on air border.
using ice and lava you can lavacast around the border of the claim.
Flying machines break in own claim.
When a flying machine exits your own claim in breaks and wont move. but only when crossing the border.

Flying machines are kinda unfixable


Timing out

Hey there, thanks for building this, super excited about trying this out.
The problem is, running the dev server it just hangs and never loads, and running a build just times out. Have you seen this before?
Here is the error when I run yarn build
Node: v14.16.1
...

warn  - Restarted static page generation for /posts/quia-corporis-nisi-quam-et-provident because it took more than 60 seconds
warn  - Restarted static page generation for /posts/hello-world because it took more than 60 seconds
warn  - Restarted static page generation for /posts/page/1 because it took more than 60 seconds
warn  - Restarted static page generation for /posts/page/2 because it took more than 60 seconds
> Build error occurred
Error: Static page generation for /404 is still timing out after 3 attempts. See more info here https://nextjs.org/docs/messages/static-page-generation-timeout
    at onRestart (/Users/glen/Sites/personal/my-blog/node_modules/next/dist/build/index.js:487:31)
    at Worker.exportPage (/Users/glen/Sites/personal/my-blog/node_modules/next/dist/lib/worker.js:49:40)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async /Users/glen/Sites/personal/my-blog/node_modules/next/dist/export/index.js:412:32
    at async Span.traceAsyncFn (/Users/glen/Sites/personal/my-blog/node_modules/next/dist/trace/trace.js:74:20)
    at async Promise.all (index 0)
    at async /Users/glen/Sites/personal/my-blog/node_modules/next/dist/export/index.js:407:9
    at async Span.traceAsyncFn (/Users/glen/Sites/personal/my-blog/node_modules/next/dist/trace/trace.js:74:20)
    at async /Users/glen/Sites/personal/my-blog/node_modules/next/dist/build/index.js:987:17
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

hey i haven't ran into this before, the only time ive seen issues is if the API that i'm requesting data from is hanging, but page creation shouldn't take taht long if you're not experiencing something similar with other nextjs apps

@colbyfayock I’m actually seeing the same thing on a local dev instance. FWIW, my site has nearly 900 posts. But it’s timing out after creating the first few .xml files; no posts or pages are created. Just hangs. Could be a different issue but wanted to mention. Cheers!

thanks for the heads up, ill see if i can repro. i need to find a bigger wordpress to test with!

@colbyfayock For the record I was never able to use the repo, everything just keep timing out and it was a fresh install with zero posts or data. Anyway thanks for looking into it, cheers!

@skinnard want to try using the demo site GraphQL endpoint to see if you still have issues with that? https://nextwpprod.wpengine.com/graphql

@colbyfayock ya good call, Ill do that, cheers and thanks again.

closing this issue, let me konw if you're still seeing issues and are able to identify any info about what may be causing


Nested layout views and attribute access

Nanoc seems to be nesting views, is it intended?
[1] pry(#<ByExtension>)> assigns[:layout]
=> #<Nanoc::LayoutView:0x007fd3d391fe70
 @document=
  #<Nanoc::LayoutView:0x007fd3d3915f88
   @document=<Nanoc::Int::Layout identifier="/partials/markdown_links.erb">>>

Anyway, nested view work fine for accessors:
[2] pry(#<ByExtension>)> assigns[:layout].identifier
=> <Nanoc::Identifier type=full "/partials/markdown_links.erb">
[3] pry(#<ByExtension>)> assigns[:layout].identifier.ext
=> "erb"

The layout inside has some attributes:
[4] pry(#<ByExtension>)> assigns[:layout].unwrap.unwrap.attributes
=> {:filename=>"layouts/partials/markdown_links.erb",
 :content_filename=>"layouts/partials/markdown_links.erb",
 :meta_filename=>nil,
 :extension=>"erb",
 :mtime=>2014-11-23 20:30:58 +0100}

But accessing them via [] fails:
[5] pry(#<ByExtension>)> assigns[:layout][:extension]
NoMethodError: undefined method `attributes' for #<Nanoc::LayoutView:0x007fd3d3915f88>
from /Users/damien/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/nanoc-5231a7247477/lib/nanoc/base/views/mixins/document.rb:37:in `[]'

Ah, that’s not quite right. Will fix.

Potential fix in #631.

@cdlm Will close not, but please double-check if the issue is truly solved for you.


add authenticating-users example

CI failures are unrelated

Also, is it idiomatic to not include a Gemfile.lock?

Yes, so long as versions are specified in the Gemfile