Add Visual Studio 2019 Solution

Single Header folder (as it stands today) was never built with VS2019 / CL ... One VS2019 solution will save you a lot of time because that will be: ready-made,  instant, no-effort way to use simdb on windows ...

The single-header folder is not "built" normally on any platform, including Visual Studio.
It is not meant to be built. You are supposed to grab to files and integrate them into your project.

I am going to close this issue, because I think it is properly documented in the README.
If you have specific proposals or issues, please reopen this issue and share your thoughts.

I am going to calmly assume you misunderstood me.
I am saying : if you do what I suggest, you will spend much less or zero time, on the issues tab, explaining to people how to build using VS2019 + CL ...
There are a lot of people (aka "very large audience") who have never used CMake and likely never will. But they are very likely to want to use your lib. On Windows. Using VS2019.

who have never used CMake and likely never will

I agree.
There are hundreds of different build systems. We support CMake since it is the de facto standard for cross-platform builds. It is well supported by Microsoft, among others.
We are not going to support platform-specific or IDE-specific build systems.
Of course, you can provide this support. If you build a repository with an IDE-specific build system for our single-header files, we will link to it.
People who do not wish to use CMake (a very reasonable stance) should grab the single-header files and and drop them in their projects. It should be as simple as dropping two files into your project. If you have expertise in this domain, please contribute by making public a repository of your making.
The core simdjson development will continue on CMake.

I made it work but I am doing this for decades. windows.h include requires ancient macros beforehand. One fopen had to be changed to fopen_s.

If there are issues with the code regarding either a specific supported compiler or a standard library please raise them as specific issues. Note that we already compile the library as a matter of course under Visual Studio including the IO (file access) code.

https://github.com/dbj-systems/simd_json_visual_studio.git
Builds.  Does not run. "Kicks the bucket" at somewhat random locations ...

From CMake, you can generate a Visual Studio file, it will build the library and you can then run the tests... we do it automatically with each commit in CI:
https://ci.appveyor.com/project/lemire/simdjson/build/job/t3d0j1rn489af2id
Our code builds under Windows and it passes our tests. And this includes file accesses.
You do not need to port the code. The portability has already been handled.
Several of our contributors work for Microsoft, the library is available via Microsoft vpkg. The library is part of Microsoft FishStore https://github.com/microsoft/FishStore
Now, of course, there might be bugs... if so report them. Don’t port the code to Visual Studio: it is wasted effort. We are committed to supporting Visual Studio.

OK + Clear = No worries ...

Sorry to be a proverbial pain in the ... I did a legal install .. Cmake and all that ... ALL_BUILD builds, but RUNTESTS fails.
This machine is WIN10 PRO , i5 CPU, 8GB RAM ... this is the visual studio build dump on running building RUN_TESTS :
1>------ Build started: Project: RUN_TESTS, Configuration: Debug x64 ------
1>Test project D:/DEVL/GitHub/simdjson
1>    Start 1: basictests
1>1/5 Test #1: basictests .......................***Exception: Illegal  0.24 sec
1>    Start 2: jsoncheck
1>2/5 Test #2: jsoncheck ........................***Exception: Illegal  0.21 sec
1>    Start 3: jsonstream_test
1>3/5 Test #3: jsonstream_test ..................***Exception: Illegal  0.09 sec
1>    Start 4: pointercheck
1>4/5 Test #4: pointercheck .....................***Exception: Illegal  0.20 sec
1>    Start 5: integer_tests
1>5/5 Test #5: integer_tests ....................***Exception: Illegal  0.21 sec
1>
1>0% tests passed, 5 tests failed out of 5
1>
1>Total Test time (real) =   0.98 sec
1>
1>The following tests FAILED:
1>	  1 - basictests (ILLEGAL)
1>	  2 - jsoncheck (ILLEGAL)
1>	  3 - jsonstream_test (ILLEGAL)
1>	  4 - pointercheck (ILLEGAL)
1>	  5 - integer_tests (ILLEGAL)
1>Errors while running CTest
1>D:\PROD\programs\vs2019ide\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: The command "setlocal
1>D:\PROD\programs\vs2019ide\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: "C:\Program Files\CMake\bin\ctest.exe" --force-new-ctest-process -C Debug
1>D:\PROD\programs\vs2019ide\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd
1>D:\PROD\programs\vs2019ide\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: :cmEnd
1>D:\PROD\programs\vs2019ide\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
1>D:\PROD\programs\vs2019ide\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: :cmErrorLevel
1>D:\PROD\programs\vs2019ide\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: exit /b %1
1>D:\PROD\programs\vs2019ide\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: :cmDone
1>D:\PROD\programs\vs2019ide\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd
1>D:\PROD\programs\vs2019ide\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: :VCEnd" exited with code 8.
1>Done building project "RUN_TESTS.vcxproj" -- FAILED.
Build has been canceled.
Projects build report:
Status    | Project [Config|platform]
-----------|---------------------------------------------------------------------------------------------------
Succeeded | ZERO_CHECK.vcxproj [Debug|x64]
Failed    | RUN_TESTS.vcxproj [Debug|x64]

Yes, worries.
Fish Store was neve built using VS 2019, too ...
As we all know: "He who uses CMake, he likes pain" ...
There are also C++03 (or is it 98?) constructs in there ... but that is another big subject ... this applies to both projects: simd JSON and FishStore ...
Please advise ...

The simdjson library builds and runs in CI (please see the log) and it builds and run on our machines.  If you have problems building this library with Visual Studio, you need to provide enough details so that others reproduce and verify the issue.

CMake might be an annoying extra effort, but we could also say, as we all know: "He who uses IDE-specific build systems, likes flipping tables and kicking buckets at random locations".

Guy from the FishStore poject is very reasonable. He will amend their readme so that cmake / vs2019 combo, will have the correct incantation.
As of VS2019 , cmake has changed the behaviour. It appears -A switch is now required. But in reality, it is not required. Neither is the architecture code required as the last word in the command argument string ...
cmake .. -G "Visual Studio 16 2019"

is the correct command ...  no -A required ...


Add rustdoc_json::Builder::package_target() to build for bin, test, bench, etc

I'll see if I can write some tests tomorrow.
One annoyance I've noticed is that this doesn't work:
//  cannot infer type of the type parameter `T` declared on the enum `PackageTarget`
Builder::default().package_target(PackageTarget::Lib)

Since Lib is the default, i think this won't be a problem very often.
Fixes #245

Thanks for the review and adjustments!

Thank for the help with implementing!
(Again, feel free to ping when you would like a release of rustdoc-json)


Cloudfront Function Resource

What problem are you facing?

After trying to attach a Lambda function to Cloudfront as a Cloudfront function, I realized Lambda and Cloudfront functions have nothing to do with each other. Cloudfront Functions are a totally new resource and they fall under the cloudfront api. These are not something I can create with Crossplane at the moment.
How could Crossplane help solve your problem?

Make a new Cloudfront Function resource like so:
apiVersion: cloudfront.aws.crossplane.io/v1alpha1
kind: Function
metadata:
  name: rewriter
spec:
  forProvider:
    comment:  A lil rewriter
    runtime: cloudfront-js-1.0
    code: |
      function handler(event) {
          var request = event.request;
          if (!/\..+/.test(request.uri)) {
              request.uri = `/index.html`;
          }
          return request;
      }

hey @kferrone since latest sdk bump it is possible via code-gen - remove following https://github.com/crossplane/provider-aws/blob/master/apis/cloudfront/generator-config.yaml#L13 - checkout https://github.com/crossplane/provider-aws/blob/master/CODE_GENERATION.md

I finally gave it a shot. I kinda see what's going on now. I got tons of errors though. Will need lots of help.


PPO2 sample efficiency

Hi,
I was trying to get a sense of the sample complexity required for training PPO2 vs. DQN on simple environments. I ran both PPO2 and DQN on CartPole-v0. DQN achieved mean episode reward of 185 in about 100,000 episodes. For PPO2 it took about 2,000,000 episodes. This implies a sample complexity overhead of about 20x for PPO2. I did not change any hyper-parameters and used the default settings. Am I doing something wrong here or does PPO2 does indeed take around an order of magnitude more samples than DQN? Any tips/ideas appreciated. Thanks

CartPole is not a good benchmark for evaluating sample efficiency. It's too easy. Also how many random seeds did you run? Better to do at least 10 if possible.


i can't use /wild with multiworld plugin.

it showed "Command cannot be use in this world".

Did you add the world to the config because the plugin is not plug in play

