add api for cluster manager to get table state

remove unused file
Description
Add API endpoint for cluster manager to get the table current state. fixes Issue 6169.
Upgrade Notes
Does this PR prevent a zero down-time upgrade? (Assume upgrade order: Controller, Broker, Server, Minion)

[ ] Yes (Please label as backward-incompat, and complete the section below on Release Notes)

Does this PR fix a zero-downtime upgrade introduced earlier?

[ ] Yes (Please label this as backward-incompat, and complete the section below on Release Notes)

Does this PR otherwise need attention when creating release notes? Things to consider:

New configuration options
Deprecation of configurations
Signature changes to public methods/interfaces
New plugins added or old plugins removed

[ ] Yes (Please label this PR as release-notes and complete the section on Release Notes)

Release Notes
If you have tagged this as either backward-incompat or release-notes,
you MUST add text here that you would like to see appear in release notes of the
next release.
If you have a series of commits adding or enabling a feature, then
add this section only in final commit that marks the feature completed.
Refer to earlier release notes to see examples of text
Documentation
If you have introduced a new feature or configuration, please add it to the documentation as well.
See https://docs.pinot.apache.org/developers/developers-and-contributors/update-document

Codecov Report

Merging #6211 into master will decrease coverage by 20.10%.
The diff coverage is 49.14%.

@@             Coverage Diff             @@
##           master    #6211       +/-   ##
===========================================
- Coverage   66.44%   46.34%   -20.11%
===========================================
  Files        1075     1237      +162
  Lines       54773    58586     +3813
  Branches     8168     8667      +499
===========================================
- Hits        36396    27152     -9244
- Misses      15700    29226    +13526
+ Partials     2677     2208      -469

Flag
Coverage Δ

#integration
46.34% <49.14%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...ot/broker/broker/AllowAllAccessControlFactory.java
100.00% <ø> (ø)

.../helix/BrokerUserDefinedMessageHandlerFactory.java
52.83% <0.00%> (-13.84%)
:arrow_down:

...org/apache/pinot/broker/queryquota/HitCounter.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...che/pinot/broker/queryquota/MaxHitRateTracker.java
0.00% <0.00%> (ø)

...ache/pinot/broker/queryquota/QueryQuotaEntity.java
0.00% <0.00%> (-50.00%)
:arrow_down:

...ava/org/apache/pinot/client/AbstractResultSet.java
26.66% <0.00%> (-30.48%)
:arrow_down:

.../main/java/org/apache/pinot/client/Connection.java
22.22% <0.00%> (-26.62%)
:arrow_down:

.../org/apache/pinot/client/ResultTableResultSet.java
24.00% <0.00%> (-10.29%)
:arrow_down:

...not/common/assignment/InstancePartitionsUtils.java
64.28% <ø> (-8.89%)
:arrow_down:

.../apache/pinot/common/exception/QueryException.java
90.27% <ø> (+5.55%)
:arrow_up:

... and 1224 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 85a0804...48fc2fb. Read the comment docs.

@galalen is there anything pending in this PR?

@galalen is there anything pending in this PR?

@kishoreg, @npawar Yes, I'm working on unit and the integration test.
I want to make sure reading the IdealState will give me the current state.

@galalen is there anything pending in this PR?

@kishoreg, @npawar Yes, I'm working on unit and the integration test.
I want to make sure reading the IdealState will give me the current state.

Are you planning to add any unit test? One test in the PinotTableRestletResourceTest would be nice

@galalen is there anything pending in this PR?

@kishoreg, @npawar Yes, I'm working on unit and the integration test.
I want to make sure reading the IdealState will give me the current state.

Are you planning to add any unit test? One test in the PinotTableRestletResourceTest would be nice

unit test added


Issue828 collimator cam

Main changes:

add_camera_1d() now handles unique unit vectors
Implemented collimator in tuto_real0.py
Started collimator camera handling, TBF

Issues:
Fixes, in devel, issue #828

Hello @Didou09! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file tofu/data/_class7_check.py:

Line 55:1: E303 too many blank lines (3)
Line 210:80: E501 line too long (80 > 79 characters)
Line 229:80: E501 line too long (80 > 79 characters)
Line 257:80: E501 line too long (83 > 79 characters)
Line 262:80: E501 line too long (83 > 79 characters)
Line 267:80: E501 line too long (82 > 79 characters)

In the file tofu/data/_class8_check.py:

Line 76:80: E501 line too long (81 > 79 characters)
Line 82:80: E501 line too long (81 > 79 characters)
Line 201:11: E203 whitespace before ':'

In the file tofu/tests/tests09_tutorials/tuto_real0.py:

Line 289:1: E303 too many blank lines (3)


DM parsing PAPI placeholder before parsing Args placeholder

Version 1.14.1-DEV-178
Server Version git-Purpur-2158 (MC: 1.20.4)
(Issue opened on advice from Prestley in HelpChat)
As described in the title. When trying to get DeluxeMenus to parse something like %luckperms_meta_{player}_wealth%, the placeholder breaks.

Hello @ElysiumSMP, I have attempted to use the %luckperms_meta_{player}_wealth% placeholder myself but it does not seem to exist. Parsing it even with this command /papi parse me %luckperms_meta_BlitzOffline_wealth% returns nothing. The same as using your example inside a menu.
After taking a look at luckperms' wiki, I could not find any specification of the placeholder you were using. The only similar placeholder I found was %luckperms_meta_wealth%.
Of course, I have set a value for my wealth key using /lp user BlitzOffline meta set wealth abc and the placeholder I found on the wiki does work.

After looking more over this issue, I have found the root cause. It is a side effect of our changes regarding parsing placeholders inside arguments.
We have previously made some changes to how arguments and placeholders are handled.
How it used to work:

Parse Arguments
Parse Placeholders

How it works now:

Parse placeholders
If enabled, parse placeholders inside arguments
Parse arguments

These changes were made because we've realized that letting players parse arbitrary placeholders is bad. In my opinion, placeholders should be simple mapping operations without any side effects. Not everyone agrees or sticks by this rule. Some placeholders do things such as giving items to players, executing commands, etc. when they are parsed.
When I've made the changes, I have allowed menu designers to enable placeholder parsing inside arguments on a per-menu basis. I have missed that parsing arguments after parsing placeholders, does not allow menu designers to use arguments inside placeholders anymore.
We might have to revert these changes or add a new option that would allow menu designers to switch the order in which arguments and placeholders are parsed. If we were to add this new option, I think the option that parses placeholders that are inside arguments should be removed.
Feedback is very much appreciated!

Hi @BlitzOffline, thank you for your prompt response, and apologies for my relatively late response.

Hello @ElysiumSMP, I have attempted to use the %luckperms_meta_{player}_wealth% placeholder myself but it does not seem to exist. Parsing it even with this command /papi parse me %luckperms_meta_BlitzOffline_wealth% returns nothing. The same as using your example inside a menu.

In response to the above, %luckperms_meta_{player}_wealth% is just an example meta key that utilises an arg within a placeholder. What I was using it for on my server, is to use args to call different data based on what the player specifies:

For instance, I might have a command such as /warp {args} (which opens up a warp menu), and I'd use the placeholder %luckperms_meta_warp_{args}_name% to call the name of the specified warp.

We might have to revert these changes or add a new option that would allow menu designers to switch the order in which arguments and placeholders are parsed. If we were to add this new option, I think the option that parses placeholders that are inside arguments should be removed.

Thank you for the detailed information. I personally do not really see as much utility in allowing placeholders to be parsed within arguments compared to the former, so I would prefer removing it. Then again I am biased haha.

Hi there, any updates here?

Bump