Hey can you provide any updates

Closed due to lack of response


RBD provisioner use provisioner name as identitiy by default instead of random string

What this PR does / why we need it:
In production, provisioner should not use random identity on start.
Because, provisioner Pod may crash or be recreated on different nodes, if a provisioner generates random identity string each time, then it will cannot delete old PVs it provisioned before. Example errors logs:
I0801 11:03:05.685653    1901 controller.go:1068] scheduleOperation[delete-pvc-e2be4095-76a8-11e7-88c1-000c291fbe71[e2c845d1-76a8-11e7-88c1-000c291fbe71]]
I0801 11:03:05.688484    1901 controller.go:1035] deletion of volume "pvc-e2be4095-76a8-11e7-88c1-000c291fbe71" ignored: ignored because identity annotation on PV does not match ours
...

Most users deployed their RBD provisioner without specifying -id flag. So I change the default behavior to use provisioner name as identity (like some other provisions, gluster/block, etc) instead of random string.
Special notes for your reviewer:
In this PR, I also add PROVISIONER_NAME environment variable support, like many other provisioners do.

/cc @rootfs @wongma7

Hmmm.... Does id have to be unique within the same type of provisioner?
Say I have a statefulset of ceph rbd provisioners. If I use string for id of 'rbd', then multiple could handle the request, but maybe thats ok? If not, maybe using the statefulset's hostname is a better default?

@kfox1111 id doesn't have to be unique, except in rare cases where only the provisioner that created a PV is capable of deleting it. By giving all provisioners serving the same class the same id (same prName), they will simply race to Delete PVs and everything should turn out fine.
I'm okay with using prName as the default.
On one hand, it just "makes sense" that the provisioner that created a PV should be responsible for deleting it, so the recommendation made when gluster/block and cephfs were created was to force the user to specify an ID.
On the other, users expect provisioners to behave the same as the upstream mega-controller, i.e. if a PV has Delete it should be deleted, it doesn't matter by which provisioner instance. And maintaining state via an ID argument is painful, plus impossible with a statefulset.

ok. sounds good to me.
Does the cephfs one have the same issue currently or is it defaulting to hostname?

Yes cephfs has the same issue, it is defaulting to random UUID atm.


Right clicking an interactible block sets PRIMARY instead of SECONDARY

This is behaviour that I know about but would be cumbersome to avoid, so I'm documenting it here.
As a server plugin, I have to limit myself to information the vanilla client volunteers to the server. As such, the closest heuristic I have to detecting left click that doesn't depend on being in reach of a block is when the client sends over the arm swing animation. Unfortunately, the arm swing animation also triggers when you right click a block that can be interacted with.
For this reason, it won't be fixed for now.

I don't know, actually, maybe I can try mixin'ing PlayerController.activateBlockOrUseItem and prefer SECONDARY when a simultaneous PRIMARY and SECONDARY select happens? I'll need to investigate :)


Add unit tests for gomega variables

Add missing tests to check the new additions to support gomega variables or fields.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+7.9%) to 87.869%

Files with Coverage Reduction
New Missed Lines
%

gomegahandler/handler.go
2
95.6%

Totals

Change from base Build<PHONE_NUMBER>:
7.9%

Covered Lines:
536

Relevant Lines:
610

💛  - Coveralls


[Intel MKL] Changes to graph rewrite to support native format

This PR makes changes to MKL graph rewrite to enable native format support for MKL ops based on an environment variable setting.

@mahmoud-abuzaina  Can you please check @penpornk's comments and keep us posted ? Thanks!


Have a translation system

Have a system to handle string and text translation on demand.

Left as closed - picon is no more in active development


Provide type definitions for Stylesheet

Right now, the result of the parse method is Stylesheet which is just an empty object. I don't know if this intended in order to keep the API private, but it would be great to have some more type information on the result, also to get more confidence in using the resulting AST ("these are types I can expect to use for this major version of the library"). The HTML language service does something similar by providing a subset of the internal type definitions.
For our specific use case over at Svelte language tools it would be great to have some kind of walk functionality, a "find node at X" method, and for the node it would be great to get the Node start, end and type (class/id/etc).

I understand the desire, but sorry, there are no plans for that. It's too much work: Document all the node types and maintain the API over the years.


Documentation cleanup and deployment test

When this works, I'll update the dev deployment documentation.

bypassing the required review for this test documentation update


Address comments on the "rootless CA certs" patch

Address the following problems with #538:

Correct the shell selection for entrypoint, Ubuntu flavours still need explicit bash for variables with dots in their names
Change unhelpful exported variable name (changed from CACERT to JRE_CACERTS_PATH)
Change which to more-POSIX-compatible command -v
More cleanup
Explicitely use TMPDIR when available instead of hard-coded /tmp

Ubuntu flavours are broken, I'm on it.

CC @tianon

This is an improvement, yes, thanks :heart:
(definitely like your idea in #573 though, and wonder if, since this rootless functionality hasn't been officially released yet, it could happen sooner and then this is moot?)

wonder if, since this rootless functionality hasn't been officially released yet, it could happen sooner and then this is moot?

That's my thinking too, but since I'm not involved in and not knowledgeable about the release process and its deadlines, I'm offerring both possibilities. #573 still needs to be implemented, tested, documented and experimented with after all and if "July release" is what I think it is, the timeline is rather tight. "rootless" improves on the current process, which is probably valuable by itself, even if we know how it could be improved further.

@karianna Are you aware of anything blocking the review and merge here? I would like to get this in before the July release as QOL improvement.

@sxa and/or @gdams up next to review and merge.

@rassie Apologies for the rebase requirement but I think our release has created conflict for this PR

@karianna rebase done. I hope we can squeeze this patch into the release. Fingers crossed it will help the pain points not exacerbate them.

Doh, this should've been part of all those recent updates, right?

Doh, this should've been part of all those recent updates, right?

Probably. I've asked multiple times for a review, but nothing happened. I guess the release happened a couple of days ago and then #612 has been reported, so I thought I'd need to fix that as well.

Doh, this should've been part of all those recent updates, right?

yeah we're working on it, it would appear we've broken some users so I want to get this merged and update the official images soon

@rassie if you can help us resolve #612 in this PR we'll get it merged and kick off a republish

Hold your horses, this build isn't even green yet :)

Hold your horses, this build isn't even green yet :)

yeah just spotted the failing CI, I'll wait until it's green

@rassie if you can help us resolve #612 in this PR we'll get it merged and kick off a republish

This is what is happening, the latest push as of right now should become green. Would still appreciate a closer look at the source from you, I'm quite anxious about breaking more stuff, even though I believe that the tests are solid.

@rassie if you can help us resolve #612 in this PR we'll get it merged and kick off a republish

This is what is happening, the latest push as of right now should become green. Would still appreciate a closer look at the source from you, I'm quite anxious about breaking more stuff, even though I believe that the tests are solid.

This looks good to me, the tests are solid and the changes all seem as expected.

/merge

/approve

Thanks!

/approve

@tianon I'll get this merged and update https://github.com/docker-library/official-images/pull/17249 to include these changes shortly


#226 allows to use ```mermaid blocks but they don't render all the time.
I think that
  $('code.language-mermaid').each(function(index, element) {
    var content = $(element).html().replace(/&/g, '&');
    $(element).parent().replaceWith('
' + content + '
');
  });

run's after mermaid.initialize() on some machines.

This happens for me all the time in current FF releases but not Chrome.
This is because there is a race condition between mermaid.init and the conversion for code fences in hugo-learn.js document-ready-handler at the end of the file.
You can avoid this by reissuing the initialization from your own js file by
$(document).ready(function(){
	// This is a bugfix for FF, because Mermaids converter may run
	// before our Hugo theme changed the diagram to fit Mermaids rules
	if( !mermaid ){
		return;
	}
	if( jQuery( '.language-mermaid' ).length ){
		// as long as we have those nodes our theme is not
		// done with loading
		setTimeout( supportMermaidCodeFence, 10 );
	}
	jQuery( '.mermaid' ).each( function(){
		var $this = jQuery( this );
		if( !$this.find( '> svg' ).length ){
			mermaid.init( undefined, $this );
		}
	});
});

But this is just a workaround.
Nevertheless Mermaid-Code-Fences suffer from another bug, where they will not render while a search term is found in the diagramms source code. This is an issue in all browsers. Just type a plain a into the search and watch your diagramm bomb up.
Also Mermaid wasn't updated for ages. Current version is 8.7.0


Add a lots of weapons and armors inside equipments compedium.

update also list of weapons and armors inside the rules compendiums

update french translation & some fix

Fix the spellselector :)

I'm going to let it slide this time, but in the future I would highly suggest that you create separate branches for each change you'd like to make and then create separate PR's for them as well.


make run error

@mirgong if you search issues for huggingface.co you'll find the workaround.
In the future, please fill out the bug template 😄


Aws4 signature

Description
Adds the ability to sign requests to Opensearch with the AWS4 signature algorithm
Issues Resolved
Check List

[x] Commits are signed per the DCO using --signoff

Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the
best of my knowledge, is covered under an appropriate open
source license and I have the right under that license to
submit that work with modifications, whether created in whole
or in part by me, under the same open source license (unless
I am permitted to submit under a different license), as
Indicated in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including
all personal information I submit with it, including my
sign-off) is maintained indefinitely and may be redistributed
consistent with this project or the open source license(s)
involved.