@ElysiumSMP I have opened a PR to add a new option that would fix your issue (#99). If you don't want to wait until that is merged, you can test this build:
DeluxeMenus-1.14.1-DEV-local-build.zip


Make RP registration policy more reusable

Feature Request
We are using the Azure SDK for Go (Track 2) in the context of a Kubernetes reconciler. One of the tenants of a Kubernetes reconciler is to not block the goroutine running the reconciliation process for a long time. If you encounter a failure, retries will be handled automatically if you return that failure to the coordinating infrastructure.
As part of following that best practice, we disable retries in the SDK. Retries will be done by the reconciliation infrastructure instead so there need not be SDK specific retries (or their corresponding delays).
We would love to use the SDKs built in RP registration policy, but unfortunately there's no good way to avoid a delay waiting for the RP to register.
Our ideal solution: would send the initial request to ARM, check the response, issue the RP registration call to ARM if the response was MissingSubscriptionRegistration and then return an error that said something like: RP registration is ongoing
We investigated 2 options for achieving this with the existing policy:

Disable RP registration entirely. This is well supported in the SDK but doesn't meet our needs of automatically registering RPs.
Enable RP registration, set MaxAttempts = 1 and PollingDelay and PollingDuration to 0 seconds. This results in the RP registration request being sent to ARM, but then the policy immediately times out with a context cancellation. This gets us almost there, but the problem is that we can't differentiate this error from a networking timeout and so the user on our end would see spurious timeout errors we couldn't suppress/hide from them. This is confusing.

What we've done in the meantime: We copied the RP registration code and modified it to remove the delays and return a well-established error.
What would we like:
I'm not sure that many other use-cases will want this exact behavior, although it's possible other people in the context of a Kubernetes operator will. In any case, what would be nice is either this option officially supported by the SDK with a flag passed to NewRPRegistrationPolicy, or a publicly exported set of function(s) that did most of the work of actually detecting this error and sending a new request, so that we don't have to duplicate code to achieve it.
If this is something you're willing to entertain, we might be willing to send you a PR to do it. Open to thoughts on what the best user experience would look like.

We could add a feature that, when PollingDuration < 0, the policy doesn't wait for the terminal registration state.  Still need to decide how best to surface this.

Thinking about this a bit more.  The RP registration code is just copied from the armresources module.  It might be best to simply disable the policy and roll your own RP registration handling that uses this module instead.  What do you think?

That's basically what I've done, and yeah, it might make sense to just have that be the official answer.
I did notice that the official implementation of this doesn't use some builtins like NewResponseError, instead opting to define its own error structure:
// minimal error definitions to simplify detection
type requestError struct {
	ServiceError *serviceError `json:"error"`
}

type serviceError struct {
	Code    string                `json:"code"`
	Details []serviceErrorDetails `json:"details"`
}

type serviceErrorDetails struct {
	Code   string `json:"code"`
	Target string `json:"target"`
}

Curious if you know the reasoning for that? I've followed that approach in my fork (which was part of where I was thinking there was a good bit of duplicate code), but possibly there's no good reason to do that and I could instead just use NewResponseError and delete all of that...
In any case, happy to close this.

The official Azure policy is that for error responses, the only parts that are contractual are the service error code and the HTTP status code; this is why we only return an *azcore.ResponseError from our APIs.
For this policy, as you know, we need to extract some of the details from the error in order to register the RP.  Could have done it a few different ways, I just copied the code from the track 1 implementation.

Closing per our discussion.


Support Delta Merge with DBR 11.3 LTS and OL 0.18

The latest runtime with OL 0.18 should support Delta Merge statements!

Complete with release/2.3


Fix null parsing on S3 notification email

When parsing an S3 notification email as part of pre-processing some special characters like "=20" were removed and caused an error during parsing in some emails with a document URL like the following:
https://ecf.cod.uscourts.gov/doc1/20914522284?caseid=206379&de_seq_num=204&magic_num=20105679
Parameters starting with 20 like caseid=206379, de_seq_num=204, magic_num=20105679 failed during parsing since =20 were replaced by a white space
In order to solve this problem, before replacing =20, we replace temporarily url variables caseid= de_seq_num= magic_num= by  caseid% de_seq_num% magic_num%  then replace =20 characters and finally restore url variables to caseid= de_seq_num= magic_num=
A special test case like the one described was added in order to verify the problem is gone.

There's more than one problem with malformed HTML in CMECF NEFs. For instance, gmail renders these (see the email list in the screenshot) as literal & n b s p strings, presumably because of the lack of a terminating ;. The point being, I suspect the problem is more general and worry this solution, as described, may be too narrow.

@johnhawkinson if the emails contain &nbsp without a semi-colon, I think we do like gmail does and just ignore it. That seems fine. Is there another example that we'd want to deal with?
@albertisfu, I'm a bit confused here why we have to do do the find/replace of all these funny characters in general. Aren't they only in the plaintext versions? For example, the test case you added, there are no =20's. Maybe we only do this find and replace in plaintext emails or something like that?

@mlissner yes I'm also confused about s3 email examples some of them the content is in plain text and others are in HTML, I think those ones in plain text that have some special characters need to be converted to: =2E->.  ,  =C2=A0->   ,  =3D->=   and  =20 ->
I looked for '=20' in s3 example emails and the only test case where a could find a =20 character in content is this one https://github.com/freelawproject/juriscraper/blob/main/tests/examples/pacer/nef/s3/arwd_5.txt#L199
FileNumber=2082324-0
This one is an HTML case so I don't know if in this case, it is correct to replace =20 to be a white space because it would change FileNumber 82324-0 but I think we are not getting this number when parsing.
So I'm not sure if it would exist a case where is necessary to  transform=20 to a white space, if not maybe we could avoid replacing =20
In the test case I added, I used a URL like the one we had problems parsing because it contains =20 :
https://ecf.cod.uscourts.gov/doc1/20914522284?caseid**=20**6379&de_seq_num**=20**4&magic_num**=20**105679
So we this test we just verify that we avoid replacing those =20 and parse correctly.

I was able to talk to @tewen about this a bit. The idea for the scraper at present is that it can work on both plaintext or HTML emails (it doesn't look like PACER has figured out what multi-part ones are yet!).
I think that means we should:

Detect early on if an email is HTML or plaintext.
If plaintext, do the find/replace thing.
If not, don't.

It also occurs to me that we'll still have this bug in plaintext emails if we continue blindly replacing =20 characters, so on top of only applying the find/replace to plaintext emails, we also need to do so more carefully. Maybe it only applies to =20\n, for example.
Trevor is going to send some plaintext email examples tonight, but in the meantime, maybe we can just fix it so HTML works properly?

@johnhawkinson if the emails contain &nbsp without a semi-colon, I think we do like gmail does and just ignore it. That seems fine. Is there another example that we'd want to deal with?

Not offhand. It's just my recollection that CMECF HTML may be noncompliant.
But it sounds like a rather different problem here. Why would you be worrying about =20 in plaintext emails? It seems like your MIME parser is wrong (or you're not using one?) Unless you're saying they are Content-Transfer-Encoding: quoted-printable and that is malformed?
For sure you should not be applying corrections that apply to one encoding to the other.

(it doesn't look like PACER has figured out what multi-part ones are yet!)

I think CMECF (what's this PACER thing?) made the right design choice here, to give users a knob whether they get a plain-text email or an HTML email, rather than sending multipart. Especially when sometimes the emails are huge. Maybe we are at the point where multipart/alternative emails work so well that nothing else should ever be sent, but my experience is that email display and formatting has only been getting jankier with time, not better.

or you're not using [a mime parser]

Yeah, I think that's probably the core of it. Alberto, do you think you could take a stab at upgrading this to use an email parser at the first step and then handle the HTML or the plaintext as a second step?
This looks like a decent starting place: https://stackoverflow.com/questions/17874360/python-how-to-parse-the-body-from-a-raw-email-given-that-raw-email-does-not
What's your take?

Sure I think that would be the right approach, let me check this, if I have any questions I'll be asking you.

@albertisfu @mlissner and @johnhawkinson put 10 emails with both plain text and HTML up here: https://drive.google.com/file/d/1MiTgdukDlVHQwhcft2sMC1AZIXNZexr_/view?usp=sharing

I'm aware that the goal of email parser is that it could work properly for HTML or plain text emails.
Reviewing current test cases and the last ones that Trevor sent us, I can see that all of those emails have a version in text/html and some of them also have a text/plain version in the same file, if I'm not wrong in those cases the text/plain version is added when the email is forwarded.
My questions are:

when getting emails from PACER, emails could have both versions (text/htmland text/plain) in the same file or it's just possible to get one or another?

In case we get emails with both versions, which one should we prioritize to parse, text/html or text/plain?

Reviewing current test cases and the last ones that Trevor sent us, I can see that all of those emails have a version in text/html and some of them also have a text/plain version in the same file, if I'm not wrong in those cases the text/plain version is added when the email is forwarded.

Unfortunately, the method Trevor used to forward doesn't preserve encodings, so those are not very useful.

when getting emails from PACER, emails could have both versions (text/htmland text/plain) in the same file or it's just possible to get one or another?

CMECF sends emails either as text/html or as text/plain but not both.
Of course this could change in the future.

In case we get emails with both versions, which one should we prioritize to parse, text/html or text/plain?

I don't think it matters a whole lot, but CMECF does include markup in docket text, and that markup is lost in text/plain.
So all things being equal, prefer the html version. That said, Courtlistener does not do a good job of handling that markup (we strip it), which is bad, but it means it doesnt' matter much.
Digging through my mailbox, here's an old example of a text/plain email from back when I had NEFs configured in that fashion: manafort2019.mbox.zip
.

Understood, thanks @johnhawkinson

Thanks John! Yes, I agree with everything he said!

MIME Parser email implemented, now it's not necessary to replace special characters.
Added support for parse text/plain emails and added a test case for it, I'm afraid that we are going to need more text/plain emails examples to ensure it works properly.
For example, I have a doubt about docket description, in this example, we have something like this:
Docket Text:
Joint  STATUS REPORT    by USA
as to RICHARD W. GATES, III (Weissmann, Andrew)

Right now I'm parsing as: Joint  STATUS REPORT by USA
Is this correct?

Huh! I had never noticed there was HTML markup in the text/plain NEFs. I wonder if that's still true, three years later, and I wonder if it's specific to ecf.dcd? I don't have a huge corpus of them. Although I could change some of my HTML notifications to text/plain and wait-and-see what the court drags in…

Right now I'm parsing as: Joint STATUS REPORT by USA

Err, no? Did you inadvertently truncate? It should be
Joint  STATUS REPORT by USA as to RICHARD W. GATES, III (Weissmann, Andrew)
Just as it appears at https://www.courtlistener.com/docket/6249516/united-states-v-manafort/?filed_after=&filed_before=&entry_gte=551&entry_lte=551&order_by=asc
You could also, perhaps, draw the conclusion that  means there is an empty free text field here, but since we don't make use of that information, I'm not sure what to say other than keep it in the back of your head if you ever want it, just as you would when parsing the HTML version.

I was checking the description parsing for text/html emails and I realized that it might not be working properly.

You're absolutely right. Thanks for catching that too! If you can get that fixed too, then we can merge?

Sure, working on that fix.

@mlissner Done! fixed description parsing in text/html emails, and updated JSON of test cases where the description was incomplete.

Looks great to me. Let's chat with Bill about getting this deployed once he's back from being sick.


Basic Shape: Cylinder

Implement a spec, sim object and handle for a Cylinder basic shape. Look at the SimBall and SimBox objects for reference

Fixed in https://github.com/FRUK-Simulator/SimulatorCore/pull/55


turn of height restriction with scrolling by default

I turned Prism on for my code samples and it looks gorgeous!
But a longer code section suddenly got its height restricted with scrollbars added with the coy skin. I didn't ask for this! I don't want scrollbars.
The reason this is a blocker issue is that I need to convert this documentation to a PDF. Scrollbars in a PDF won't help my students, and they will be missing code.
At the very least, there should be CSS that indicates the restricted height with scrollbars is only for screen media, not for print media!!

The offending code is a max-height set for <pre>. I don't know if it is part of Prism or part of the coy skin.
Here is the workaround for CSS after Prism is included:
pre {
  max-height: none !important; /*workaround for Prism scrollbars*/
}

I don't know if it is part of Prism or part of the coy skin.

I think it is only part of the coy theme and I agree that such a restriction should not be determined in the theme but left to the end user. Changing it now would probably break a lot of websites which expect this behavior.

Do it the right way: turn it off for print. Nobody could every want it for print, because you lose information. Leave it on temporarily for backwards-compatibility on web sites.
As for long-term, deprecate this behavior. Create a checkbox on the download page that you have to check to get the restricted height. Indicate that you will eventually remove it.
I shouldn't have to add workarounds in my clean code just to get things to work the right way.

As for long-term, deprecate this behavior. Create a checkbox on the download page that you have to check to get the restricted height. Indicate that you will eventually remove it.

I don't think there is any need for that. I think we can remove it immediately for the next release. If people want the old behavior, they can use an earlier version.

Yay!! Thank you. Sorry, I guess I had misunderstood you earlier, thinking you were going to always leave it in.

@LeaVerou maybe you would like to comment on this? Otherwise I would remove the max-height: 30em attribute from the coy theme.

I would put it inside @media screen. @garretwilson is right that nobody would want this for print.

I would put it inside @media screen {...}.

Done.

Is this available from the website now? I just want to know when to test it. Thanks.

P.S. I also recommend documenting somewhere how a user can change this or disable it altogether, so people don't have to go hunting around in a debugger. Just a thought. Thanks!

Is this available from the website now?

Yes. It is also in the gh-pages branch in this repo.

P.S. I also recommend documenting somewhere how a user can change this or disable it altogether, so people don't have to go hunting around in a debugger. Just a thought. Thanks!

I would be in favor of removing it altogether. It is inconsistent with the other themes.

OK, the latest version from the site is printing without vertical scrollbars now. Thanks for addressing this so quickly!
I still get horizontal scrollbars for things I have made too wide, but I'm not sure what my opinion is on that. I suppose I just need to fix the content.

I would be in favor of removing it altogether. It is inconsistent with the other themes.

Fine with me!

I would be in favor of removing it altogether. It is inconsistent with the other themes.

The problem with having this in by default is that there's no way to even guess what a "default" value might be for a majority of users. Best to leave it out altogether and make a note about what a user would need to do to restrict the height---although that should be pretty much self-explanatory, anyway.

I would be in favor of removing it altogether. It is inconsistent with the other themes.

Yeah, I think that's the best option. Even after removing it from the print version, it still gives me trouble on a web page because I'm using it as a document in a screen-sharing session to give a class, and being forced to scroll two things (the larger document and then the code snippet) is a hassle. I'm going to go back to permanently removing it in my stylesheet, and I would recommend you get rid of it altogether too.

If we remove it, the theme breaks (the shadows are the wrong size). No time to debug why right now, but I suspect it has a lot to do with how hacky these shadows are. They've been giving us trouble with other things too (they break the line highlight plugin for example) but damn, they look nice :P

That's odd, because I didn't notice a difference when I took the size restriction off (see workaround above).
Frankly the shadows aren't that great for me anyway. They look odd, as if the page is curled up. And when printing to a PDF from Chrome they look odd. And sometimes the shadow will show up half on one page and half on another. I'd be happy without the shadows in coy.
Coy is a pretty theme. No use trying to make it do too much. I'd be happy without the shadows.

I wouldn't be happy without the shadows and neither would many people who use it.
That said, putting them inside @media screen would be good to prevent them from showing up in print.

I wouldn't be happy without the shadows and neither would many people who use it.

I think I have fixed the shadow bug with #865.

I wouldn't be happy without the shadows and neither would many people who use it.

That's fine, I can see how many people love it. It looks pretty on the screen (although it's a bit odd that I get it on both sides). Just let me know how to turn it off for print. Thanks.

We should put the shadows inside @media screen so they only show up on the screen.

We should put the shadows inside @media screen so they only show up on the screen.

Do you plan on doing that soon? I don't want to rush you, but if it's going to take a while, do you know an easy way for me to turn them off from my own CSS? They are really starting to get in the way in my resulting PDFs. Thanks.

do you know an easy way for me to turn them off from my own CSS?

So nobody knows how I can just turn off the shadows manually from my own CSS?


ps3eye_sdl.exe closes immediately in step 4

I followed all the directions outlined in the wiki, however ps3eye_sdl.exe will not run, it simply closes immediately after opening.  I've been through the previous steps many times to make sure everything is correct and it is.  I did the 3 steps in the troubleshooting guide and did various other steps to try and get this working, such as reset the computer, switch USB ports multiple times, uninstalled reinstalled via USBDeviceView.  Really hoping for some help here.  Thanks so much for writing this all up and any help you can offer.  I am on Windows 10 btw
-Make sure Unity is shut down
-Make sure there are no other apps trying to connect to the camera
-If the red light next to the camera is still on, unplug and re-plug in the PS3Eye and then try running the apps again.
EDIT: Got it working!  The last set of USB ports on my PC worked for whatever reason...  But having another issue with the camera config files not existing.

I was able to get through step 5 just fine btw, until I got to test_tracker.exe obviously which didn't show either.

Got it working by using the last set of USB ports on my machine...  Dunno what makes them so different but it worked.
I am now having issues with the video jumping around while running test_tracking.exe however.  And I don't have the registry keys or files:
HKEY_CURRENT_USER\Software\PS3EyeCamera
colormapping.dat
PSEye_backup.ini
PSEye_backup_win.ini
Why wouldn't these be built?

Sorry for my slow reply. Was out of town most of this weekend.
Those files (and registry key) will only be generated when using a version of the psmoveapi library with the CLEye driver (via the CAMERA_CONTROL_USE_CL_DRIVER option), see here. I believe I didn't compile the version of psmoveapi used by psmove-unity5 in the master branch with that flag.
The camera issues tend to manifest on usb ports where there is a bunch of other USB traffic on the same usb root hub i.e. another camera (like the Oculus tracking camera). On the back of your computer pairs of usb ports are generally connected to the same hub. So you want to avoid putting a ps3 eye camera adjacent another camera like so:

All that said, it turns out there were some inefficiencies in how the ps3eye camera driver worked that causes it to be more sensitive to other traffic than it should be. There is a large discussion about that here. At the end of that discussion there is a potential camera driver fix I'm going to try out tonight. I'll update this issue with the results.

Thank you for the reply,  After reading some of your other replies regarding this problem I tried every combination of USB ports I could, disconnecting all other devices and putting keyboard and mouse in a completely seperate bank. etc..  Nothing helped.  There are only 2 USB ports where the device even works as described in your wiki.  I purchased this PCIe USB expansion card hoping to fix the issue:
http://www.amazon.com/gp/product/B00FPIMJEW?psc=1&redirect=true&ref_=od_aui_detailpages00
That is arriving Thursday and I will let you know the results, but of course any progress you make on the driver front would be very welcome!
If there is anything else I can do to help you get to the bottom of these issues please let me know  =)  Once I get this working decently it will be extremely helpful!

Thanks for linking that PCIe USB expansion port. I actually needed to order one of those myself but couldn't remember what one to people recommended. I think we're close on the driver. I was having similar variable framerate issues here in the ps3eye test app on my PC trying to run at 60fps, getting between 28 and 36MB/sec from the camera:

Then after removing a sleep statement in the SDL example's frame polling loop I got a stable 36 MB/s:

Hopefully I can get the same performance when using the psmoveapi in Unity.

Sounds like good news, I look forward to your next updates!  Great work, keep it up.

I just got rovarma's libusb.ps3eye improvements incorporated into psmove-unity5. When you get a chance would you mind pulling down the following branch:
https://github.com/brendanwalker/psmove-unity5/tree/new_ps3driver
Here is a video of it in action in Unity for me:
https://youtu.be/qI_lyUydsbc
And here is a video of the new version of ps3eye running at an (almost) solid 60fps:
https://youtu.be/2cVb4bHNKuQ
If this works for you I'll merge this back up into master

Thank you I will give it a try tonight!

I am having problems getting it to work at all now.  Below is a screenshot of my USBDeviceView and the error I am getting when I try and run PS3eye_SDL.exe

Hmm. There shouldn't have been any other setup, the new build should have just worked. I just cloned https://github.com/brendanwalker/psmove-unity5/tree/new_ps3driver to my Win8.1 work machine and it ran ok. When I get home I can test it on my Win10 machine. In the mean time, some questions for you:

Do you get the same problem when you run the old version of ps3eye_sdl in https://github.com/brendanwalker/psmove-unity5/tree/master?
Are you running this using an admin account or a non-admin account. Many of the tools have issues opening USB devices when not run on an admin account.
Does the test_tracker.exe app also crash on startup or does run ok?

1- When I run the old version of ps3eye_sdl it simply closes immediately after I start it without any error message, it doesn't give me any error.
2- Yes I am using an admin account, doing run as administrator also.
3- The test_tracker.exe app closes immediately after opening it also in both the master and this branch.
Just a couple more things that may help..
-If I uninstall the device and then run the ps3eye_sdk.exe without first switching the camera (Interface 0) driver to the libusb-win32 driver it actually runs,  On the old version I get 180fps and it's jumpy, on the new it's like 20fps and insanely choppy.  Not sure what this means, if anything??
-When I was first following your directions I think I switched the camera (interface 1) to libusb-win32 instead of (Interface 0), not sure if this would matter..  But in your screenshot I see your camera interface 1 service names are usbaudio, in mine it is WinUSB.
Thanks so much for all this!!!

IT'S WORKING!  Not exactly sure what I did, I just went through task manager, uninstalled all USB drivers I could find besides the keyboard and mouse, uninstalled all USB audio devices, DK2, etc.. etc.. etc.. and checked the "delete driver software" box.  Restarted the computer, plugged it in the new USB card, then everything worked as expected.
FYI ALL - the test_tracker program will close immediately if the pS move controllers are not on.  I think that is why when I had the wrong drivers installed above, the ps3eye_sdl sorta worked and test tracker didn't... just a quick note on that since it scared me for a moment that it didn't work after the ps3eye_sdl worked so well.
It seems to be working near perfectly now.  Thanks again for all your help.

Sweet! Thanks for the update. In Win10 I have occasionally been bitten by stale USB drivers on the camera. Completely removing the USB drivers and starting from a clean slate usually does the trick.
And yeah I could have a more friendly warning when the controller is turned off. This will get better once we get the new PSMoveService working, but that's still at least a month out.
There are still a few small tweaks I'm working with rovarma on the ps3eye_sdl app, but once we have those settled I'll migrate these fixes back up to master. Once that is done I'll close this issue.


Cookie bar pops up every time

What is the problem?
I cannot get rid of the cookie preference snackbar at the bottom of the page. It always pops back up after a page change, no matter what I choose in terms of accepting cookies.
Reproduction Steps
I am using chrome on Windows 10 with my ad blocker turned off. I visit https://cdkworkshop.com/ and I see the cookies preference snackbar at the bottom of the page.
I either accept some or all of the cookies (could not notice a difference) and hit "Save preferences" (or Accept all, again, makes no difference in what follows).
I reload the page, or simply navigate to another page within the workshop.
I see the cookie snackbar again. I can do this multiple times without a different outcome.
Verbose Log
No response
CDK CLI Version
No response
Section
No response
Browser
No response
Language
No response
Other information
No response

Hmm, I can confirm this. Thank you for reporting! Since it isnt functionally breaking the workshop, its a slightly lower priority, but it will certainly be addressed

I just duplicated this bug report by mistake. It is breaking the workshop, it covers half the screen and makes it unusable

Please fix this. The site is unusable as it is....

Is there any update on this?

Thanks for posting this @ghost23,
I know you posted this first, but I'm going to close this in favor of #427. Please take any discussion there 🙂


DOM-62795 Capture debug logs after and before failed iteration

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting)
[ ] Refactoring (no functional changes)
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior?
In cucu debug logs, we are not capturing the before and after action logs for the tenacity retry calls.
Issue Number: https://dominodatalab.atlassian.net/browse/
What is the new behavior?
Start capturing these logs to help us debug issues seen during retry steps.
Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information
Example log output with changes for one wait step:
     Then I wait up to "{ENVIRONMENT_REVISION_BUILD_TIMEOUT_S}" seconds for the environment revision in "1st" row to have status "Build Succeeded" on the environments page
2024-10-22 16:19:29,749 DEBUG Starting call to 'cucu.utils.retry.<locals>.new_decorator', this is the 1st time calling it.
2024-10-22 16:19:29,771 DEBUG Finished call to 'cucu.utils.retry.<locals>.new_decorator' after 0.022(s), this was the 1st time calling it.
2024-10-22 16:19:29,771 DEBUG Retrying cucu.utils.retry.<locals>.new_decorator in 0.5 seconds as it raised RuntimeError: Expected environment revision in row 1 from top to have status "Build Succeeded", but it had status "Build Building"..
2024-10-22 16:19:30,276 DEBUG Starting call to 'cucu.utils.retry.<locals>.new_decorator', this is the 2nd time calling it.
2024-10-22 16:19:30,296 DEBUG Finished call to 'cucu.utils.retry.<locals>.new_decorator' after 0.547(s), this was the 2nd time calling it.
2024-10-22 16:19:30,296 DEBUG Retrying cucu.utils.retry.<locals>.new_decorator in 0.5 seconds as it raised RuntimeError: Expected environment revision in row 1 from top to have status "Build Succeeded", but it had status "Build Building"..
2024-10-22 16:19:30,801 DEBUG Starting call to 'cucu.utils.retry.<locals>.new_decorator', this is the 3rd time calling it.
2024-10-22 16:19:30,822 DEBUG Finished call to 'cucu.utils.retry.<locals>.new_decorator' after 1.073(s), this was the 3rd time calling it.
2024-10-22 16:19:30,822 DEBUG Retrying cucu.utils.retry.<locals>.new_decorator in 0.5 seconds as it raised RuntimeError: Expected environment revision in row 1 from top to have status "Build Succeeded", but it had status "Build Building"..
2024-10-22 16:19:31,326 DEBUG Starting call to 'cucu.utils.retry.<locals>.new_decorator', this is the 4th time calling it.
2024-10-22 16:19:31,345 DEBUG Finished call to 'cucu.utils.retry.<locals>.new_decorator' after 1.596(s), this was the 4th time calling it.
2024-10-22 16:19:31,345 DEBUG Retrying cucu.utils.retry.<locals>.new_decorator in 0.5 seconds as it raised RuntimeError: Expected environment revision in row 1 from top to have status "Build Succeeded", but it had status "Build Building"..
2024-10-22 16:19:31,847 DEBUG Starting call to 'cucu.utils.retry.<locals>.new_decorator', this is the 5th time calling it.
2024-10-22 16:19:31,868 DEBUG Finished call to 'cucu.utils.retry.<locals>.new_decorator' after 2.120(s), this was the 5th time calling it.
2024-10-22 16:19:31,869 DEBUG Retrying cucu.utils.retry.<locals>.new_decorator in 0.5 seconds as it raised RuntimeError: Expected environment revision in row 1 from top to have status "Build Succeeded", but it had status "Build Building"..
2024-10-22 16:19:32,373 DEBUG Starting call to 'cucu.utils.retry.<locals>.new_decorator', this is the 6th time calling it.
2024-10-22 16:19:32,392 DEBUG Finished call to 'cucu.utils.retry.<locals>.new_decorator' after 2.644(s), this was the 6th time calling it.
2024-10-22 16:19:32,393 DEBUG Retrying cucu.utils.retry.<locals>.new_decorator in 0.5 seconds as it raised RuntimeError: Expected environment revision in row 1 from top to have status "Build Succeeded", but it had status "Build Building"..
2024-10-22 16:19:32,895 DEBUG Starting call to 'cucu.utils.retry.<locals>.new_decorator', this is the 7th time calling it.
2024-10-22 16:19:32,915 DEBUG Finished call to 'cucu.utils.retry.<locals>.new_decorator' after 3.166(s), this was the 7th time calling it.
2024-10-22 16:19:32,915 DEBUG Retrying cucu.utils.retry.<locals>.new_decorator in 0.5 seconds as it raised RuntimeError: Expected environment revision in row 1 from top to have status "Build Succeeded", but it had status "Build Building"..
2024-10-22 16:19:33,418 DEBUG Starting call to 'cucu.utils.retry.<locals>.new_decorator', this is the 8th time calling it.
     Then I wait up to "{ENVIRONMENT_REVISION_BUILD_TIMEOUT_S}" seconds for the environment revision in "1st" row to have status "Build Succeeded" on the environments page                                                                            # started at 2024-10-22T16:19:29.748 took 3.689s
     # ENVIRONMENT_REVISION_BUILD_TIMEOUT_S="600"

@ddl-cfuerst might want to make fix and make lint just in case this is the build issue

Thanks @ddl-cedricyoung for the lint callout. All fixed now. One of the issues was in a file I didn't even touch 😛

The failing build test is very flaky. I see the time the step took was barely over 13s many times, and I see people have had to re-run these tests multiple times in the past to get a green build. I bumped the expected step time to 14s which should alleviate the issue, but is 13 a hard requirement or was just decided on via experimentation?
https://github.com/dominodatalab/cucu/blob/main/features/cli/report_basics.feature#L205

Looks like it was last changed here https://github.com/dominodatalab/cucu/pull/382
And then it was just based on the time it took back then, so bumping this by 1s should be OK.


added loj-1235 solution

Thanks for your contribution Reshad. The previous day were very hard for me. I am sorry for not being able to merge this earlier.
Looking forward to your next contribution.


Ability to supply a special reformatting filter for 'source:'.. entries - '|pretty'

Example - You are watching the contents of a <select> list from a source:http://foobar website
You add |pretty to your CSS or xPath filter (maybe this should not be available for xpath)
and then you add a extract filter to just extract one line, but the whole list appears as one line of text
URL | https://foobar.com/page.html
FILTER | #id-of-selectbox|pretty
EXTRACT FILTER | /.+W36.L34.*/i
then, the whole select/option list is nicely formatted and I can extract the text of that one <option> value
for example
<select aria-label="Please select a Größe" class="x-msku__select-box" id="x-msku__select-box-1001" selectboxid="1001" selectboxlabel="Größe"><option value="-1">- Select -</option><option disabled="disabled" id="x-msku__option-box-1" value="1"> W30/L30   (Out of stock)</option>

becomes
<select aria-label="Please select a Größe" class="x-msku__select-box" id="x-msku__select-box-1001" selectboxid="1001" selectboxlabel="Größe">
 <option value="-1">
  Select
 </option>
 <option disabled="disabled" id="x-msku__option-box-1" value="1">
  W30/L30   (Out of stock)
 </option>
</select>

pipe | is used by both CSS and xPath, need a different filter char
li[data-years|="1900"]


Code out-of-date relative to hmac-drbg crate?

Hello!
I work on https://github.com/RustCrypto. I was interested in sending a PR to bump the versions of various RustCrypto dependencies this crate uses, but it seems this repo is out-of-date as compared to the https://crates.io/crates/hmac-drbg crate?
Is this the correct repo for the hmac-drbg crate? If so, it seems the changes made in v0.2.0 and v0.3.0 are missing from this repo.

Hi @tarcieri
The author continued the work at https://github.com/sorpaas/rust-hmac-drbg.
Thank you for bringing it up, it seems that I'll need to archive the project and update the links


Verification of Enum fails

Consider this arrangement:
    enum AnEnum{
        One = 1,
        Two,
        Three
    }

    class AClass {
        property1: string;
        property2: number;
        property3: AnEnum

        amethod(){}
    }

    class CUT{

        do(instance:AClass){

        }
    }

Now we write two tests:
    it('matches without enum', () => {
        const mock = TypeMoq.Mock.ofType(CUT, TypeMoq.MockBehavior.Strict);

        mock.setup(f => f.do(TypeMoq.It.isObjectWith({property1: 'one', property2: 1} as AClass)))
            .verifiable();
        mock.setup(f => f.do(TypeMoq.It.isObjectWith({property1: 'two', property2: 2} as AClass)))
            .verifiable();

        const call1 = new AClass();
        call1.property1 = 'one';
        call1.property2 = 1;
        call1.property3 = AnEnum.One;

        const call2 = new AClass();
        call2.property1 = 'two';
        call2.property2 = 2;
        call1.property3 = AnEnum.Two;

        mock.object.do(call1);
        mock.object.do(call2);

        mock.verifyAll();
    });

    it('does not match with enum', () => {
        const mock = TypeMoq.Mock.ofType(CUT, TypeMoq.MockBehavior.Strict);

        mock.setup(f => f.do(TypeMoq.It.isObjectWith({property1: 'one', property2: 1, property3: AnEnum.One} as AClass)))
            .verifiable();
        mock.setup(f => f.do(TypeMoq.It.isObjectWith({property1: 'two', property2: 2, property3: AnEnum.Two} as AClass)))
            .verifiable();

        const call1 = new AClass();
        call1.property1 = 'one';
        call1.property2 = 1;
        call1.property3 = AnEnum.One;

        const call2 = new AClass();
        call2.property1 = 'two';
        call2.property2 = 2;
        call1.property3 = AnEnum.Two;

        mock.object.do(call1);
        mock.object.do(call2);

        mock.verifyAll(); //THIS FAILS!!
    });

The later test fails. The only difference is the verification of the call that includes an enum value.
Any workaround?

Strangely enough, when you inline the call, the test passes:
    it('with enum', () => {
        const mock = TypeMoq.Mock.ofType(CUT, TypeMoq.MockBehavior.Strict);

        mock.setup(f => f.do(TypeMoq.It.isObjectWith({property1: 'one', property2: 1, property3: AnEnum.One} as AClass)))
            .verifiable();
        mock.setup(f => f.do(TypeMoq.It.isObjectWith({property1: 'two', property2: 2, property3: AnEnum.Two} as AClass)))
            .verifiable();

        mock.object.do({property1: 'one', property2: 1, property3: AnEnum.One} as AClass);
        mock.object.do({property1: 'two', property2: 2, property3: AnEnum.Two} as AClass);

        mock.verifyAll();
    });

So not sure what is going on in here, but certainly a bug somewhere?

It seems there is a typo in your tests. Instead of
const call2 = new AClass();
call2.property1 = 'two';
call2.property2 = 2;
call1.property3 = AnEnum.Two;

I guess you wanted to write
const call2 = new AClass();
call2.property1 = 'two';
call2.property2 = 2;
call2.property3 = AnEnum.Two;

Oh boy! stoopid me. Thanks for pointing that typo out.
I guess this isn't a good repro test of what I am seeing. I'm pulling my hair out.
Let me investigate further, I'll close this for now.


Time for a new release?

It's been a little over two months since the last release (and it's probably good to avoid large gaps between releases), see https://github.com/mozilla/pdf.js/releases, hence it might be a good idea to create a new one?
Given that there's a couple of larger changes incoming, such as e.g. text-layer/selection improvements and structure tree support for accessibility, it might be a good idea to create a new release before those land. (Since all larger features, no matter how well tested they are, often require some follow-ups.)

It would be really great to release text-layer changes. I am waiting for it some time now and am happy to test it in our production application. :)
Btw. is there any chance to create nightly releases?

It would be really great to release text-layer changes.

In https://github.com/mozilla/pdf.js/issues/13174#issue-849488894 I'm specifically recommending to create a new release before those changes land, since otherwise the next release will likely be delayed a fair bit (since we need to watch for regressions after larger changes).

Oh sorry, my mistake. I didn't read carefully. Anyway, a question about night releases is still relevant.

Anyway, a question about night releases is still relevant.

Unfortunately I don't really understand exactly what you mean by "night releases", however I'm not sure that it's relevant for this issue (which is solely about creating a new release); however the following might be helpful https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#what-is-the-latest-stable-version-of-pdfjs

Doing a new release also sounds good to me. There have been enough changes in the meantime, and it will provide us with some time for the next changes coming up. I'll take care of this release today.

@timvandermeij Thank you for doing this!

@brendandahl It seems that the latest tag still doesn't update correctly on npm, can you please fix that?

@brendandahl The latest tag on NPM should now be version 2.7.570.


Fix typo

Just a couple of typos in the README that might confuse readers. :)

Thank you for contributing.


pull atlas sampler into unstable

Some of the merges are extremely awkward. It will be easier to manually put the atlas sampler stuff in the unstable branch.


Support for custom Service Provider

Hi!
First of all, thank you for the great framework!
I'm trying to find out if there is any possibility to use a custom ServiceProvider. As far as I see, there is none. However, since my projects are based on Autofac modules, I'd like to have such functionality to avoid registering components twice.
The idea is to have a custom ServiceProvider which will first look for mock in Dictionary as it's implemented now and if no suitable implementation found, will look in Autofac container for a ordinary implementation. In this way, I'd need to manually register only services which I need to mock in a particular test.
Thanks.