Lol, sorry, I just saw the existing PR:
https://github.com/opensearch-project/opensearch-rs/pulls
This PR is superfluous.


Code of Conduct: please stop censoring expressions of concern in re: analytics.

Dear @Homebrew/@owners:
I must at this time express my utmost consternation and disappointment at the way in which those members of this community who have been voicing their concerns about the recent addition of anonymous collection of analytics to homebrew have been (and continue to be) treated.
I am long-term member of this community. Homebrew is something that I care deeply about.
In almost any other circumstance I would be loath in the extreme to "humblebrag" as I will now, but for what little it is worth, I am somewhere between the 34th and 70th most frequent contributor to this project. I have been involved to one degree or another for most of its seven years of existence. I have dedicated many, many hours to it, I think I have made some significant contributions. So it is in my capacity as a deeply invested, deeply committed, non-maintainer of this project that I humbly speak on the behalf of the thousands of other members of this community who are, or might be, distraught, and wish, or may wish, to express it.
I am not saying I am opposed to analytics. On the contrary, I think they could be immensely helpful in steering the future direction of the project. But I am also someone who is very privacy and security-minded, and I have some legitimate concerns. And while there are times when censorship is necessary when users are in breach of the Code of Conduct, this is not an excuse to violate it oneself.
I know "managing an open-source community is easy when your project is small but grows harder the larger your project becomes." It must be incredibly frustrating to face this kind of backlash and hysteria.  But I think at this point we all need to remember that learning "how to grow your project’s community and ensure that it remains a healthy, happy and fun place" is a process that does not cease.
I see little point in citing where I see plain violations of this project's Code of Conduct. There are many. Instead, I would kindly ask user and maintainer alike to please review:

https://github.com/Homebrew/brew/blob/master/CODEOFCONDUCT.md#open
https://github.com/Homebrew/brew/blob/master/CODEOFCONDUCT.md#considerate
https://github.com/Homebrew/brew/blob/master/CODEOFCONDUCT.md#respectful

...and reflect for a moment. Because frankly, I currently do not feel welcome here at all. 😢

Geoff,
I won't speak on behalf of other maintainers, but I can and will speak to my own concerns & experiences.
I'll also note the following for transparency's sake:

In the last 3 months I have erased the contents of one Issue, because it contained purely personal abuse to the Homebrew maintainers on really quite a nasty level.
Over my time in Homebrew 4 people have been blocked organisation-wide by me:

One for persistent GitHub insults to maintainers, and then finding maintainer's personal Twitter accounts and tweeting personal abuse to each of us repeatedly, over a persistent period of a couple of days.
One for sending abusive emails to maintainers' personal email accounts after doing so repeatedly on GitHub and being asked to stop.
One for posting repeated personal abuse on various GitHub issues, including to normal contributors, and refusing to stop when asked. That block was removed after a week, and then re-implemented when that person went right back to abusing contributors.
One for creating a new account that had been blocked previously to continue abusing the maintainers.

I'll also note that fundamentally, whilst the Code of Conduct is absolutely applied equally, white men have a severe imbalance in influence over open source and the voices and experiences of women and non-white contributors are frequently trampled over by FOSS communities. Homebrew is determined to not become one of those communities.

You have the free speech to say those things to me, but I have the free speech to say we don't welcome those comments around Homebrew and we won't endure them. Your free speech does not === the right to abuse me. That's not what free speech is, not even in law for many legal systems; most have "harm exemptions" to the free speech mechanism.
 This is why Code of Conduct's exist, to enforce a minimum conduct. Not to make sure every comment is one of grovelling approval but to make sure it doesn't degrade into outright insults and personal attacks.
 Yelling censorship like its a one-size-fits-all problem is disingenuous, and I apply that broadly over the last couple of weeks more than I apply it to your comment, I add.
I will note that if people have constructive suggestions to make about analytics that go beyond "you are all terrible human beings and this is something the NSA would do" your Issue will remain open until we can resolve it one way or another. As a shining example this issue was opened on a productive subject Homebrew could work with, and has remained open for 18 days without significant issue.
Come to us with "Oh you could improve the opt-out mechanism with this tweak" or "Have you considered this analytics provider instead?" or anything like that and the issue is not only welcome but encouraged. If you come to us with "You're all a disgrace to open source, spies for Google and have been paid off by the government to collect this data" and again, those aren't theoretical examples, that's an Issue that clearly isn't going anywhere and harm reduction comes into play.
In terms of the "humblebrag" I contributed the most commits to the Homebrew organisation last year, let alone the amount of Issues and Pull Requests I review. Contribution buys you trust, it doesn't necessarily buy you the right to make others feel absolutely awful, and look, I have fairly crappy health, I've written about that publicly before now (and removed the posts 6 months later worrying about them), but none of this has been good for my health and I have a lot of fondness for working on Homebrew.
Imagine being someone who doesn't know Homebrew, or someone who is vulnerable or from a section of society whose voices are respected less than us white men, and going to file an Issue with Homebrew, but before you do you check the Issue below and discover someone calling the maintainers every name under the sun and comparing them to their favourite government spy agency. Would that make you want to contribute to Homebrew or would it make you want to run in the opposite direction as fast as you could? This isn't a theoretical problem. Look at tech's ongoing diversity problem, that is amplified significantly in FOSS.
To be blunt, if you feel threatened by us trying to make Homebrew a safer space for everyone, from all walks of life, and the people who feel threatened feel a bit safer, I'll take that trade off because the difference between their real threat level and your's is almost universally huge, just huge.
And don't take that as me wanting you to feel like you aren't welcome here, because you absolutely are and I appreciate your contributions and the discussions we've had this week alone, but we're both privileged to be white men and that discussion has a place in free speech and its consequences.
I am permanently uneasy with the erasure of comments, but I will not discard the harm inflicted by those comments in terms of both maintainer health and also with the view that Homebrew and FOSS would not be a worse place if people who weren't white men felt more comfortable contributing on a regular basis. There is a balance here, but the balance isn't to allow people to say and do unto others whatever they desire without consequence.

Hi @geoff-codes,
Firstly, our bug tracker is not an area for public expression; it's a place for reporting actionable bugs or issues we have previously not closed as a WONTFIX. People who want to express themselves publicly have Twitter, blogs and any number of other places on the internet for doing that (but @DomT4 has already made the point on this better than I have).
Secondly, you're one of the first (maybe the only) person who has created an issue about this who has actually contributed meaningfully to Homebrew. Most people who have "expressed concerns" have not been part of this community and have been publicly or privately abusive (particularly to me and @DomT4). I don't want to bore you by digging up the number or content of the private abusive emails I've been getting over the last few weeks but I'm beyond bored of them now. I edit content because I regularly have to click through issues and I don't want to read abuse repeated to me again and again.
Thirdly, the priority for me when running Homebrew is the sanity of the maintainers who contribute the most to Homebrew. As @DomT4 mentioned, between him and I we're two of the most active maintainers on this project and there's a bunch of stuff in the sidelines (applying for GSoC, keeping CI servers running, managing our finances, apply for SFC) that may not happen if the two of us dropped off. This whole analytics situation has had me very tempted on more than one occasion to leave open-source altogether and (without being too arrogant here): that would be bad for this project.
Finally, I'm happy to work to address concerns beyond "no analytics!" and "analytics should be opt-out" for reasons I've explained at extreme length in multiple other places. Whenever these concerns have been raised I've made PRs to fix them usually merged within 24 hours.

@geoff-codes Interested in your thoughts on the above comments when you get the chance, thanks!