It's not currently possible. The TestServiceProvider implementation simply looks for requested services in its own internal dictionary.
It sounds like you're proposing a fallback service resolution strategy. I don't think that will work well in all scenarios, and could lead to subtle issues. Take the following example (and assume the service components are singletons):

You'd have to ensure that any service in your Autofac container does not depend on a service that is being mocked by the TestServiceProvider. Otherwise, the grain under test would effectively resolve two different instances of a singleton type (in this example).
What shortcomings are you finding with the TestServiceProvider that Autofac helps solve?

Hello @seniorquico ,

It sounds like you're proposing a fallback service resolution strategy. I don't think that will work well in all scenarios, and could lead to subtle issues.
Fair enough.

What shortcomings are you finding with the TestServiceProvider that Autofac helps solve?
It's not about Autofac is somehow better than TestServiceProvider. My concern is about not making the same work twice and not duplicating a registration logic.
In my project every assembly exports an Autofac module which is responsible for registration all dependencies exported from that assembly. Any module may register other modules. Wherein an application module is a root module, which pushes a resulting hierarchy to IoC container.
Using this approach all I need to test my application (or any assembly) is to load a particular module to IoC container and let the test environment use this container to resolve dependencies. Replacing as necessary particular services with mocks. Another advantage is that when any service, for instance, requires a new dependency, only containing module has to be changed (not other modules or tests). When as with TestServiceProvider I need either somehow copy final Autofac container to it, or repeat all registration logic in tests which is very undesirable.

Taking into account your fair remark, if I was able to completely replace the TestServiceProvider with Autofac implementation of IServiceProvider (without any fallback resolution strategy), previously substituting required services with mocks in Autofac container, it could solve the problem.

I don't see any hard dependency on the TestServiceProvider. It sounds acceptable to open it up to allow registering a custom "conforming container" implementation.

Great. Let me create a pull request soon.


Add Auth0 google authentication

User should be able to see content only after authentication through https://auth0.com

Duplicate of #3

Duplicate of #3


Log level makes difference

Im trying to run SampleServer with multiple characterisyics with the same UUID. I have 2 characteristics, each characteristic has 3 different descriptors. More or less it works until i switch log level. With log level verbose works, with log level debug or lower it crash on first ESP_GATTS_ADD_CHAR_EVT event with error in getService()->getHandle().

Would you happen to have a small sample that illustrates the problem.  I believe you have supplied enough information for someone else to code it up ... but it sounds like you may have a test app to hand?

Just wanted to post example with code to recreate this issue but seems its fixed already.


Update python-package.yml

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@dependabot unignore numpy


Executing selected query in Graphql-playground.

Firstly, thank for the awesome IDE.
But one thing that I'm finding is executing the selected query in Graphql-playground ?
Let's say in one tab, we have a lot of queries. Each time I execute a query, I have to comment on other queries to make sure the IDE can run.

It would be great if we can execute the query that we have selected. Something like MS SQL Server. Is this possible?

You can do this by naming query and then selecting that query:

@Huvik Thank you

Hello guys,
I want to know if we are running multiple queries in playground, Is there any way to find out number of graphql queries and which queries are there in queue inside our java backend app? Please answer this if anybody knows, thank you.


guard against illegal positions

Istanbul can sometimes return illegal position values. Clamp them so they can be used by the source map consumer.
See https://github.com/bcoe/nyc/pull/143#issuecomment-173554681 for background.