Closing this out as there's nothing more actionable here but still interested in @geoff-codes' reply.

@DomT4 @mikemcquaid Thank you for your very thoughtful and considerate replies. I apologize for not responding sooner (I've been away for a few days). I intend to follow up in greater detail with some additional, detailed thoughts very soon, but for the time being, I'll just say your points are well taken, and again, thank you for your thoughtful responses.

I intend to follow up in greater detail with some additional and more detailed thoughts very soon, but for the time being, I'll just say your points are well taken, and again, thank you for your kind and detailed response(s).

@geoff-codes Still interested in this, even if it's privately.


igluctl: omit "no maxLength" warning if hostname format is present

When I'm adding format: hostname to string property, igluctl keeps inform me that I need to add maxLength, which is unnecessary, maximum hostname's length is 255.

Also, double-check if we're using it when generating DDL (though, I almost sure we do).


Volume control

Playd doesn't currently implement any volume control.
<hayashi> It probably should

Going to close this as wontfix for now, because the main use cases (eg, URY's production pc) have a sound system (vista/7/8, pulseaudio) that allows per-application volume control.  This could be revisited later.


hangs on t/mojo/daemon.t

I am running win10 64bit. When I try installing Mojolicious it hangs at this point.
with Strawberry Perl 5.18.4 it hangs at
t/mojo/daemon.t ............................ 1/?
with Strawberry Perl 5.22.1 it hangs at
t/mojo/daemon.t ............................ 50/?
matrix shows it should work?

Tried on Win10 x64, Strawberry Perl 5.22.1, and it works:
Configuring Mojolicious-6.40 ... OK
Building and testing Mojolicious-6.40 ... OK
Successfully installed Mojolicious-6.40

How long should it be at that line for? I am assuming 1 hour is too long?
I checked the CPU use and it was 0% for dmake so I am assuming it hanged.

I too have noticed the "hanging" issue in Windows (although not only with Mojolicious).  It might possibly have something to do with the differences between CMD and PowerShell.  However, during said hangs, it usually does what it's supposed to just by hitting .
Since that "work-around" seems to do the trick for me every time, I haven't put much effort into figuring out why.

what should i be hitting? space or period?
i am using CMD

Sorry, I had an error with markdown formatting.  enter

any other ideas?

so a person on another forum suggested I end process the test, and after some confusion I was able to do that and allow testing to proceed past this one hang up. It seems that was the only error for me. Here is the pastebin

Have you tested how far back the problem goes? 6.0, 5.0, 4.0...?

Or have you even checked with prove -v to see at which test exactly it hangs?

CPANTesters results look pretty good at the moment. http://matrix.cpantesters.org/?dist=Mojolicious+6.40

I did not check how far back the problem goes and I did not know the prove -v syntax. I think if there's no major issues then having the daemon.t fail testing is fine for me.

Looks like this problem only affects a very small subset of Windows machines. Is there any chance one of the affected users will be able to track it down? Otherwise i don't think it makes much sense to keep this issue open.

I am not sure how to track it down, otherwise I would've. I think since it only affected me it probably should not be kept open.

Too bad, but yea, it's not easy even with access to an affected machine.


Fix the back to the top button

Describe the feature
I will fix the back to the top button in the bottom of the page so that when we come to the top of the page it does not appears .
Add ScreenShots

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

I have good knowledge of this issue. I will fix the JavaScript to handle this issue .
Hey @arghadipmanna101 please add level and assign me this issue as a GSSoC contributor

I'm eager to lead the Flipkart_Clone project. With a solid background in HTML, CSS, JavaScript, and ReactJS, I'm confident in my ability to make substantial contributions to this project. Could you please assign me to this issue through GSSOC?

@Ramben0909 please assign this issue to me

@Ramben0909 please assign to me task.

hey @arghadipmanna101   I have resolved it and made pull request please review it


cluster: add a client for reading/writing docker for mac settings

Hello @maiamcc,
Please review the following commits I made in branch nicks/d4mclient:
dbe2760615044466cd738669cc5ced355bb141bc (2020-10-23 11:12:05 -0400)
cluster: add a client for reading/writing docker for mac settings
Code review reminders, by giving a LGTM you attest that:

Commits are adequately tested
Code is easy to understand and conforms to style guides
Incomplete code is marked with TODOs
Code is suitably instrumented with logging and metrics

hopefully not as scary as it looks, mostly just being very careful with how we handle the API structures since this is not an official client

Whoops, this fell off my radar. Will look when I'm done w/ Tiltfile stuff (so maybe this afternoon, maybe tomorrow morn.) Unless there's a particular rush?

nope, no rush


repeat.for: loses sync between array and view when array updates happen during leave animation

When events are removed from the view, they remain in viewSlot.children until the animation completes, see https://github.com/aurelia/templating/blob/master/src/view-slot.js#L204
The removing state is accounted for here during the mutation: https://github.com/aurelia/templating-resources/blob/master/src/array-repeat-strategy.js#L115 (by taking into account rmPromises.length, this works as the splices are ordered).
Say this animation takes 1 second, and 200ms later an insert happens at the end of the array. At this stage viewSlot.insert is called with the index of the item in the array, yet the index within the viewSlot is different due to the animations not having completed (viewSlot.children now has a different number of elements to the array). Now rmPromises.length can't be used to factor in the indexes of the removed items from a previous set of splices and the indexes are all wrong.
This leads to the view going badly out of sync with the array, this is particularly bad if you are using say splice(idx). This can end up splicing elements off of the end that should not be removed, then a later update can supply an index that should exist within viewSlot.children but doesn't, throwing the exception Cannot read property 'firstChild' of undefined.

Calling @EisenbergEffect @martingust @jdanyow this is a serious issue with repeat.for affecting all animator libraries. It will affect any user where arrays update during animation leading to extremely bad results.

The + rmPromises.length correction factor also bothers me. I can see how it works to fix the offset of splices at a higher index, but what if the first splice is at a higher index than the second splice... in that case wouldn't the +1 incorrectly be applied to the second splice (at the lower index)? It seems to me it should only affect splices at a higher index, (and after being corrected for intermediate additive spices). Would really appreciate some feedback on that point.

@martingust @jdanyow Can you guys work s with @ohjames to see if we can resolve that. We may also need help from @zewa666 if this involves the css animator. You all know more about this code than I do at this point...

@ohjames I think you are right, the rmPromises should only affect splices at a higher index. Do you have an example project or plunker that shows the issue you described, that would help a lot to fully see the problem.
However when trying this out I think I have found a related (or same) bug.
Let's say I have an array of 4 items: array = ['foo', 'bar', 'baz', 'qux']; bound to a repeat.
Then trigger a splice, this.array.splice(2, 1); with a remove animation of 5 sec, then trigger the same splice again, within the 5 sec. This scenario should remove baz and then qux, but since baz is still in the viewSlot, it will incorrectly remove baz twice.
Here is a plunker with this scenario: http://plnkr.co/edit/6JwgTr3ftzOx5Z8Alebp?p=preview

I'm working on a small test for this now. I want to add some unit tests to aurelia-templating-resources, but first I'm adding some visual tests in a modified aurelia-skeleton-app to see if/how the splices are modified before making it to the array repeat strategy.
I've already tested rmPromises issue and it seems that it never breaks, this leads me to believe that the splices are re-ordered before they get to this point so that the lower indexes always come first. I think this process also coalesces the splices, given that the code processes removes before inserts, you'd expect removing an element in the same tick that it is added might lead to an orderering error and the wrong elements removed.
Any idea where this process happens? I think one approach to fix this might be:

On insert, if there is a pending animation wait until it has finished and queue the splice.
After animations have finished, if there are queued splices then coalesce them and apply them.

I also wonder if maybe there's an alternative... could viewSlot.children be changed before the animation completes rather than after (and remove the rmPromises correction factor?)

Okay I've added a repository to demonstrate the issue. It uses all the dependencies from yesterday's patch release (the animator-css fix is key, otherwise this is even more broken). Anyway, here's the test repository:
https://github.com/ohjames/aurelia-bugs
Here's the key bit:
https://github.com/ohjames/aurelia-bugs/blob/master/src/welcome.js#L10-L24
The leave animation lasts 0.8 seconds.

Running it here: http://chilon.net:9040/
You can see what's happening clearly with the visuals, the C is animated in during the removals of 'a, and 'c', so the index is wrong.
The error manifests for me in chrome but no in firefox. Not sure why at the moment. Maybe because chromium is using Object.observe?

Correction: just as broken in firefox. Forgot animation to go with the -webkit-animation.

Awesome, thanks for the example project @ohjames. I think this and the issue I described could be solved by storing rmPromises on the repeat instance and clear it here when the animations are finished. The second round of splice will then know if an animation is in progress and if so compensate and wait. But then rmPromises definitely need to only affect removed views with a higher index. This would need more testing though, I have only made some quick tests on these two scenarios.

@martingust ATM rmPromises.length correction always works due to the normalise/coalesce process that happens before this code is called. If you have to wait on the rmPromises promise before applying a new set of splices then you'll need to normalise/coalesce the new splices following the same process so that the rmPromises.length correction can still work. This is probably for the best anyway... there's no need to replay additions that will be removed right after etc. I'm about to submit a PR with a test for this stuff.

There added a PR with the test now. I'm working on a fix also which hopefully I'll push tonight in the same PR. If anyone could point at where the splice normalise/coalesce phase takes place that would be great :baby_chick:

Closing this one due to my fixes but opening a very similar and very serious issue that manifests similar (but not quite as obvious and catastrophic) desync issues to this one.


Allow additional characters in keys.

I understand the the current implementation only allows alphanumeric characters in keys, but I find that can lead to mistakes very easily.  It would be great if the goal of HJSON was to cater to as many potential human errors as possible. Basically accept that no one will read the docs thoroughly and go on to assume things about the nature of the format.  A large assumption would be that hyphens and underscores in keys would be catered for.
If I were to make a key for something like redis-server I don't think my mind would clue in that I am typing a non-alphanumeric character.  At least not until I am debugging the error later... or maybe not even ;)

I changed it to allow all characters except whitespace and {}[],: (because that would make it confusing).
Thanks for the feedback!


Added support for running unit tests on PHP 5.2

Signed-off-by: Dan Bernardic<EMAIL_ADDRESS>

@narfbg I know this is not very high on your priorities list, but FWIW.

Why are you changing DB_driver.php and the quoted_printable_encode() test though?

I'm really glad you find it useful :)
DB_Driver's implementation of the field_data method had the signature public function field_data($table), and all the sub-classes had the signature public function field_data($table='').
When I ran the tests with 5.2, PHP complained about the mismatch. The change should be a "true refactoring", by which I mean that there is no way that the change would change existing functionality at all.
The quoted_printable_encode test was written wrongly, which just never came up before because the test is skipped on all versions higher than 5.2.
I hope that answers it. Otherwise, I can submit a pull request without those changes, and then you could review the Travis log, and see in what way the build fails without those changes.

Yes, please revert the field_data() and quoted_printable_encode() changes.
The former is a recent change and any extending classes should be changed instead, while the latter is copied from PHP's own test cases, so chances are - it's the implementation that's wrong and not the test.

OK, I did, and the tests fail for those two reasons. Do you want me to change all the sub-classes?
That is a more risky change, as I understand it, because any code that relies on that default parameter will then break.
Did you write the implementation of quoted_printable_encode() yourself, or did you copy it from somewhere?

It looks like the test is actually wrong. Here's a codepad I prepared to test that:
http://codepad.viper-7.com/8INDk3

The implementation is mine, only the test is copied. I'll look into that myself though ... thanks for the whole effort.

dbf3460bc7c94bf49db7dff3525906cae53a81ac


[BUG] disabled-worlds didn't work.

Describe the bug
version1.2 have 'disabled-worlds' option
I tried setting him to world, but it didn't work.
There is something wrong with the plugin logic.
Also I recommend setting this to enable-world
To Reproduce
Steps to reproduce the behavior:

disabled-worlds:

world

Desktop (please complete the following information):

Minecraft server software and version: Paper1.19
Plugin version: 1.2

Thanks for the bug report! Fixed in 1.2.1. I will also make a switch between enabled and disabled worlds, which will be implemented in future updates.


ARM64: use 64 bit bytecode

@sigatrev couple of files in full repro also needs change. Please update them.


feat: merge VRP quickstarts

The existing two VRP quickstarts are merged into a single one, by adding the capacity into the VRP with time windows quickstart.

The existing VRP quickstarts have not been touched yet, only a new (combined) one has been added. I will remove the old VRP quickstarts after a first review and CI checks.

Just realized UI needs an update as well to include the capacity. On it..

Since we are changing the QS URL, please check the https://github.com/TimefoldAI/frontend repository for references.

UI updated.

Added one more commit introducing the progress bar with vehicle load and capacity into the By Vehicles tab. I will squash it after review.

All comments addresses, will squash the commits and remove the old VRP quickstarts.


/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:748:12: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      local void send_tree (s, tree, max_code)
                 ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:748:12: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:799:11: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      local int build_bl_tree(s)
                ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:799:11: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:834:12: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      local void send_all_trees(s, lcodes, dcodes, blcodes)
                 ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:834:12: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:863:20: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      void ZLIB_INTERNAL _tr_stored_block(s, buf, stored_len, last)
                         ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:886:20: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      void ZLIB_INTERNAL _tr_flush_bits(s)
                         ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:896:20: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      void ZLIB_INTERNAL _tr_align(s)
                         ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:911:20: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      void ZLIB_INTERNAL _tr_flush_block(s, buf, stored_len, last)
                         ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1014:19: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      int ZLIB_INTERNAL _tr_tally (s, dist, lc)
                        ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1064:12: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      local void compress_block(s, ltree, dtree)
                 ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1064:12: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1124:11: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      local int detect_data_type(s)
                ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1124:11: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1158:16: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      local unsigned bi_reverse(code, len)
                     ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1158:16: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1173:12: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      local void bi_flush(s)
                 ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1173:12: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1190:12: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      local void bi_windup(s)
                 ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/trees.c:1190:12: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      2 warnings generated.
      [ 34%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/compress/zstd_double_fast.c.o
      [ 35%] Building C object thirdparty/zlib-build/CMakeFiles/zlibstatic.dir/zutil.o
      1 warning generated.
      [ 37%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/compress/zstd_fast.c.o
      34 warnings generated.
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/zutil.c:133:22: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      const char * ZEXPORT zError(err)
                           ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/zutil.c:305:22: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      voidpf ZLIB_INTERNAL zcalloc (opaque, items, size)
                           ^
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/zlib-src/zutil.c:315:20: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
      void ZLIB_INTERNAL zcfree (opaque, ptr)
                         ^
      [ 38%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/compress/zstd_lazy.c.o
      3 warnings generated.
      [ 39%] Linking C static library ../../lib/libz.a
      [ 39%] Built target zlibstatic
      [ 40%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/compress/zstd_ldm.c.o
      [ 40%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/compress/zstd_opt.c.o
      [ 41%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/compress/zstdmt_compress.c.o
      [ 43%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/decompress/huf_decompress.c.o
      [ 44%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/decompress/zstd_ddict.c.o
      [ 45%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/decompress/zstd_decompress.c.o
      [ 46%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/decompress/zstd_decompress_block.c.o
      [ 48%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/dictBuilder/cover.c.o
      [ 49%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/dictBuilder/divsufsort.c.o
      [ 50%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/dictBuilder/fastcover.c.o
      [ 51%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/dictBuilder/zdict.c.o
      [ 53%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/deprecated/zbuff_common.c.o
      [ 53%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/deprecated/zbuff_compress.c.o
      [ 54%] Building C object thirdparty/zstd-build/lib/CMakeFiles/libzstd_static.dir/__/__/zstd-src/lib/deprecated/zbuff_decompress.c.o
      [ 55%] Linking C static library ../../../lib/libzstd.a
      [ 55%] Built target libzstd_static
      [ 56%] Building CXX object CMakeFiles/seal.dir/native/src/seal/batchencoder.cpp.o
      [ 58%] Building CXX object CMakeFiles/seal.dir/native/src/seal/ckks.cpp.o
      [ 59%] Building CXX object CMakeFiles/seal.dir/native/src/seal/ciphertext.cpp.o
      [ 60%] Building CXX object CMakeFiles/seal.dir/native/src/seal/context.cpp.o
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/context.cpp:441:91: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
              context_data_map_.emplace(make_pair(next_parms_id, make_shared<const ContextData>(move(next_context_data))));
                                                                                ^
                                                                                std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/context.cpp:456:17: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
              : pool_(move(pool)), sec_level_(sec_level)
                      ^
                      std::
      2 warnings generated.
      [ 61%] Building CXX object CMakeFiles/seal.dir/native/src/seal/decryptor.cpp.o
      [ 62%] Building CXX object CMakeFiles/seal.dir/native/src/seal/encryptionparams.cpp.o
      [ 62%] Building CXX object CMakeFiles/seal.dir/native/src/seal/encryptor.cpp.o
      [ 64%] Building CXX object CMakeFiles/seal.dir/native/src/seal/evaluator.cpp.o
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/decryptor.cpp:291:35: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
              secret_key_array_.acquire(move(secret_key_array));
                                        ^
                                        std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:808:35: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  bfv_square(encrypted, move(pool));
                                        ^
                                        std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:812:36: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  ckks_square(encrypted, move(pool));
                                         ^
                                         std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:816:35: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  bgv_square(encrypted, move(pool));
                                        ^
                                        std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:853:48: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  bfv_multiply(encrypted, encrypted, move(pool));
                                                     ^
                                                     std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:992:49: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  ckks_multiply(encrypted, encrypted, move(pool));
                                                      ^
                                                      std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:1054:48: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  bgv_multiply(encrypted, encrypted, move(pool));
                                                     ^
                                                     std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:1365:62: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  mod_switch_scale_to_next(encrypted, destination, move(pool));
                                                                   ^
                                                                   std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:1370:61: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  mod_switch_drop_to_next(encrypted, destination, move(pool));
                                                                  ^
                                                                  std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:1374:62: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  mod_switch_scale_to_next(encrypted, destination, move(pool));
                                                                   ^
                                                                   std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:1466:62: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  mod_switch_scale_to_next(encrypted, destination, move(pool));
                                                                   ^
                                                                   std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:1593:38: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  product_vec.emplace_back(move(temp));
                                           ^
                                           std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:1606:38: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  product_vec.emplace_back(move(temp));
                                           ^
                                           std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:1642:58: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
              multiply_many(exp_vector, relin_keys, encrypted, move(pool));
                                                               ^
                                                               std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:1847:53: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  multiply_plain_normal(encrypted, plain, move(pool));
                                                          ^
                                                          std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/evaluator.cpp:2355:97: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  apply_galois_inplace(encrypted, galois_tool->get_elt_from_step(steps), galois_keys, move(pool));
                                                                                ^
                                                                                std::
      [ 65%] Building CXX object CMakeFiles/seal.dir/native/src/seal/keygenerator.cpp.o
      [ 66%] Building CXX object CMakeFiles/seal.dir/native/src/seal/kswitchkeys.cpp.o
      1 warning generated.
      [ 67%] Building CXX object CMakeFiles/seal.dir/native/src/seal/memorymanager.cpp.o
      [ 69%] Building CXX object CMakeFiles/seal.dir/native/src/seal/modulus.cpp.o
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/kswitchkeys.cpp:127:50: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                          new_keys[index].emplace_back(move(key));
                                                       ^
                                                       std::
      15 warnings generated.
      [ 70%] Building CXX object CMakeFiles/seal.dir/native/src/seal/plaintext.cpp.o
      [ 71%] Building CXX object CMakeFiles/seal.dir/native/src/seal/randomgen.cpp.o
      1 warning generated.
      [ 72%] Building CXX object CMakeFiles/seal.dir/native/src/seal/serialization.cpp.o
      [ 74%] Building CXX object CMakeFiles/seal.dir/native/src/seal/valcheck.cpp.o
      [ 75%] Building C object CMakeFiles/seal.dir/native/src/seal/util/blake2b.c.o
      [ 75%] Building C object CMakeFiles/seal.dir/native/src/seal/util/blake2xb.c.o
      [ 76%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/clipnormal.cpp.o
      [ 77%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/common.cpp.o
      [ 79%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/croots.cpp.o
      [ 80%] Building C object CMakeFiles/seal.dir/native/src/seal/util/fips202.c.o
      [ 81%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/globals.cpp.o
      [ 82%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/galois.cpp.o
      [ 83%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/hash.cpp.o
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/croots.cpp:18:56: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  : degree_of_roots_(degree_of_roots), pool_(move(pool))
                                                             ^
                                                             std::
      1 warning generated.
      [ 85%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/iterator.cpp.o
      [ 86%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/mempool.cpp.o
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/galois.cpp:50:28: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  result.acquire(move(temp));
                                 ^
                                 std::
      [ 87%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/numth.cpp.o
      1 warning generated.
      [ 87%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/polyarithsmallmod.cpp.o
      [ 88%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/rlwe.cpp.o
      [ 90%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/rns.cpp.o
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/numth.cpp:301:46: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                          destination.emplace_back(move(new_mod));
                                                   ^
                                                   std::
      1 warning generated.
      [ 91%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/scalingvariant.cpp.o
      [ 92%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/ntt.cpp.o
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/rns.cpp:19:21: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  : pool_(move(pool)), size_(rnsbase.size())
                          ^
                          std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/rns.cpp:59:78: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
              RNSBase::RNSBase(const RNSBase &copy, MemoryPoolHandle pool) : pool_(move(pool)), size_(copy.size_)
                                                                                ^
                                                                                std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/rns.cpp:567:21: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                  : pool_(move(pool))
                          ^
                          std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/ntt.cpp:229:108: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
              NTTTables::NTTTables(int coeff_count_power, const Modulus &modulus, MemoryPoolHandle pool) : pool_(move(pool))
                                                                                ^
                                                                                std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/ntt.cpp:319:83: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                      : coeff_count_power_(coeff_count_power), modulus_(modulus), pool_(move(pool))
                                                                                ^
                                                                                std::
      [ 93%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/streambuf.cpp.o
      2 warnings generated.
      [ 95%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/uintarith.cpp.o
      3 warnings generated.
      [ 96%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/uintarithmod.cpp.o
      [ 97%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/uintarithsmallmod.cpp.o
      [ 98%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/uintcore.cpp.o
      [100%] Building CXX object CMakeFiles/seal.dir/native/src/seal/util/ztools.cpp.o
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/ztools.cpp:37:67: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                          PointerStorage(MemoryPoolHandle pool) : pool_(move(pool))
                                                                        ^
                                                                        std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/ztools.cpp:44:46: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                              ptr_storage_[addr] = move(ptr);
                                                   ^
                                                   std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/ztools.cpp:395:59: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                      auto ret = zlib_deflate_array_inplace(in, move(pool));
                                                                ^
                                                                std::
      /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src/seal/util/ztools.cpp:755:59: warning: unqualified call to 'std::move' [-Wunqualified-std-cast-call]
                      auto ret = zstd_deflate_array_inplace(in, move(pool));
                                                                ^
                                                                std::
      4 warnings generated.
      [100%] Linking CXX static library lib/libseal-4.0.a
      [100%] Built target seal
      building 'Afhel' shared library
      creating build/temp.macosx-10.9-x86_64-3.9/private
      creating build/temp.macosx-10.9-x86_64-3.9/private/var
      creating build/temp.macosx-10.9-x86_64-3.9/private/var/folders
      creating build/temp.macosx-10.9-x86_64-3.9/private/var/folders/ks
      creating build/temp.macosx-10.9-x86_64-3.9/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn
      creating build/temp.macosx-10.9-x86_64-3.9/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T
      creating build/temp.macosx-10.9-x86_64-3.9/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu
      creating build/temp.macosx-10.9-x86_64-3.9/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356
      creating build/temp.macosx-10.9-x86_64-3.9/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel
      creating build/temp.macosx-10.9-x86_64-3.9/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/Afhel
      /usr/bin/gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -fwrapv -O2 -Wall -fPIC -O2 -isystem /opt/anaconda3/include -arch x86_64 -I/opt/anaconda3/include -fPIC -O2 -isystem /opt/anaconda3/include -arch x86_64 -g -I/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/Afhel -I/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/native/src -I/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/build/temp.macosx-10.9-x86_64-3.9/Pyfhel/SEAL/thirdparty/msgsl-src/include -I/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/native/src -I/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/backend/SEAL/thirdparty/msgsl-src/include -c /private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/Afhel/Afseal.cpp -o build/temp.macosx-10.9-x86_64-3.9/private/var/folders/ks/12yn37bn4l5_xvrw2j7nv7900000gn/T/pip-install-wnm9dueu/pyfhel_d018f977886143ffa8f4a19ef6f63356/Pyfhel/Afhel/Afseal.o -std=c++17 -O3 -fopenmp
      clang: error: unsupported option '-fopenmp'
      error: command '/usr/bin/gcc' failed with exit code 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for Pyfhel
Failed to build Pyfhel
ERROR: Could not build wheels for Pyfhel, which is required to install pyproject.toml-based projects

After some intense fights, there is an official way to install Pyfhel in MacOs, and it requires installing gcc with brew and setting some environment variables. Check the Readme for more info!

Ho very good news ! I'll test it :)

Closing as the installation on M1 Pro has been tested and properly documented in the README. Reopen if the issue still persists.


Add example that shows TypeScript usage

Our components are all written in TypeScript. Is there support for using TypeScript and possibly typings for react-static?
Glad to have an alternative to next.js and would love to switch.
Great Work!
Dino

@D1no We don't use Typescript ourselves, so we're not likely to add that anytime soon, but we'd be open to a PR!

Thats too bad. That is one of the burning issues of next.js and project groups, that already have a component library or logic. I wrote about it here; related to the blocking PR below
https://github.com/zeit/next.js/issues/2391#issuecomment-325627560
https://github.com/zeit/next.js/pull/2699
Maintaining ecmascript variations is unfortunately quite difficult outside a core team.

@D1no So you're less interested in having react-static type definitions and more interested in making sure that TypeScript compiles during the build cycle?

Yes exactly. Since everything is react — I guess the few untyped properties of react-static are discardable. But not being able to to use existing code is quite a bummer

@tannerlinsley Shouldn't that be possible?

Technically yes. You can use custom webpack loaders, so using a typescript
loader wouldn't be a problem at all. When using the react static browser
components, you won't have type safety. But if someone wanted to submit
types that would not be the case.
On Sun, Oct 8, 2017 at 11:01 AM Derek Perkins<EMAIL_ADDRESS>wrote:

@tannerlinsley https://github.com/tannerlinsley Shouldn't that be
possible?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nozzle/react-static/issues/8#issuecomment-335020816,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFUmCfpujwNSxykgPTuGRymwF3fd0aQZks5sqP_NgaJpZM4PxtNd
.

Sure! Thanks!

So I gave it a shot now on updating the rule-set for typescript. I get it to compile, but it crashes in the browser. Maybe a Webpack crack can take a look whats missing.
Essentially its about replacing the original babel rule with one that includes a pre-stage with awesome-typescript-loader.
Reproduction Repo: https://github.com/D1no/react-static-typescript
The commits detail what I needed to do to get this far.
clone
yarn install
yarn start

Essential config in static.config.js
// For TypeScript Resolution
import { CheckerPlugin, TsConfigPathsPlugin } from "awesome-typescript-loader"

// (...)

  webpack: (webpackConfigurator, { dev }) => {

    // Add .ts & .tsx extension to config
    webpackConfigurator.merge({
      resolve: {
        extensions: ['.ts', '.tsx']
      }
    })

    // We can take a look at the current Webpack Config via webpackConfigurator._config
    // Lets overwrite the default rule resolution for source files found here:
    // https://github.com/nozzle/react-static/blob/master/src/rules.js#L5

    // Update Rule to use awesome-typescript-loader
    // Extending the default ruleset with typescript support (normal webpack rule)
    let typeScriptRule = {
      test: /\.(js|jsx|ts|tsx)$/,
      // Keeping the original exclude path
      exclude: webpackConfigurator._config.module.rules[0].exclude,
      use: [
        {
          loader: 'babel-loader',
        },
        {
          loader: 'awesome-typescript-loader',
        }
      ]
    }

    // Overwrite the first (original js-transform) rule with our extended version
    webpackConfigurator._config.module.rules[0] = typeScriptRule;

    // For async error reporting of as-typescript
    webpackConfigurator.plugin("typescript-checker-plugin", CheckerPlugin)

    // For resolving potential alias paths inside the typescript.json
    webpackConfigurator.plugin("typescript-path-plugin", TsConfigPathsPlugin)

  }

Renaming i.e. Home.js to Home.tsx transpiles without problems

but crashes terribly in the browser

Check this
https://github.com/gloorx/nextjs-typescript-boilerplate

With the latest changes to version 2.0.0, this should now be extremely possible. Using the webpack callback you can easily modify or completely replace any aspect of the webpack config to make this work. It might take some fine tuning to get this right, but it's definitely possible now.

What the current status of this? Can I help?

Yes - a webpack config as an example in a static.confog.je would help a lot. I am just blocked right now that I can not even get a breath of air .... far from Open Source :/

@D1no so, as I understand, it's possible to make example with typescript right now? For example I can modify your Reproduction Repo and it will work?

The reproduction repo is on an outdated version of static-react. That needs to be updated and than possibly adapted to the new version according to the changelog. I think a normal webpack setup should do now. But I don’t have access to check myself (out of country atm)

I don't know that react-static should be advertised as having full TypeScript support yet if it's not possible to completely rename all .js component files to .tsx. I see the same console errors mentioned earlier when renaming the Home component. Has anyone been able to rename all .js component files to .tsx and successfully compile and run the TS example?

I think that is a harsh assumption. TypeScript, like Babel, is a preprocessor of which presets in babel and compiler options / definition files are an extension. React-Static compiles all .tsx files, allows to use typescripts flexible paths options, includes hot module replacement and compiles — none-the-less — of warnings the typescript language service may throw up in your EDI.
Definition files are very straight forward and I invite anyone to update them along with the changes to the codebase. However, even if those would not exist or overwritten by the user, all typescript code will be transpiled and handled without problems.
So from my point of view, and probably @tannerlinsley's, full support is there. The definition file should be maintained for the language service for which I am happy to see support from any side possible.
Best
Dino


How can I configure IntelliSense autocomplete on WebStorm?

Hello,
How can I configure IntelliSense autocomplete on WebStorm?

The same problem keeps confusing me for quite a long time... Waiting for a great solution!
I have only seen this https://youtrack.jetbrains.com/issue/WEB-48505/Tailwind-CSS-regex-support-custom-class-name-completion-contexts

Waiting for this too! +1

Webstorm 2024.1.5
Languages & Frameworks > Style Sheets > Tailwind CSS
Add two properties - typescript, typescriptreact
  "includeLanguages": {
    "typescript": "javascript",
    "typescriptreact": "javascript"

add theese classRegex
  "experimental": {
    "classRegex": [
      "tw`([^`]*)",
      "tw\\.[^`]+`([^`]*)`",
      "tw\\(.*?\\).*?`([^`]*)"
    ]
  }


rendering on Safari bug

Just an FYI. I have no idea what this means and don't need it. Feel free to close.
I ran your example and made some edits to see test it in the ui.
This is firefox:

This is Safari:

Environment:
➜  example macenv
ProductName:	Mac OS X
ProductVersion:	10.15.2
BuildVersion:	19C57
yarn version: 1.21.1
node version: v13.3.0

thanks for reporting!
It seems that the package I am using is not supposed to be a polyfill but an alternative one (strange tho, I think they advertise it as one)

Since there isn't much polyfills to be found, the closest I can get is from the package broadcastchannel-polyfill.
Currently, the problem here is that Safari doesn't support this feature in the first place (a shame).
I'll mark this as fixed.


Roll Flutter Engine from 9c3f66d822e4 to eee831b37a0b (6 revisions)

https://github.com/flutter/engine/compare/9c3f66d822e4...eee831b37a0b
2024-08-30<EMAIL_ADDRESS>Reverts "Roll Dart SDK from 88d311c9a531 to 995324d1b218 (1 revision) (#54896)" (flutter/engine#54901)
2024-08-30<EMAIL_ADDRESS>Roll Dart SDK from 88d311c9a531 to 995324d1b218 (1 revision) (flutter/engine#54896)
2024-08-30<EMAIL_ADDRESS>Roll Fuchsia Test Scripts from NWpblL_DFACOx_Spi... to DtxLvjJOVzo_oZGui... (flutter/engine#54891)
2024-08-30<EMAIL_ADDRESS>Roll Skia from c23d19fdf117 to 2b633f7626ea (1 revision) (flutter/engine#54890)
2024-08-30<EMAIL_ADDRESS>Roll Skia from 9ce15f8b2c7e to c23d19fdf117 (2 revisions) (flutter/engine#54889)
2024-08-30<EMAIL_ADDRESS>Roll Dart SDK from 139867e57ba9 to 88d311c9a531 (1 revision) (flutter/engine#54886)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC matanl@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


List[str] attr.ib element aggregates over multiple instantiations

The following code illustrates the case. The element ll should be newly created for each class instance. However it aggregates the values together and is sharing a single ll instance for all instantiated classes:
from typing import List
from typing import List

@attr.s
class TT(object):
    name: str = attr.ib()
    ll: List[str] = attr.ib(default=[])
    def __attrs_post_init__(self):
        self.ll.append(['a','b','c'])

tt1 = TT(name='1')
tt2 = TT(name='2')
print(tt1,tt2)
TT(name='1', ll=[['a', 'b', 'c'], ['a', 'b', 'c']]) TT(name='2', ll=[['a', 'b', 'c'], ['a', 'b', 'c']])```

I don't believe that the ll element should be a static class level element and rather should be an instance element.
If I change the code as follows, the problem goes away:
from typing import List
from typing import List

@attr.s
class TT(object):
    name: str = attr.ib()
    ll: List[str] = attr.ib(default=[])
    def __attrs_post_init__(self):
        self.ll=[]
        self.ll.append(['a','b','c'])

tt1 = TT(name='1')
tt2 = TT(name='2')
print(tt1,tt2)
TT(name='1', ll=[['a', 'b', 'c']]) TT(name='2', ll=[['a', 'b', 'c']])

Adding an initializer for ll resets it with each invocation, but IMO this shouldn't be necessary and is counter intuitive.

That's how Python works with mutable defaults, nothing special for attrs.
To fix your code use ll = attr.ib(default=attr.Factory(list))

Fix confirmed, thank you.


Logger added.

Logger Added.
It was on TODO I wanted to complete it.

Can we please use https://github.com/sirupsen/logrus instead? It has levels and already has all the functionality we need. Thanks for adding this though!

I have used it in production at many banks for years. It's good for production usage 👍

I have used it in the past, but actually you are right. We should pick one of

https://github.com/rs/zerolog
https://github.com/uber-go/zap
https://github.com/apex/log

Zerolog seems to be an improvement on zap, and apex seems to be an integration on top of logging libraries. In that case I think we should use zerolog. What do you think?

Yeah, I agree I added zerolog implementation and some unit tests.


CNN channels.md

Job d2l-zh/PR-597/1 is complete.
Check the results at http://preview.d2l.ai/d2l-zh/PR-597/

Job d2l-zh/PR-597/2 is complete.
Check the results at http://preview.d2l.ai/d2l-zh/PR-597/

Job d2l-zh/PR-597/3 is complete.
Check the results at http://preview.d2l.ai/d2l-zh/PR-597/

Job d2l-zh/PR-597/4 is complete.
Check the results at http://preview.d2l.ai/d2l-zh/PR-597/

Job d2l-zh/PR-597/5 is complete.
Check the results at http://preview.d2l.ai/d2l-zh/PR-597/

Job d2l-zh/PR-597/6 is complete.
Check the results at http://preview.d2l.ai/d2l-zh/PR-597/


DynamicWidgets does not work with Remix Link

🐛 Current behavior
When the component which is passed to the getServerState method contains DynamicWidgets and Link from “@remix-run/react” components it causes the app to break with the error: “useHref() may be used only in the context of a  component.”. If DynamicWidgets or Link is removed then everything seems fine
🔍 Steps to reproduce

Go to https://codesandbox.io/p/sandbox/lucid-cerf-glr0tu
Everything should work fine, you can see filters and hits
In app/components/Search.tsx change line 97 from <Hits hitComponent={Hit} /> to <Hits hitComponent={HitWithLink} /> (same component just wrapped with Link)
"Error: useHref() may be used only in the context of a  component."
Now delete <DynamicWidgets>, refresh and the app is working again (just without filters)

Live reproduction
https://codesandbox.io/p/sandbox/lucid-cerf-glr0tu
💭 Expected behavior
DynamicWidgets should work with Remix Link
Package version
react-instantsearch-hooks-web 6.41.0, react-instantsearch-hooks-server 6.41.0
Operating system
macOS
Browser
Chrome
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hi, in getServerState() when we detect a dynamic widget we run renderToString on your search component a second time to get the initial state of all the dynamic facets we received from Algolia. This time, apparently the router context is lost, which creates the error you see.
We'll look at if and how we can fix that, but in the meantime, you can conditionally wrap your Hit component with a Link, depending on whether you detect a router context or not. Here's an example:
import { useInRouterContext } from 'react-router';

/* ... */

function HitWithLink({ hit }: HitProps) {
  const inRouterContext = useInRouterContext();
  const Hit = () => (
    <>
      <Highlight hit={hit} attribute="name" className="Hit-label" />
      ${hit.price}
    </>
  );

  if (inRouterContext) {
    return (
      <Link to="/new">
        <Hit />
      </Link>
    );
  }

  return <Hit />;
}


tests: round trip test for blob submission/retrieval

Overview
Basic round trip test that submits a blob and then reads it back from DA.
Resolves #27.

Checklist

[x] New and updated code has appropriate documentation
[x] New and updated code has new and/or updated testing
[x] Required CI checks are passing
[x] Visual proof for any user facing features like CLI or documentation updates
[x] Linked issues closed with keywords

Another follow-up is to test the submission of multiple blobs.

2 blobs the same namespace
2 blob different namespaces

Another test is to ask for a namespace with no blob inside. Basically to catch if the error handling changes.


Finished translating sections 3, 8 and evens.  Corrected minor errors in sections 0,1.

The translation of the new units is done.
Agreed with Sergey to use the comment symbol in the table of contents file to make it easier to synchronize the uniformity when translating titles.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

@MKhalusova Seems to have answered all the comments. From now on, I will try to be more attentive and take my time. Regarding the extra line breaks, I haven't realized yet at what stage there are more of them, I'm dealing with the problem. Thanks Maria!


ErrorProneInjector incorrectly picks up the no-args constructor

The logic of determining the constructor of a checker class changed in commit 1c3c09f5c286989f76eb545613c9ce91dac4acad. Previously it explicitly checked for a constructor with a single parameter of type ErrorProneFlags; now it looks for a constructor with all parameters having this type. The issue is that the condition used - allMatch - also returns true if there are no parameters at all, so the no-args constructor also matches the test.
The impact is that when I have a test for a checker which needs to take additional flags, the CompilationTestHelper uses the wrong constructor to create the checker instance, making it impossible to pass flags in a test.

@ksobolew this sounds similar to something that initially puzzled me when upgrading to Error Prone 2.19+. Then I realized that just annotating the ErrorProneFlags-accepting constructors with @Inject suffices. See the changes in PicnicSupermarket/error-prone-support#621 for an example. Hope this helps!

Check; I suppose that's something for @graememorgan to have an opinion on :)

Hah, I think I thought of that edge case when I wrote it, but decided it wouldn't matter for some reason. :)
I would expect the inject constructor to be annotated @Inject and therefore win.

The impact is that when I have a test for a checker which needs to take additional flags, the CompilationTestHelper uses the wrong constructor to create the checker instance, making it impossible to pass flags in a test.

Could you provide a minimal example which is a problem?

Could you provide a minimal example which is a problem?

IIRC ~any test that provides a non-vacuous set of flags using setArgs should trigger the issue.
On example:
git clone git@github.com:PicnicSupermarket/error-prone-support.git
cd error-prone-support
sed -i '/Inject/d' error-prone-contrib/src/main/java/tech/picnic/errorprone/bugpatterns/RedundantStringConversion.java
mvn clean install -Dverification.skip -DskipTests
mvn test -Dtest='RedundantStringConversionTest#identificationOfCustomConversionMethod' -pl error-prone-contrib

sed -i '/Inject/d' error-prone-contrib/src/main/java/tech/picnic/errorprone/bugpatterns/RedundantStringConversion.java

But can it be fixed by just including the @Inject? Ideally we'd like @Inject to be used for the injectable constructor.
(I'm not suggesting not fixing this to match the original behaviour, but chucking some @Injects around would be good anyway.)

Yes, it can be fixed this way. I originally didn't realize that, so the severity is much lower than I thought. Now it's just mostly a source of confusion :)

The warning-level InjectOnBugCheckers check should help, though many may have disabled it due to the false-positives it reported in an earlier version. Perhaps adding a hint to the release notes could also help. :)

Should be fixed now; give me a shout about any further problems.


[UT] add nested array test for parquet ingesting

What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[x] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto backported to target branch

[ ] 2.5
[ ] 2.4
[ ] 2.3
[ ] 2.2

run starrocks_be_unittest

@mergify rebase

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test


Tut 001

Thank you @Badr2211 for your work.
Sorry, I have to cancel this PR, since this repo now is a reference for others to learn.
You create your (own) repo and start applying there.
Thanks again, and keep following the course.