@novemberborn nice elegant patch :+1:
@albertogasparin would you be able to give this branch a try, and see if it solves your problems?


HomeKit (Siri) doesn't seem to see anything anymore

I've developed the WEIRDEST problem. Suddenly out of no where, Siri can't identify ANY of my accessories.
I didn't really change anything, the Home HomeKit app can add and control all my devices just fine, but Siri refuses to understand anything.
If I ask for a device by name to be turned on/off, it doesn't understand. If I ask for a whole room to be turned off, it doesn't understand.
So it's like it sees my devices, but can't figure out how to control them appropriately.
I've done everything down to resetting all my HomeKit settings. Has anyone else seen anything like this before?

@maddox What's the Siri's response when you ask "Turn on the lights" and what's the iOS release you're using?

what's the iOS release you're using
I'm on 9.0 (Haven't updated my 6s yet :grin:).

What's the Siri's response when you ask "Turn on the lights"

I already wiped my accessories.
Good news though. After doing another wipe, I couldn't add a Home anymore. It kept telling me "cloud sync is in progress". Even a reboot didn't fix this.  And siri is responding correctly now.
So...¯_(ツ)_/¯

That's strange... I guess there are something wrong with HomeKit which cause Siri failed to sync all the home information with its server.

It could turn EVERYTHING on/off when I asked though.

Does it really asks that? With me, it always turns all lights on/off if it doesn't understand the room name. Which has a very low WAF I can tell.

@snowdd1 I believe that's a new Siri feature in iOS 9, when Siri is not confident enough about your command, it will ask like this.

Never had that. Always got a "your lamps are turned off" and sudden darkness in the house :(

@snowdd1 yeah, Siri should never ever try to turn off everything without asking...

This month? October?

September. (3 days ago)


Create a gRPC client in .Net Framework 4.6 or higher to connect to a micreoservice that has a gRPC server in .NET Core 6 or higher.

Create a gRPC client in .Net Framework 4.6 or higher

I have been looking for some documentation that explains how to make a gRPC client in an application made in .Net 4.7, we plan to migrate it to microservices, but while we do the migration, we need to communicate the microservices that we are developing with the application.
https://learn.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-7.0&tabs=visual-studio

We have been working on a hybrid RESTful and gRPC microservice using .Net Core 6 that services
to the front end and the application in .Net Framework 4.7.

I have tried to look for an example that makes a gRPC connection between a client and a server, but all I have found are examples that use the same library where there is an interface to the service.

https://github.com/grpc/grpc-dotnet/tree/master/examples/Frameworker

Other pages only say how to configure the channel.

https://stackoverflow.com/questions/58125102/grpc-net-client-fails-to-connect-to-server-with-ssl/66041094#66041094
https://learn.microsoft.com/en-us/aspnet/core/grpc/netstandard?view=aspnetcore-5.0

I have tried to make a bridge library in .Net Standard 2.0 but I think I am doing something wrong. For this reason, I am asking for a guide or an example.

Thank you very much in advance.

@JamesNK,
I could use your take on this for priority and would need some of your time for guidance.  Thanks.


Rationale for PhysFS use?

I'm interested in developing a preliminary DirectX11 renderer for your engine intending to use it with OPHD and like that you are using modern C++. I was wondering what your rationale for using PhysFS is?
I just tried to directly use the source code of PhysFS (3.0.2) in one of my own projects so as to not create an external dependency and it does not compile cleanly on a W4 level with warnings as errors in both VS2019 and VS2017 x64 build (There are hundreds). I spent an hour just getting rid of all the warnings (with pragma warning disable directives) and the few casts needed for type size and signed/unsigned mismatches. Not to mention there are unused variables all over the place and redefinition errors in a few places. It is decidedly not a C++-minded library and is poorly written.

Hi cugone, welcome.
You are right that PhysFS is not really a C++ library. Most of it's source code is plain C, and the API interface is plain C. That can make it's use from C++ seem like a bit of an archaic style.

In terms of compiling and errors, I can't say too much about the Windows side or MSVC, but I can speak a little about the Linux side.
We are using the native PhysFS build scripts packaged with the library, and so I'm not seeing any errors or warnings compiling.
As a check though, I tried running the PhysFS sources manually though the compiler with the -fsyntax-only option to check the source for errors. The following produce no warnings or errors:
# Both C and C++ sources
gcc -fsyntax-only *.c *.cpp
clang -fsyntax-only *.c *.cpp

# C++ sources only
g++ -fsyntax-only *.cpp
clang++ -fsyntax-only *.cpp

If however I try to process the .c files as C++, that does produce warnings and errors:
# C sources as C++
g++ -fsyntax-only *.c
clang++ -fsyntax-only *.c

As the PhysFS project is predominantly C (not C++), perhaps the errors you are seeing come from processing the C source code as C++? I don't know how well MSVC handles straight C code, if it detects based on file extension, or if it needs any special flags set. On the Linux side, I'm aware of the base compiler names (gcc, clang) setting the language based on file extension. Explicitly using a language specific name (g++, clang++) disables that auto detection.
Additionally, if header files are processed directly by the compiler as source files (rather than being included by them), that can also lead to errors and warnings:
gcc -fsyntax-only *.h
clang -fsyntax-only *.h

In particular, I'm seeing a lot of errors involving size_t and the basic type typedefs (PHYSFS_uint32, etc.).
Maybe also check that header files are added as header files, and not as "source files". If you try to add a header file as a source file, I think MSVC will try to compile it directly, which it shouldn't be doing.

In terms of dependency management, I'd highly recommend using a package system whenever possible. This is often the easiest approach. We've had some good experiences with NuGet packages, though sometimes the packages are a bit old. If you need newer packages, I'd recommend a small script for your project that downloads all dependent source packages and runs them through their compile and install steps. Only as a last resort would I include the source directly in my own repository. Though yes, I recognize that is the easy way to get started, especially if you haven't mucked around with build systems. Build systems can be hard.

Finally, there has actually been some informal discussion about possibly handling the file access without PhysFS. There are no immediate plans to swap it out though, and we haven't committed one way or the other. For now we're sticking with maintenance to keep a working system, and slow iterative improvements.

Thanks for the write-up.
Do you use PhysFS strictly for controlling access above the working directory the executable is in? If so, this is an easy fix and does not need the use of PhysFS...at least in Windows.
I avoid build systems for ease of transferability, custom source changes (Dear Imgui is a good example), and I stay up-to-date on Modern C++ while tools tend not to (all new code must be written with the most recent stable version of the language: Brand new code: c++17, if a tool doesn't support it, don't use the tool.)
I forgot to mention I have the language set to c++17 so most of the warnings were "if expression is constant, consider using if constexpr".
MSVC by default compiles as C or C++ based on the file extension. You can force it to compile as C or C++ by either changing the file properties directly (not scalable) or "including" the .c file inside a .cpp file and compiling that. This also allows you to disable warnings en-masse via push and pop.

The intention to use PhysicsFS was to provide transparent/seamless archive 'streaming', kind of like what Quake2 and Quake3 do. As a side note, it was a historical choice from when NAS2D was still in its infancy circa 2008/2009.
In the long run the plan is to remove PhysFS as a dependency and instead take advantage of C++11 - C++17 filesystem functions and objects instead. PhysFS served its purpose but for NAS2D based applications I don't see a need to have support for Doom WAD, Quake 2 PAK, Descent HOG etc. etc. archives. ZIP archives are enough and are generally trivial to implement.

@ldicker83 That's commendable, but I foresee issues trying to use std::filesystem if you move away from C++17 and the only reason is "because TravisCI doesn't support it." as the std::filesystem only just moved out of the experimental namespace in October. In this case it will be way less of a hassle to just scrap PhysFS now.
Looking over the Filesystem code, it is trivial to implement all the functions as delegate calls to std::filesystem functions and std::filesystem::path objects. It will also make all of the code immediately cross-platform.

Most of the NAS2D::Filesystem code is pretty trivial, it effectively wraps the most basic FS operations and PhysicsFS calls within a C++ class. I don't expect it to be much effort to convert it to std::filesystem. The problem is that std::filesystem is not yet supported by default on macOS X (this may have changed in the last few months, I haven't yet checked).
Long story short, it's "in the works" so to speak. I have higher priorities for now but I would like to drop the dependency (especially since it pulls in a lot of code that never actually gets executed, leads to binary bloat).

Create a PR for updating to VS17 (eventually to VS19), It builds locally just fine, but I have no experience in Linux-based build systems, so if accepted some things will need changing to get it to build on the worker VMs for AppVeyor. TravisCI is a wash because its Windows support is in its infancy as reported on their website.

Do you use PhysFS strictly for controlling access above the working directory the executable is in?
No. That is one aspect of it. Some concerns are:

Read only access to static resources alongside the exe and in subfolders
Setting a platform specific write folder (manual with <filesystem>, and different for each system)
Restricting writes to a given subtree (a potential security concern, which <filesystem> has no equivalent for)
Automatic mounting of archive files (need an external library for this)
Prioritized file access over a virtual filesystem (again, no real equivalent here, so manual code)

Not all are equally important, but they are all at least somewhat relevant.

In this case it will be way less of a hassle to just scrap PhysFS now.
I don't follow the argument here. I think scrapping use of PhysFS right now is actually quite the hassle. This is particularly true for non-Windows platforms.

I think we're still far away from being able to do a clean tested transition. Despite how trivial the changes may appear on the surface, they will have rippling consequences. Further, these changes are at the core of many cross platform issues, and so need testing on all platforms.
Right now we have absolutely no tests for the filesystem code. Having code that merely compiles cleanly isn't enough. It has to actually work. And we won't know that unless the code actually runs on all systems. And the details will be different on every system.

It will also make all of the code immediately cross-platform.
Except that it won't, because <filesystem> support is still lacking on some platforms and compilers. Additionally, <filesystem> doesn't encompass the same scope as PhysFS, meaning custom code which has to be built and tested from scratch.

The new <filesystem> code is wonderful. Except that's it's kind of not, because it's roll out has been dragging on for years, leaving everyone hopeful yet frustrated.

especially since it pulls in a lot of code that never actually gets executed, leads to binary bloat
I haven't tested, but from what I heard, modern linkers will cut out most of the bloat from unused code. They're supposed to be pretty good at that now. Early linkers were not.

But yes, it would be nice to have fewer dependencies.

1. Read only access to static resources alongside the exe and in subfolders

Can you give an example of intent? Do you not want users to be able to alter resources like images and text files and such? Why? If the user screws with your resources and it breaks the game, it's not your concern.

2. Setting a platform specific write folder (manual with `<filesystem>`, and different for each system)

Like Windows' AppData folder but for Mac and Linux as well?

3. Restricting writes to a given subtree (a potential security concern, which `<filesystem>` has no equivalent for)

Why? A game shouldn't care where the resources come from (save files, images, scripts, etc) just as long as they are validated before being loaded; This also cannot be prevented, all the user has to to is turn off your game and then they can do whatever they want to your file structure. The only real way to mitigate this is discipline and consistency of where game files are stored and automatically written to/read from. Manually reading/writing resources (save games) can come from anywhere. See UE4's concept of a "Content" subfolder. Nothing outside this folder is packaged as a game-specific resource and most save games are written to/read from the AppData or other "known" equivalent folder.

4. Automatic mounting of archive files (need an external library for this)

By "automatic" do you mean transparent structures that read from archives as if they are real folder structures?
If so, yes, this can't be helped, but there are specialized libraries that do just that and nothing else; zLib for example, and you can easily just drop in code that can be compiled along-side your code in a Thirdparty folder (TinyXml2, Dear Imgui, STBI) so there's no external dependency. DLLs next to the executable for said libraries is something that can't be helped (fmod, libcurl, I'm looking at you!). There's no need to pull in and download a whole library just to get your code to compile and link. Users (including down-stream games you yourself write) just need to have your top-level Engine code folder referenced properly and any .dlls and it will compile and link.

5. Prioritized file access over a virtual filesystem (again, no real equivalent here, so manual code)

I don't understand what you mean, again, could you give an example?

I don't follow the argument here. I think scrapping use of PhysFS right now is actually quite the hassle. This is particularly true for non-Windows platforms.

With this I agree. I'm just now finding out that Apple is a horrible platform to develop for and Linux is a little better. Reason being is Microsoft has active and direct participation in the C++ committees, helping shape the language. They have the most stable releases (and it's easier to tell what each release has available because it correlates with major IDE versions) with library and language updates happening at the same time; Linux doesn't update the Library changes at the same time and you have to manually link specific library changes and implementations with confusing argument names. Apple just doesn't do any of that and is off in their own world of "We'll release changes whenever, even if they are years behind anyone else." In all the CppCon, CppNow, and other C++ convention videos I've seen not one that has been a developer working in a Mac-based IDE environment (Xcode). All Linux, Clang, GCC or Visual Studio (even VS for Mac!).

I think we're still far away from being able to do a clean tested transition. Despite how trivial the changes may appear on the surface, they will have rippling consequences. Further, these changes are at the core of many cross platform issues, and so need testing on all platforms.
Right now we have absolutely no tests for the filesystem code. Having code that merely compiles cleanly isn't enough. It has to actually work. And we won't know that unless the code actually runs on all systems. And the details will be different on every system.

I think this is a separate issue. Removing unneeded dependencies on external libraries, getting every platform on the same page compile-wise is the first step, (at this stage there's a lot of do-nothing or well-defined values that are returned and documented functions, but your interfaces are complete. Then writing OS-specific implementations behind those interfaces if need be.

It will also make all of the code immediately cross-platform.

Except that it won't, because <filesystem> support is still lacking on some platforms and compilers. Additionally, <filesystem> doesn't encompass the same scope as PhysFS, meaning custom code which has to be built and tested from scratch.
The new <filesystem> code is wonderful. Except that's it's kind of not, because it's roll out has been dragging on for years, leaving everyone hopeful yet frustrated.

See my previous about Apple. 🙁

especially since it pulls in a lot of code that never actually gets executed, leads to binary bloat

I haven't tested, but from what I heard, modern linkers will cut out most of the bloat from unused code. They're supposed to be pretty good at that now. Early linkers were not.
But yes, it would be nice to have fewer dependencies.

No argument here.

All-in-all if you look at the statistics (derived from Steam hardware & software surveys) 96% of gamers are on a Windows platform, 3% are on Mac and 0.8% are on Linux. Most games on Steam are windows-only. Trying to be cross-platform up front with such low market share is just a waste of resources and time. Get it working on Windows, then dedicate time as needed porting the OS-specific implementations of your interface.

My apologies for not replying sooner. I got kind of busy last month, and this sort of fell by the wayside.

Read only access to static resources alongside the exe and in subfolders

Can you give an example of intent? Do you not want users to be able to alter resources like images and text files and such? Why? If the user screws with your resources and it breaks the game, it's not your concern.

This one is more concerned about finding the static data packaged with the executable file. The executable could potentially be installed or unpacked anywhere. The static data resources distributed with the game are likely to be located at some relative path from the executable file, typically a subfolder. This is more about finding the current executable's location, so the path to the subfolder can be found. This is not as simple as just assuming the current working directory points to the executable's folder, as that is often not the case. For example, starting an executable in the terminal using an absolute or relative path will leave the current working directory untouched. Ex:
/path/to/some/working/folder/ $ /game/path/executable
Current working directory: /path/to/some/working/folder/
Executable path: /game/path/
Possible resource path: /game/path/data/

Finding the current executable's location has different solutions for different platforms. It's also complicated by symbolic links, where the executable path might have a component pointing to another area of the filesystem. One common way of finding executable location is using argv[0].
In terms of security concerns, that's more about number 3. Though that concern doesn't really apply to the static data. The static data is of course assumed to be static. If the user edits it outside of the game, that's their problem/benefit.

Setting a platform specific write folder (manual with <filesystem>, and different for each system)

Like Windows' AppData folder but for Mac and Linux as well?

Yes, exactly. Examples from the PhysFS documentation:
Windows: "C:\\Users\\bob\\AppData\\Roaming\\My Company\\My Program Name"
Linux: "/home/bob/.local/share/My Program Name"
MacOS: "/Users/bob/Library/Application Support/My Program Name"

Restricting writes to a given subtree (a potential security concern, which <filesystem> has no equivalent for)

Why? A game shouldn't care where the resources come from (save files, images, scripts, etc) just as long as they are validated before being loaded; This also cannot be prevented, all the user has to to is turn off your game and then they can do whatever they want to your file structure. The only real way to mitigate this is discipline and consistency of where game files are stored and automatically written to/read from. Manually reading/writing resources (save games) can come from anywhere. See UE4's concept of a "Content" subfolder. Nothing outside this folder is packaged as a game-specific resource and most save games are written to/read from the AppData or other "known" equivalent folder.

Many games allow for sharing of resources during online play. For instance, automatically downloading a new map file from a game host. Normally you'd just dump this into a 3rd party map folder. Example: gameWriteFolder/downloadedMaps/mapName.map. However, if some hacker kid gets clever and decides to name his map something like ../../../../../../command.com, you may end up with a problem. This is a particular concern on single user setups where people regularly use an admin account for normal tasks. That used to be common on Windows, though thankfully security has gotten a bit better by default.
Ideally writes should be restricted to a game specific write folder, and any attempt to escape that write folder should either fail or at least be ignored. PhysFS handles this with it's virtual filesystem concept. You can mount multiple folders for reading, including static read-only game assets, but have a single write folder, typically set as in number 2 above. The game effectively can't see any of the real filesystem that hasn't been mounted into the virtual filesystem. There is no way to map a malicious map name like the above to a potentially dangerous area of the filesystem, even if the user was running as an admin.

Automatic mounting of archive files (need an external library for this)

By "automatic" do you mean transparent structures that read from archives as if they are real folder structures?
If so, yes, this can't be helped, but there are specialized libraries that do just that and nothing else; zLib for example, and you can easily just drop in code that can be compiled along-side your code in a Thirdparty folder (TinyXml2, Dear Imgui, STBI) so there's no external dependency. DLLs next to the executable for said libraries is something that can't be helped (fmod, libcurl, I'm looking at you!). There's no need to pull in and download a whole library just to get your code to compile and link. Users (including down-stream games you yourself write) just need to have your top-level Engine code folder referenced properly and any .dlls and it will compile and link.

I think you've got a pretty good handle on the challenges there. The effective proposal here, is to replace one dependency with another lower level dependency, albeit with lighter requirements and a more specific focus.
I wouldn't recommend direct source inclusion though. I think whenever possible, a package manager solution should be preferred. To avoid external DLLs, static libraries can be used. It increases the executable size, but makes things more standalone.

Prioritized file access over a virtual filesystem (again, no real equivalent here, so manual code)

I don't understand what you mean, again, could you give an example?

With PhysFS you can mount multiple folders into a common point of the virtual filesystem. That means two real filesystem paths might map to the same virtual filesystem path. This isn't a requirement per se, rather how things are done with PhysFS. It can potentially be used for mod support. If a mod folder is mounted, and has a higher priority than a core game asset folder, then the mod assets will be seen instead of the core game assets. That may be one way to allow for mods to work.
Example:
filesystem.mount("/", "data/coreAssets/");  // Contains "assetName1", and "assetName2"
filesystem.mount("/", "modName/newAssets/");  // Also contains "assetName1"
data1 = filesystem.read("assetName1");  // Core game asset or mod asset?
data2 = filesystem.read("assetName2");  // Core game asset

Here two real filesystem folders are mounted to the root of the virtual filesystem. Assuming the second mount folder has a higher priority, then any access to "assetName1" will get the mod version of it, rather than the packaged core game asset.
Note that "assetName2" is not hidden by the mod folder mount. Rather the virtual filesystem overlays the mod folder onto the filesystem image. Files with the same name in the original folders are hidden by the new assets in the mod folder. Other files which are not overlaid are still present and accessible under their usual name. This is the priority part.
Again, there are alternative ways to do this, and no requirement that we handle such things in the PhysFS way.


Data migration demo: Add ability to transform exported data before importing into the new model

Over time, it's reasonable to expect that the developer might want to change the export/import format (esp. if features are added/removed from their app).  By permitting a transform callback function in the migrator, the developer can avoid having to ensure their model knows how to import every stale format.
The callback is async to permit network calls or dynamically loading the function (since most pageloads won't need to do this, it would be a reasonable candidate to lazy-load).
The example then demos this functionality by using a different export/import format for version 1 vs. 2 -- in this case switching between using ':' vs. '\t' for delimiting the item name and quantity.
AB#1606

It's awesome to see data transformation concerns separate from the model itself :) Separating transformation & migration concerns away from model itself will certainly make the design more extensible.

Another general questions: What sort of unhappy paths scenarios we could have here. User upgraded ver1 -> ver2 and then realized that his transformation code did not do the right thing, and some of these containers are now live. What would be the next steps here.

Another general questions: What sort of unhappy paths scenarios we could have here. User upgraded ver1 -> ver2 and then realized that his transformation code did not do the right thing, and some of these containers are now live. What would be the next steps here.

I don't currently have anything to handle that, but the old container will still exist and can be accessed after the migration - it would be possible to craft a recovery flow based on reattempting the migration (hopefully with a fixed transformer if the corruption was due to some bug).  I guess it would depend partly on what the user expects to happen to the badly-migrated containers (I assume destroy them if they are in a corrupted state)?


Fix code scanning alert - Arbitrary file write during zip extraction ("Zip Slip")

Tracking issue for:

[x] https://github.com/TheoPierne/MythicalLauncher/security/code-scanning/1

Related to https://github.com/TheoPierne/MythicalLauncher/commit/38ddff05602b89698ce62c623d91bee6e8af255d

Related to https://github.com/TheoPierne/MythicalLauncher/commit/38ddff05602b89698ce62c623d91bee6e8af255d


Add a rule to enforce a newline between the metadata and code

I'm not sure if this is already possible by default in ESLint, I thought lines-around-comment might work but I'm not sure how to only enforce it for the metadata and not for regular comments. There is an ignorePattern but no includePattern.
I've outlined how I would expect it to work below.
Correct ✔
// ==UserScript==
// ...
// ==/UserScript==

console.log('Hello world');

Incorrect ❌
// ==UserScript==
// ...
// ==/UserScript==
console.log('Hello world');

EDIT: I think I've achieved it with the following in my .eslintrc:
{
  "rules": {
    "lines-around-comment": [
      "error",
      {
        "afterLineComment": true,
        "ignorePattern": "^(?:(?!==\/UserScript==).)*$"
      }
    ]
  }
}

As I understand it though, ESLint will check every single comment to see if the RegEx matches, which seems inefficient. A more specific rule/check from this plugin could be useful in this case.

Added new metadata-spacing rule


iceoryx2_cal::event::Listener::**_wait_all shall use callback with result

Brief feature description
The signature of all functions in the Listener trait in the iceoryx2_cal::event concept shall be adjusted to
fn **_wait_all<F: FnMut(TriggerId) -> Result<CallbackProgression, ListenerWaitError>(&self, callback: F) -> Result<(), ListenerWaitError>;

This allows a better usage and the ? operator inside the callback as well as the implementation. Furthermore, it allows to stop the progress when an error occurs or a certain user condition is met (thanks to CallbackProgression).
The iceoryx2::port::Listener::**wait_all API shall be adjusted as well after the same scheme.

Already implemented


WIP lists helper

@charlierudolph
I agree that Bash arrays are super hard and frustrating to use.
I think they also go against the Unix philosophy, and against the whole idea of Bash Script.
The standard exchange format between apps are newline-separated strings. Unix provides a ton of tool support out of the box for dealing with them, they are more portable to non-Bash shells, and overall much more easy to use than arrays in my opinion.
Here is an initial idea how to use lists, in the form of a helper library that makes them super convenient to use. This is just an idea at this point, I haven't tried replacing any real array code with this. Wanted to get your take on this first before I drill deeper.
If we decide to give this a try, I'm happy to dig up the old Bash unit test framework to test libraries like this properly.

@kevgo for now I don't think this is needed. Good to see working with arrays isn't too hard. Believe we already have a few of these methods here though its a bit more specialized for delimiter separated strings

@kevgo bump

Okay, closing this PR.


KAFKA-8610: Don't use /bin/bash in scripts

Currently, the interpreters (i.e., /bin/sh, /bin/bash, and #!/usr/bin/env bash) and indentations in the scripts are not unified. This PR improves portability by unifying them to use /bin/sh.
It was validated with shellcheck and manual testing, but the more comprehensive test would be welcomed.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Retest this please.

Retest this please

retest this please

Thank you for this! I was just about to issue a PR for it, but thought to check beforehand.

Thanks. But I still need other contributers' help. If you experienced any issue while running this update, don't hesitate to leave a comment here. I am eager to help! :smiley:
cc/ @hachikuji

Retest this please.

Retest this please.

Retest this please.


No install option after make

Hi,
Just notice there is no make install option for this great little galendae. How should one install this into the system correctly?

Sorry, blond moment ;)

Glad you got it sorted, I hope its useful :-)
Galendae is a simple wee program and can be kept and run from your user directory. However, maybe 'make install' should be an option.


Implemented restart button to reset the game state,  #12

Added draw condition and message when game ends in a tie
Updated CSS for restart button and winner/draw messages

Also added animation after player win.


NIFI-11369: Fixed Defragment strategy with optional fragment.count at…

…tribute in MergeContent

Summary
NIFI-11369
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[x] Apache NiFi Jira issue created

Pull Request Tracking

[x] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[x] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[x] Pull Request based on current revision of the main branch
[x] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[x] Build completed using mvn clean install -P contrib-check

[x] JDK 11
[ ] JDK 17

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[x] Documentation formatting appears as expected in rendered files

I check the fix, and it works as intended.
Now it is enough that one flow file contains the fragment.count.


feat: custom commands

closes #165

Allows to pass in addition to NPM script names any commands. For example
start-test 'http-server -c-1 --silent' 8000 'npm run test -- --verbose'

:tada: This PR is included in version 1.8.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


fix for issue 33

Fix for issue 33. https://github.com/backstage/backstage/issues/33
ALso added -v flag to go get command in make setup for transparency and easier troubleshooting.

Hi @lmunro, thank you for that!
Why did you close this PR without merging it?


Call to action styles

toward #201

@mccalluc please review
what I'm going for is more modularity of style, trying to decouple parent elements from their children as much as possible. I think this PR moves in that direction, although there's more that can be done.

Home page large screen

Home page smaller screen

Home page narrow screen

Bottom call to action, full width

Bottom call to action - medium breakpoint

Top of search results page - medium and full widths

Top of search results page - narrow width. The search bar (pulled left) and "contact us" blurb (pulled right) begin to overlap.

I copied included part of the search header from the search results page into the #show view for catalog items. It takes up a little bit of room, but I think it's worth it for the consistency.
Top of #show view - medium and full widths

Top of #show view - narrow width


feat: type hooks with ParamSpec

Follow up of #2344 that types hook with paramspec.
Will merge this after 4.0 is out

It is not decided yet whether we want to do this in 4.1, or even further down the road. But we can keep this PR open for a while.


Update Apollo Optics to Apollo Engine

I struggled with this just a little so I thought I'd update the docs to reflect what I found worked. I have personally included app.user(compress()); to the configServer options based on Apollo Engine instructions, but I'm not entirely certain it should be there, that it works and that it should be in the example. So I left it out of this document update.

Checklist:

[x] If this PR is a new feature, please reference an issue where a consensus about the design was reached (not necessary for small changes)
[x] Make sure all of the significant new logic is covered by tests
[x] If this was a change that affects the external API used in GitHunt-React, update GitHunt-React and post a link to the PR in the discussion.

➤ meteor-bot commented:
@dlredden: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

➤ James Baxley commented:
Deploy preview ready!
Built with commit c3d5461c0551b3443037ca06c6aa29c53e44910c
https://deploy-preview-2544--apollo-client-docs.netlify.com

➤ meteor-bot commented:

Messages

:book:

Please add your name and email to the AUTHORS file (optional)

  Generated by :no_entry_sign: [dangerJS](http://github.com/danger/danger-js/)

➤ codecov[bot] commented:
Codecov Report> Merging 2544(https://codecov.io/gh/apollographql/apollo-client/pull/2544?src=pr⪙=desc) into master will not change coverage.

The diff coverage is n/a.

@@           Coverage Diff           @@
1. master    #2544   +/-   ##

=======================================
Coverage   85.98%   85.98%
Files          39       39
Lines        2147     2147
Branches      500      500
Hits         1846     1846
Misses        292      292
Partials        9        9
Continue to review full report at Codecov.

Legend

Click here to learn more

Δ = absolute  (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 07079ba...c3d5461. Read the comment docs.