Improve warning for missing layout

When missing layouts, Hugo presents this output:
WARN 2019/12/18 19:42:47 found no layout file for "HTML" for "home": You should
create a template file which matches Hugo Layouts Lookup Rules for this
combination.

WARN 2019/12/18 19:42:47 found no layout file for "HTML" for "page": You should
create a template file which matches Hugo Layouts Lookup Rules for this
combination.

WARN 2019/12/18 19:42:47 found no layout file for "HTML" for "section": You
should create a template file which matches Hugo Layouts Lookup Rules for this
combination.

WARN 2019/12/18 19:42:47 found no layout file for "HTML" for "taxonomyTerm": You
should create a template file which matches Hugo Layouts Lookup Rules for this
combination.

However, this output is not quite helpful. A skilled user might find this page:
https://gohugo.io/templates/lookup-order
but a novice user might not, in which case they will have no idea how to fix the
problem. Further, even if they find the page, its not clear still how to resolve
the issue. For example if you search taxonomyTerm, it doesnt take you to a
section that lists proper paths. Youd have to know to navigate to this section:
https://gohugo.io/templates/lookup-order#examples-layout-lookup-for-taxonomy-terms-pages
I think it would be more helpful for Hugo to emit these anchored links. That way
upon error a person can navigate directly to the section of the help page to
solve the problem.
Another option would be for Hugo to simply emit what its searching for,
something like:
WARN 2019/12/18 19:42:47 found no layout file for "HTML" for "taxonomyTerm" in
these paths: [layouts/categories/category.terms.html.html
layouts/categories/terms.html.html layouts/categories/list.html.html
layouts/categories/category.terms.html layouts/categories/terms.html
layouts/categories/list.html layouts/taxonomy/category.terms.html.html
layouts/taxonomy/terms.html.html layouts/taxonomy/list.html.html
layouts/taxonomy/category.terms.html layouts/taxonomy/terms.html
layouts/taxonomy/list.html layouts/category/category.terms.html.html
layouts/category/terms.html.html layouts/category/list.html.html
layouts/category/category.terms.html layouts/category/terms.html
layouts/category/list.html layouts/_default/category.terms.html.html
layouts/_default/terms.html.html layouts/_default/list.html.html
layouts/_default/category.terms.html layouts/_default/terms.html
layouts/_default/list.html]

I get that this is verbose, so it could be hidden behind --verbose or
--debug. Currently neither flag exposes this output.

Here is a cheat sheet:
found no layout file for "HTML" for "home": layouts/_default/index.html
https://gohugo.io/templates/lookup-order#examples-layout-lookup-for-home-page

found no layout file for "HTML" for "page": layouts/_default/single.html
https://gohugo.io/templates/lookup-order#examples-layout-lookup-for-regular-pages

found no layout file for "HTML" for "section": layouts/_default/section.html
https://gohugo.io/templates/lookup-order#examples-layout-lookup-for-section-pages

found no layout file for "HTML" for "taxonomy": layouts/_default/taxonomy.html
https://gohugo.io/templates/lookup-order#examples-layout-lookup-for-taxonomy-list-pages

found no layout file for "HTML" for "taxonomyTerm": layouts/_default/terms.html
https://gohugo.io/templates/lookup-order#examples-layout-lookup-for-taxonomy-terms-pages

I like this idea - I think it's perfectly fine to be verbose when it comes to warnings or errors:

You typically won't (or rather: should not) have too many of them, so the verbosity wouldn't add up
You should look into resolving the issues one way or another: more verbose output would accelerate getting a resolution.

The idea is good, but I think the right thing is to just suggest the first path we look for each.

@bep I would consider the files I listed in the "cheat sheet" to be the canonical paths. Its going to differ depending on language and taxonomy settings, but I think its a good starting point.
Also I think they are better than using list.html, as I have found that to be ambiguous. It seems list.html can be used in different contexts. This can be useful for reducing code duplication, but I found its worth the duplicated code for clarity.

@cup I suggest that we use your "cheat sheet", but with a couple of mods:

found no layout file for "HTML" for "section": layouts/_default/list.html or layouts/_default/section.html
found no layout file for "HTML" for "home": layouts/index.html

It is very common to have the home page template on the top level.

@bep I dont like the list.html for "section" as it can be used in other
contexts. For example it can be used for Home as layouts/list.html or
layouts/_default/list.html. Buts thats my preference so its not a big deal
either way.
And I like layouts/_default/index.html for Home as it allows you to have
everything in the same folder, _default, but again thats a person preference.
Your suggestion wouldnt be my ideal, but its definitely an improvement from the
current warnings. Thanks

I too found the current output of the warnings at times frustrating: Hugo knows exactly what it is looking for, why make me guess what it wants?  I would prefer the suggestion by @cup to list the complete list of paths, at least as part of "--verbose".  If I have time in the next few days, I'll look into producing a pull request for this very thing, although I'm currently a Go beginner!

@cup keeping everything in _default makes sense, but I still think listing list.html and section.html as the two common section options makes sense. We have recently cleaned up the page tree API to make it symmetrical from top to bottom, so even if I think most people will have a dedicated home page template, having all other list pages share one list.html seems like a common enough pattern that we should tell people about it.
@zaitseff listing every options makes it too noisy, considering languages, output formats and legacy lookup variants.

Alternatively, I suggest modifying the renderForLayouts and/or findFirstTemplate functions in hugolib/site.go to print a DEBUG statement on every template lookup (successful or otherwise), with a warning when one is not found:
DEBUG 2019/12/23 09:18:00 looking for layout file for "HTML" for "taxonomyTerm" in [layouts/categories/category.terms.html.html layouts/categories/terms.html.html layouts/categories/list.html.html layouts/categories/category.terms.html layouts/categories/terms.html layouts/categories/list.html layouts/taxonomy/category.terms.html.html layouts/taxonomy/terms.html.html layouts/taxonomy/list.html.html layouts/taxonomy/category.terms.html layouts/taxonomy/terms.html layouts/taxonomy/list.html layouts/category/category.terms.html.html
layouts/category/terms.html.html layouts/category/list.html.html layouts/category/category.terms.html layouts/category/terms.html layouts/category/list.html layouts/_default/category.terms.html.html layouts/_default/terms.html.html layouts/_default/list.html.html
layouts/_default/category.terms.html layouts/_default/terms.html layouts/_default/list.html]
WARN 2019/12/23 09:18:01 found no layout file for "HTML" for "taxonomyTerm": you should create a template file which matches the Hugo Layout Lookup Rules for this combination; pass "--debug" to hugo for a list of paths being searched.

@bep I dont have a strong opinion about the specifics, my main concern is that a path, or a link to a page heading in the docs, or both would be helpful and welcome in these cases.


Add TryStreamExt::try_flatten

Closes #1730
The same as 0.1's Stream::flatten.
Refs: https://docs.rs/futures/0.1.28/futures/stream/struct.Flatten.html

r? @cramertj


Initial pass at blockwise array creation routines.

This is a start at adding blockwise high-level layers for dask array creation routines (for the moment, ones, zeros, and full), addressing part of #6791. I've patterned this after the blockwise CSV reader Layer.

[x] Tests added / passed
[x] Passes black dask / flake8 dask

Thanks for working on this @ian-r-rose! cc @rjzamora

@rjzamora I've cherry-picked your commit from #6933 -- it seems to fix the immediate issue, though there may be some downstream things to fix up.
The following snippet adding a new axis (adapted from a test) fails for what appears to be dimensionality-related reasons:
import dask.array as da

def f(x):
    return x[:, None] * np.ones((1, 7))

x = da.ones(5, chunks=2)
y = da.blockwise(
    f, "aq", x, "a", new_axes={"q": 7}, concatenate=True, dtype=x.dtype
)
y.compute()

---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-1-d61b664d7769> in <module>
      8     f, "aq", x, "a", new_axes={"q": 7}, concatenate=True, dtype=x.dtype
      9 )
---> 10 y.compute()

~/dask/dask/dask/base.py in compute(self, **kwargs)
    278         dask.base.compute
    279         """
--> 280         (result,) = compute(self, traverse=False, **kwargs)
    281         return result
    282

~/dask/dask/dask/base.py in compute(*args, **kwargs)
    560     )
    561
--> 562     dsk = collections_to_dsk(collections, optimize_graph, **kwargs)
    563     keys, postcomputes = [], []
    564     for x in collections:

~/dask/dask/dask/base.py in collections_to_dsk(collections, optimize_graph, **kwargs)
    331             dsk, keys = _extract_graph_and_keys(val)
    332             groups[opt] = (dsk, keys)
--> 333             _opt = opt(dsk, keys, **kwargs)
    334             _opt_list.append(_opt)
    335

~/dask/dask/dask/array/optimization.py in optimize(dsk, keys, fuse_keys, fast_functions, inline_functions_fast_functions, rename_fused_keys, **kwargs)
     46     dsk = optimize_blockwise(dsk, keys=keys)
     47     dsk = fuse_roots(dsk, keys=keys)
---> 48     dsk = dsk.cull(set(keys))
     49
     50     if not config.get("optimization.fuse.active"):

~/dask/dask/dask/highlevelgraph.py in cull(self, keys)
    625         """
    626
--> 627         all_ext_keys = self.get_all_external_keys()
    628         ret_layers = {}
    629         ret_key_deps = {}

~/dask/dask/dask/highlevelgraph.py in get_all_external_keys(self)
    516             self._all_external_keys = set()
    517             for layer in self.layers.values():
--> 518                 self._all_external_keys.update(layer.get_output_keys())
    519         return self._all_external_keys
    520

~/dask/dask/dask/blockwise.py in get_output_keys(self)
    284             (self.output, *p)
    285             for p in itertools.product(
--> 286                 *[range(self.dims[i]) for i in self.output_indices]
    287             )
    288         }

~/dask/dask/dask/blockwise.py in <listcomp>(.0)
    284             (self.output, *p)
    285             for p in itertools.product(
--> 286                 *[range(self.dims[i]) for i in self.output_indices]
    287             )
    288         }

KeyError: '.1'

I'm not certain that this is related to the above issue, but it might be.

I'm not certain that this is related to the above issue, but it might be.

Interesting - Not sure what is causing the problem off hand.  I'll take a look

Ah.. There was a copy-paste bug in the BlockwiseIO constructor that I just fixed in #6933 - I'm still getting an error for your example (albeit a different one).  I'm still trying to figure out if the new error is another bug of mine :)

Ah.. There was a copy-paste bug in the BlockwiseIO constructor that I just fixed in #6933 - I'm still getting an error for your example (albeit a different one). I'm still trying to figure out if the new error is another bug of mine :)

Thanks for looking into this @rjzamora

Some follow-on difficulties with fusion of BlockwiseIO subgraphs: optimize_blockwise is still losing tasks in some cases. A minimal example:
x = da.full(2, 7, chunks=(2,))
y = da.full(2, 10, chunks=(2,))
c = da.add(x,y)
c.compute(optimize_graph=False) # Succeeds
c.compute(optimize_graph=True) # Fails (the resulting graph is empty)

Any thoughts as to what might be happening @rjzamora?

Any thoughts as to what might be happening @rjzamora?

Hmmm - I will look into this.  It may be that this is the first case where we are trying to fuse two BlockwiseIO layers to gether, and we are loosing one of the IO subgraphs.  It may turn out that we need to support a collection of IO subgraphs in BlockwiseIO

Okay @rjzamora , here is the next blockwise failure case: array creation -> map blocks with broadcasting. I think this is one that is verging on a case where we might not want to do it blockwise (or defer that until later), but it should at least not error:
def func(x, y, z):
    return x + y + z

a = da.ones((3, 4), chunks=(3, 2))
b = da.ones((6, 2), chunks=(3, 2))
c = da.ones((4,), chunks=(2,))
d = da.map_blocks(func, a, b, c, chunks=((3, 3), (2, 2)), dtype=a.dtype)
d.compute()

Or, an even simpler example that involves some inter-block communication:
y = da.ones((2, 2), chunks=1)
y.transpose().compute()

It seems to fail for similar reasons to the above -- some arg substitution isn't happening.

It seems to fail for similar reasons to the above -- some arg substitution isn't happening

Thanks @ian-r-rose !  It looks like I may just need to do task substitution a bit "less efficiently" (and not worry about knowing the specific indexing rule to search for) until I can work out a more-clever apporach.

@ian-r-rose - I submitted #6931 to (hopefully) address the latest bug you discovered.  I would have pushed to this PR, but I don't believe I have permissions to do that.

@ian-r-rose - I submitted #6931 to (hopefully) address the latest bug you discovered. I would have pushed to this PR, but I don't believe I have permissions to do that.

Hmm, I have the box checked that allows for maintainers to push commits. Perhaps there was a conflict? (n.b., I just rebased and force pushed.

Hmm, I have the box checked that allows for maintainers to push commits.

Right - I don't have maintainer/write privileges :)

Thanks for the review @rjzamora. I think there will need to be some follow-up work for things like from_array, but this is a decent checkpoint.

Nice green check marks @ian-r-rose @rjzamora! I'll make sure to look through the changes here tomorrow

Thanks for the review @jrbourbeau, and thanks for all the back-and-forth @rjzamora!

This seems to have broken some xarray tests: https://github.com/pydata/xarray/issues/4703. KeyErrors raised for keys all-aggregate and blockwise-create-zeros
Sorry I don't have a minimal example yet.

Thanks @dcherian !
It looks like blockwise fusion is getting tripped up in some cases - I'm looking into it now.


Miscellaneous corrections to and polishing of README.md

Thanks. I'm working on bringing it into the main branch...

On Sat, 26 Nov 2016 18:27:37 -0800, Jon Bennett<EMAIL_ADDRESS>wrote:

Thanks. I'm working on bringing it into the main branch...

It might be too late,
but please wait a little bit for me to rebase that stuff
yet yet yet again.
Also, for cleaner history,
I recommend against doing the merge from github's web site.
Do the merge on your own box, then push the result back to github.

On Sat, 26 Nov 2016 18:27:37 -0800, Jon Bennett<EMAIL_ADDRESS>wrote:

Thanks. I'm working on bringing it into the main branch...

I have rebased my old commits, yet yet yet yet again
so that when you merge, it will be a trivial ("fast-forward") merge
that makes the provenance ASCII artwork (and github "network")
a trivial clean straight line.
Also, for cleaner history,
I recommend against doing the merge on github's web site.
Do the merge on your own box, then push the result back to github.
The commands on your own box would be something like:
git remote add jep https://github.com/james-prior/chicken-coop.git ;# if not done previously
git fetch jep
git checkout master ;# unnecessary if you are already on that branch
git merge jep/master
git push origin master ;# that assumes that "origin" is for git@github.com:jondbennett/GaryCooper.git

Let me know if you need help with doing git on the command line.
Also see my terse notes git.redacted and github.
By the way, since the original pull request,
an additional commit was added to change Garrage to Garage.

Jim,
Ann is about to arrive home, so I won't have any more time to play
today, but I tried the
git commands. The first one seemed to fail:
jon@Origin:~/Documents/Dev/Dev_Share/GaryCooper/GaryCooper$ git remote
add jep https://github.com/james-prior/chicken-coop.git
fatal: Not a git repository (or any of the parent directories): .git
On 11/27/2016 12:18 AM, James Prior wrote:

al commit was added to change Garrage

--
Jon
http://www.jondbennett.com

On Sun, 27 Nov 2016 10:21:53 -0800, Jon Bennett<EMAIL_ADDRESS>wrote:

git commands. The first one seemed to fail:
jon@Origin:~/Documents/Dev/Dev_Share/GaryCooper/GaryCooper$ git remote
add jep https://github.com/james-prior/chicken-coop.git
fatal: Not a git repository (or any of the parent directories): .git

Did you already have a git repository in the
~/Documents/Dev/Dev_Share/GaryCooper/GaryCooper
directory? Is there a .git subdirectory in the above directory?
If not, try the following:
cd ~/Documents/Dev/Dev_Share/GaryCooper/
mv GaryCooper GaryCooper.old
The clone command requires ssh keys to be set up.
Read my github notes file
(referenced in my comments on my pull request)
which likely refer to reading some github pages
about using ssh keys with github.
It's the way to go.
git clone<EMAIL_ADDRESS>cd GaryCooper
then resume with the git remote add command.

I like that you kept the switches away from the chickens.

OK, I got it all merged. No apparent problems. I'll compare the old and new
directories to make sure everything got there OK.
On 11/27/2016 02:52 PM, James Prior wrote:

On Sun, 27 Nov 2016 10:21:53 -0800, Jon Bennett
<EMAIL_ADDRESS>wrote:

git commands. The first one seemed to fail:
jon@Origin:~/Documents/Dev/Dev_Share/GaryCooper/GaryCooper$ git remote
add jep https://github.com/james-prior/chicken-coop.git
fatal: Not a git repository (or any of the parent directories): .git

Did you already have a git repository in the
~/Documents/Dev/Dev_Share/GaryCooper/GaryCooper
directory? Is there a .git subdirectory in the above directory?
If not, try the following:
cd ~/Documents/Dev/Dev_Share/GaryCooper/
mv GaryCooper GaryCooper.old
The clone command requires ssh keys to be set up.
Read my github notes file
(referenced in my comments on my pull request)
which likely refer to reading some github pages
about using ssh keys with github.
It's the way to go.
git clone<EMAIL_ADDRESS>cd GaryCooper
then resume with the git remote add command.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jondbennett/GaryCooper/pull/1#issuecomment-263143111,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANHY9KKBvGWNwP5FTQgyZqMYo5hfq3Lzks5rCd95gaJpZM4KvWCh.

--
Jon
http://www.jondbennett.com

Hi Jon,
On Thu, 01 Dec 2016 11:38:15 -0800, Jon Bennett<EMAIL_ADDRESS>wrote:

OK, I got it all merged.

Congratulations on doing a non-trivial merge.
They can be quite messy, can't they?
We can play with various ways of dealing with that later.
Jim


Allowing some 3D tools to stretch to the dimensions of their container.

Some minor styling changes to allow the shadow cast tool to stretch to its container's size. It was working previously only by accident because Esri's CSS had "width: 200" which is invalid. They changed it in 4.28 to "width: 200px" which made it much smaller and hard to use.
I also updated some packages to fix audit issues.

Looks like the Slice component has some sizing issues...

@edorableraf, those issues should be fixed now by my latest update. @scottander, please have a look at the changes when you have a sec.

@eric-parsons Looks good. One styling nitpick that I missed from last time, but probably OK to merge with or without a fix.
Font colour for the elevation profile layers is hard to read in dark mode:

Odd, it looks fine to me, both in preview and local:

Both in Brave and Firefox 🤷. It's either a caching issue or some strange OS issue.

Looks like the Slice component has some sizing issues...

@edorableraf, those issues should be fixed now by my latest update. @scottander, please have a look at the changes when you have a sec.

Looks good to me.

I checked again and it looks fine now. Not sure what was the cause, but we're probably good to go.

Both in Brave and Firefox 🤷. It's either a caching issue or some strange OS issue.


DPL-nnn - As a user I need to be able use the advanced options for SLv11 Run Design [PLACEHOLDER]

User story
As a user I need to be able use the advanced options for SLv11 Run Design
Who are the primary contacts for this story
e.g. John S (don't include surnames in public repos)
Acceptance criteria
To be considered successful the solution must allow:

[ ] add a list of acceptance criteria here
[ ] ...

Dependencies
This story is blocked by the following dependencies:

#<issue_no.>
sanger/#<issue_no.>

References
This story has a non-blocking relationship with:

#<issue_no.>
sanger/#<issue_no.>

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

Smrt Link v11 is going to be deprecated


feat: update avatar creator simple scene to contain user management, create, and save avatar functionality

SDK-683

Description

Update the avatar creator scene, so that you can log in/log out, and create and save new avatars from the template.

How to Test

Verify, that everything works

Looks good. Not specifically related to this PR but I think there are some things we could add or improve on like:

On the Avatars (user avatars) panel it could show some text if it's empty like "Sign in to view avatars" or "no avatars found"
When you click "Select Avatar" on a user avatar in this example it actually does nothing. Perhaps we should make it load an avatar?
maybe a separate task to improve the UI layout a little. We don't need to focus too much making it pretty but maybe we can organize it in a way that makes it easier to understand. Like a panel with all the buttons and grouping under headings or something

For the first point, I don't want to introduce any new scripts to the simple avatar creator. I want it to be as simple as possible. So if a developer wants a text there, then they can add it and react against the OnAvatarsLoaded event in the avatarListElement.
For the second point, makes sense. I didn't know as well what to do with that button to be fair 😅. I'll remove it from the list prefab for now as we don't manage "game state" right now. So there's no next state, where we can close the creator and show the avatar.
For the third point, will do 👍


GLM Notation

I was wondering if this package should adopt a more standard glm notation (and this might dovetail with mixed models, zero inflation, and others) breaking models into parts.
For example
library(equatiomatic)

dat = data.frame(counts = c(18,17,15,20,10,20,25,13,12),
                 treatment = gl(3,3),
                 trials = 30)

glm.D93 <- glm(counts/30 ~  treatment, weights = dat$trials, family = binomial(), data = dat)

extract_eq(glm.D93)

Currently makes

But, often they're easier to express more fully - including showing the info about their error distribution, such as

Thanks @jebyrnes, I like this suggestion quite a bit. As you mention, it would probably help with future development as well.
Thank you for the suggestion!

Thanks! Going to see if I can futz with this, but start of semester... ha!

Okay, I have an initial attempt at this in the alternative-binomial-notation branch. It's a bit different than displayed above because I haven't (yet) had it look for a variable inside weights and had it instead just calculate the number of rows in the dataset. I can fix that later. It also has a bit of redundant code we could get rid of. But I wanted to see what we thought about this (@andrewheiss, @jrosen48).
If you checkout the branch, you can see there's a new show_distribution argument that defaults to FALSE and, at this point, only works for logistic regression and only for the binomial distribution. But it works like this
library(equatiomatic)
library(palmerpenguins)

model_logit <- glm(sex ~ bill_length_mm + species,
                   data = penguins, family = binomial(link = "logit"))

extract_eq(model_logit)

extract_eq(model_logit, show_distribution = TRUE)

And it works with probit too
model_probit <- glm(sex ~ bill_length_mm + species,
                   data = penguins, family = binomial(link = "probit"))

extract_eq(model_probit, show_distribution = TRUE)

I haven't submitted a PR yet because I think it still needs a bit of work. But I wanted to post this now to get feedback. Worth continuing to pursue? Also, @andrewheiss in particular, the approach here is a bit ad hoc. If you can think of other approaches that are more systematic that would help us with further development that would be good too.

Also, if it would be easier to review this through a PR I can make just a few lingering edits tonight and the submit it that way.

Ooh, that's so cool! I like it a lot!
I have a tiny PR related to probit formatting (Φ[] instead of φ()) that you might want to merge in before this, and then if you want to submit a PR for the alternative binomial branch, I'll take a look

Okay, sounds good!


Setup CI

Hi @belkassaby , now that the build passes, could you please setup CI in a similar way you set it up in Biodownloader?
I am wondering though if we should create a separate profile for node setup in frontend module. The build of that module is taking ages to complete..

I would be willing to do this but I am not part of https://github.com/TheJacksonLaboratory organization on github, therefore cannot link in CI.

I am not aware that adding a CI requires you or anybody else to be part of any organization. The CI I have on my mind should execute the Maven build and run tests.
Am I missing something? Is there frontend specific thing that needs the contributor organization? Or is this related to privileges? I can grant you Write privileges if you'd like to have them, and you always can open a PR from your fork.

@ielis yes we should have a CI/CD for the frontend and another one for the backend.

@gerring ask RIT I think so they can add you to the Jacksonlaboratory organization on github. That's what I did about a year ago.

@belkassaby , I'll setup Github actions workflow for running tests just on backend modules.


Fixed typo: 'GPDR' to 'GDPR' in SETUP.md

Addressed a typo: replaced 'GPDR' with 'GDPR' in the SETUP.md for accuracy and consistency.

I do not accept PRs in the repos, especially the ones that fix just a typo to get their name in the repo as a contributor.

Understood, and I respect your policy. No need to merge – I just wanted to bring the typo to your attention. Thanks!


Image update, Dockerfile added.

Midterm updates for absentee ballot delivery page

We need to hold this one for a minute because the nginx.conf conflict with the Cloud Foundry deployment


Can we still pass store's dispatch function to the generator function?

Hi all,
According to the documentation

We could pass the Store's dispatch function to the Generator. Then the Generator could invoke it after receiving the fetch response

Is that still true?
Assuming I dispatch an action called counter/asyncIncrement somewhere and I have the following watcherSaga function
function* watchAsyncIncrement() {
  yield takeEvery("counter/asyncIncrement", incrementAsync);
}

The workerSaga generator function could accept the action prop I know that, but what about the dispatch prop? Without the dispatch prop we could still declare side effect by using put which is built in redux saga. Can someone help?

See here: https://redux-saga.js.org/docs/api#takeeverypattern-saga-args
You can pass arguments to the end of takeEvery and they will get sent to incrementAsync.
function* incrementAsync(dispatch, action) {}

function* watchAsyncIncrement(dispatch) {
  yield takeEvery("counter/asyncIncrement", incrementAsync, dispatch)
}

You got half-way there.  There is no code within redux-saga that passes dispatch, this is considered an anti-pattern.  You should just use put to dispatch actions inside a generator.
Having said that, to get your example to work, you must pass store.dispatch into the sagaMiddleware.run function.  Then you must pass it to the rootSaga and then your watch function.  I've forked your codesandbox and got it working: https://codesandbox.io/s/affectionate-surf-hyeqcv


Grid row nested within semantic grid margin error

A grid nested within a semantically named grid never gets the margin adjustment to prevent the nested grid from being inset.

Title

			Content

Title

			Content

The first example incorrectly insets the "Content" nested row. The second example correctly vertically aligns.
In the first example's nested row the margins are set by .row, while the second is .row is overriden by .row .row.

The mixins and built-in classes weren't designed to be mixed, so you'll need to do a little extra legwork to make them work together. To solve the nesting issue, nest the .row selector inside your custom class and invert the margins:
.custom-row {
  @include grid-row;

  .row {
    @include grid-row-nest;
  }
}

Should this not be somewhat automatic? As nesting should be possible by default?


Create<EMAIL_ADDRESS>with missing headers

This adds some missing headers from the original BUILD file needed to build rules_pcl. The actual content of the BUILD file was copied from rules_pcl.

Closing in favor of #1069


Update GitHub action

Currently no github action was running when pull request was created, also deploy step will be skipped for pull request events.

Verified as well that deploy step was not happening.


WGAN-GP Keras tutorial is slow to start the first epoch #48356

Hi there, I have opened the same issue in the TensorFlow github, as I am not sure where it fits better, but here it goes:
Describe the current behavior
When I run the  WGAN-GP tutorial from the Keras website, I notice that the first epoch takes a really long time to start in both CPU and GPU, up to a minute.
Describe the expected behavior
The first epoch should start promptly, as it happens with the other tutorials. For example the VAE and traditional DCGAN
Standalone code to reproduce the issue
The WGAN-GP colab. Choose a runtime accelerator and click on run all. The first epoch will always have a delay when starting training.
The VAE colab and DCGAN colab do not exhibit this regression.
Other info
I can reproduce the same performance issue on my local computer, so this is not a colab issue.

@AakashKumarNain who is the original author the notebook. https://github.com/keras-team/keras-io/pull/15.

This is weird. Although there is nothing special about the model here, so model is definitely the problem. The only thing that can be a "bit" slow is the gradient_penalty() but I doubt that would add so much of training time. I would take a look at this. Thanks for reporting.

No worries, I'd be glad to have this fixed as I've been tinkering a lot more with custom architectures with explicite gradient tapes and this is a bit of a paper-cut. I'm happy to further debug if you need me check anything.

Can you try to using the TF debugger and see which op is taking time?

@romanovzky did you try using the TF debugger?

Hi, I'm sorry but I have a lot on my hands right now and my current
on-going projects do not involve these type of architectures. Might be
able to pick it up again, but not in the next few weeks.
On 07/09/2021 07:39, Aakash Kumar Nain wrote:

@romanovzky https://github.com/romanovzky did you try using the TF
debugger?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keras-team/keras/issues/14580#issuecomment-914033250,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3O6K6BXPYMSTB3CJX446TUAWXRHANCNFSM42QKSUOA.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

No worries.


ranger resets to default colorscheme in terminator

It seem that every time ranger does something that updates the whole window in terminator, it resets the whole terminal to the default colorscheme (the one that was set in your configs, ignoring pywal's colorscheme).
The steps to reproduce this issue are quite simple:

Open up ranger through the command;
Do anything that updates all of the terminal window, for example, in the gif, I opened up vim (I've tested with commands such as :shell pandoc ... and :shell git ... that, while executing, update the whole window, and for things as the the S mapping in ranger, that takes me to my shell map S shell zsh -c "cd %d; zsh").

Or, if you open up ranger with a custom mapping (for example, I have $mod+r on i3wm), ranger will not get the custom colorscheme from the start.
Expected is you would have your custom colorscheme, but what happens is that ranger sets the default colorscheme back. That might have not been clear in the gif because the custom colorscheme and the default were very alike. In the end, when I open up two different terminals, the left one is terminator and the right one is URxvt. The right one is with the custom colorscheme, but terminator reverted back to the default colorscheme - and it affects the whole terminal window - so if I leave ranger, the terminal doesn't have the custom colorscheme set anymore.
I should also mention, If I haven't yet, that this doesn't happen on URxvt, neither the ranger issue, nor the mouse thing (maybe because it uses Xresources). I can't say about other terminals, but I can say that it happens in terminator, which is the one I recorded on (it might even be a terminator issue, but I haven't got the time to test on different emulators).
I'm sorry if it was not clear what was happening. And thank you for your patience and willingness to resolve these little issues.
Here's the above mentioned gif:

https://gfycat.com/gifs/detail/OrderlyUnsightlyFlicker

I too also use terminator as a daily terminal, but i think this issue belongs to terminator. The problem is even if i lose focus for a sec from the main window of terminator the cholorschemes are back to default(whether its ranger,cmus,htop, u name it. Same issue goes with neofetch, where the image dissapear everytime u lose focus of the window. Ive tried with urxvt, gnome-terminal, xfce4-terminal it works.
So i'm guessing its more a terminator issue than a pywal.

So here i'am, i went to terminator home page and got the last version and compiled from source and installed it, last version is 1.91. Opened two terminator windows, in one window i opened ranger, in the other one i ran the command "wal -i /pathtoimages" and wollaaa, it worked, colors changed automatically and fast af, i could switch between windows and no default mode anymore. Anyway bro i suggest you to give it a try.
First download and install this https://launchpad.net/ubuntu/xenial/i386/intltool/0.51.0-2  &&
Here's the link to the lastest version  https://launchpad.net/terminator/gtk3/1.91, just extract it and run sudo python ./setup.py install and it will work (tested on ubuntu).

All right! I'll give it a try. Though I have version 1.91 installed through pacman (on Arch Linux), and it still doesn't work, but I'll test compiling it from source.

What worked for me is making a shell script to launch Ranger like this. It runs the command to update termites' color scheme right before ranger:
#!/bin/bash
(wal -r &)
ranger


[build] raylib 2.0 on macOS is confusing and broken.

Sorry for such long post. TLDR: I'm keen to learn raylib, but am having a hard time with raylib 2.0 on macOS, and am really just sharing the experience in the hope it can be improved.
Using macOS 10.14.3, I installed raylib using Homebrew (as suggested in the wiki), which installed the package without an issue.
Once installed, the wiki does not explain how to use the library, and I couldn't find any other docs on how to compile a raylib example on macOS.
From (very limited) experience from trying raylib on a RPi, I remembered that it bundled a bunch of examples, so thought I'd try to find those. This stuff is probably obvious to people who are more familiar with raylib, but for new users, it's really isn't clear how they get started.
Looking in the system directory that Homebrew installs raylib to (/usr/local/Cellar/raylib/2.0.0) reveals that the examples are not included in the package.
I had a copy of the raylib git repo in my home directory, so tried the examples from there. From the raylib/examples directory, I ran make path PLATFORM=DESKTOP_PLATFORM replacing path with something like core/core_basic_window.
Most of the examples will not compile, and few of those that do compile will run.
Note: A handful of examples from the core directory do compile and run correctly (core_basic_window, core_input_keys, core_input_mouse, core_color_select).
The text_bmfont_ttf example compiled, but when executed, it complained that the font could not be loaded, then stated it will use the default font, then exited unexpectedly, causing the OS to complain too.
When trying physac/physics_demo, it fails to compile with a long list of references (including _InitWindow, _IsKeyDown, _Vector2Add et cetera), saying ld: symbols(s) not found for architecture x86_64. Trying to compile physac/physics_movement produces basically the exact same error.
I have raylib on my RPi3B+ still, so can personally enjoy using it there for now, but wanted to see if something can be done about macOS in general, as my experience with using brew on macOS would have honestly put me off using raylib if I hadn't already had a positive experience with it once before.

@carlsmith Thanks for reporting, seems most issues are related to not finding required external resources (images, fonts, audios, models...). Unfortunately I don't have a macOS, actually, never had one... and I'm not very fond of that platform since they announced OpenGL support removal...
I'll leave this issue open for anyone willing to contribute.

Once installed, the wiki does not explain how to use the library, and I couldn't find any other docs on how to compile a raylib example on macOS.

cc yourgame.c `pkg-config --libs --cflags raylib`

Ye, should probably be noted in the Wiki.

Looking in the system directory that Homebrew installs raylib to (/usr/local/Cellar/raylib/2.0.0) reveals that the examples are not included in the package.

Why would they? glfw3 or SDL2 don't install their examples either, neither in source or binary form, because that's not the use case. It's there so other packages can depend on it, so you could type brew install yourgame and have it automatically pull in raylib or say in your game's documentation to brew install raylib beforehand. A binary library package should install at most library, headers, documentation and maybe configuration.

I had a copy of the raylib git repo in my home directory, so tried the examples from there. From the raylib/examples directory, I ran make path PLATFORM=DESKTOP_PLATFORM replacing path with something like core/core_basic_window.
Most of the examples will not compile, and few of those that do compile will run.

Homebrew raylib tracks the latest release, which is v2.0.0. If you want examples, you need to git checkout v2.0.0, not master which has seen 9 months of changes since then.

Note: A handful of examples from the core directory do compile and run correctly (core_basic_window, core_input_keys, core_input_mouse, core_color_select).

Because these didn't change too much in the last 9 months.

The text_bmfont_ttf example compiled, but when executed, it complained that the font could not be loaded, then stated it will use the default font, then exited unexpectedly, causing the OS to complain too.

Please check if it happens with the text_bmfont_ttf example included with raylib 2.0.0.

When trying physac/physics_demo, it fails to compile with a long list of references (including _InitWindow, _IsKeyDown, _Vector2Add et cetera), saying ld: symbols(s) not found for architecture x86_64. Trying to compile physac/physics_movement produces basically the exact same error.

Please check this happens with the physics_demo example included with raylib 2.0.0.

I have raylib on my RPi3B+ still, so can personally enjoy using it there for now, but wanted to see if something can be done about macOS in general, as my experience with using brew on macOS would have honestly put me off using raylib if I hadn't already had a positive experience with it once before.

That's unfortunate. We should reword the documentation to note that homebrew packages tracks releases, not master.

I've amended the documentation.

Thank you, @a3f. Your post is very helpful, and things make a lot more sense now.
I'm a Web developer, and still new to C programming, so a lot of the confusion stems from my own ignorance. I'm always at least slightly confused at this stage. I just figured that raylib is promoted as good for beginners, so this kind of feedback (and your response to it) might be useful.
Thanks for your patience.

Unfortunately I don't have a macOS, actually, never had one... and I'm not very fond of that platform since they announced OpenGL support removal...

@raysan5, in my defense, I've only ever had one Apple product. I bought a MBA13 back in 2013, when OS X was much more developer friendly, and my hardware still works fine (and I have Linux installed on everything else), so just haven't upgraded. I'm mainly interested in using raylib on RPi ultimately.
I'll close the issue. Thanks, guys.

One last thing, @a3f: You forgot the -b flag in your comment:
git checkout -b v2.0.0

One more last thing: On Mac, you will get an error when running cc:
/bin/sh: pkg-config: command not found

Running this will fix it:
brew install pkgconfig

Thank you, @a3f. Your post is very helpful, and things make a lot more sense now.

Great. Please report back if you run into further issues, I use macOS at home, so I might be able to help :)

@carlsmith Thanks for reporting, seems most issues are related to not finding required external resources (images, fonts, audios, models...). Unfortunately I don't have a macOS, actually, never had one... and I'm not very fond of that platform since they announced OpenGL support removal...
I'll leave this issue open for anyone willing to contribute.

Don't claim to support the platform then. Installation and usage of raylib is current atrocious on a mac.

@crjenkins I'm sorry it does not work for you. Many users are happy using raylib on macOS. Feel free to join raylib Discord if you need help with it, there is a specific channel for raylib macOS users.

One last thing, @a3f: You forgot the -b flag in your comment:
git checkout -b v2.0.0

No, that would create a new branch. The goal to checkout the existing v2.0.0 tag.

@markjreed I am baffled by a comment on a 2019-2021 thread about raylib 2.0.0 when we are now at raylib 5.0.0.  Is any of it applicable to the current stable release?


Package

opened accidentally, meant to run on my fork

grin Note though that the package branch is redundant and outdated now. The master branch now fully supports the Zig package manager (and support for use as git submodule has been 'deprecated').


[BUG] - ... The command -- klib.dist_plot(df) does not plot the distribution for all the numeric features of a Dataframa

Describe the bug
The issue is that the the command -- klib.dist_plot(df) does not plot the distribution for all the numeric features of a Dataframa it just plots the ditribution for the first numeric feature only.
To Reproduce
Steps to reproduce the behavior:

Go to python notebook and import klib
Create a dataframe from any dataset in my case i used "df = pd.read_csv('https://raw.githubusercontent.com/agconti/kaggle-titanic/master/data/train.csv')"
then use - klib.dist_plot(df) to plot the distribution
See error that it plots for the first numeric only in case use also set the showall to True

Screenshots

Thank you for reporting this @Amit-0905 . It's been fixed in klib 1.2.0


JWT token and UUID parameters

Documentation is not clear about the following matters:
JWT token and UUID Headers
I know to some degree in previous issues this has been discussed but I am not very clear how I can pass in all the parameter UUIDs in my Python test function. Here is how my openapi spec is looking like:
  '/xyz/{xyzId}/something':
    post:
      summary: describe something
      description: Take a look at this snippet.
      x-ijk-docs-review: true
      operationId: takeSomeItem
      tags:
        - xyz
      parameters:
        - name: X-KLM-ID
          in: header
          description: KLM ID.
          required: true
          schema:
            type: string
            format: uuid
        - in: path
          name: xyzId
          description: xyz ID.
          x-soph-docs-review: true
          required: true
          schema:
            type: string
            format: uuid

For header X-KLM-ID above as it is a UUID that must always accommodate with request headers, how can I construct a header as such with my tests, would the following be the optimized way:

import schemathesis
import pytest
from hypothesis import settings, Phase

URL="https://api-ca01.dev.local.pqr.com"

schema = schemathesis.from_path(
	"openapi.yaml",
	skip_deprecated_operations=True,
	validate_schema=True,
	base_url=URL
	)

@pytest.fixture
def token():
    return "<JWT token is generated every 720 seconds!>"

@schema.parametrize()
@settings(max_examples=25)
def test_api(case, token):
	case.headers = {"Authorization": f"Bearer {token}"}
	case.headers["X-KLM-ID"] = "d4dd94e9-dcb2-4e1c-927d-b257e5e73261"
	case.call_and_validate()

Questions to help quick start guide improvements

Is the passage of headers as above correct? or there must be a different way to pass X-KLM-ID and authorization token?
Where can I find all the options that can go with schemathesis.from_path(), for example, can I pass --checks=all the same way we do with CLI?
I know there is no JWT token refreshable option. But, how can we auto-refresh the JWT token while the program is running?
Should we consider some auto-refresh timed window inside this function:

@pytest.fixture
def token():
    return "<JWT token is generated every 720 seconds!>"

Is there a way to have similar options to what RESTler carries? e.g., option parameter that can be described in user_settings.json, e.g.,
    "token_refresh_cmd": "~/refresh_token.py",
    "token_refresh_interval": 720,

UUID path params
With RESTler, I can pass those fixed value uuid path parameters in the dictionary file. But, I wonder how can I do this in Schemathesis' python test file? I have about 10 UUID params. For example, in RESTler I can do this:
  "restler_custom_payload_header": {
    "X-KLM-ID": [
      "d4dd94e9-dcb2-4e1c-927d-b257e5e73261"
    ]
  },
  "restler_custom_payload": {
    "internalId": [
      "f4dd94e8-dcb2-4e8c-927d-b257e5e73232"
    ],
    "externalId": [
      "7dafa30d-25d9-4e1c-80b6-f842e4412f51"
    ],
    "homeId": [
      "316e513d-bcf1-474f-8273-8cfe96f9bd4f"
    ],
    "faceAgentId": [
      "316e513d-bcf1-474f-8273-8cfe96f8bd4f"
    ],
    "userId": [
      "308051ea-8724-41ab-b22b-46dda710e2a6"
    ],
    "groupId": [
      "8537e5dc-0359-4af9-b88c-dcaf7b26376e"
    ],
    "answerIds": [
      "b12b26e1-cb8c-4d72-8bdc-052aac79d981",
      "8dc3ade9-e1af-4c47-9309-350aab23517d"
    ]
  }

Is there any analogous way to make the above in my python tests for Schemethesis. i.e., is the following the right way:
@schema.parametrize()
@settings(max_examples=25)
def test_api(case, token):

	case.headers = {"Authorization": f"Bearer {token}"}
	case.headers["X-KLM-ID"] = "d4dd94e9-dcb2-4e1c-927d-b257e5e73261"

	case.path_parameters["internalId"]    = "f4dd94e8-dcb2-4e8c-927d-b257e5e73232"
	case.path_parameters["externalId"]  = ["...", "..."]
	case.path_parameters["..."] = "..."

	case.call_and_validate()

In line with the above note, I am trying to add the path parameters using case.path_parameters for {dataRegion}:
servers:
  - url: 'https://api-{dataRegion}.local.xyz.com'
    description: local service environment.
    x-ijk-docs-review: true
    variables:
      dataRegion:
        description: Data region where data stored.
        x-ijk-docs-review: true
        default: ca01
        enum:
          - ca01
          - ca02
          - ca01
          - ca02
          - ca03

But I keep getting the following error:
    case.path_parameters["dataRegion"]  = "ca01"
TypeError: 'NoneType' object does not support item assignment

I have a similar issue for the rest of the body path parameters as described above from OpenAPI for UUIDs.
This is how I have a python test:
@schema.parametrize()
@settings(max_examples=25)
def test_api(case, token):
	case.headers = {"Authorization": f"Bearer {token}"}
	case.headers["X-Tenant-ID"] = "d4dd94e9-dcb2-4e1c-927d-b257e5e73261"
        case.path_parameters["dataRegion"]  = "ca01"
	case.call_and_validate()

Hi @mbiuki !
Thank you for asking :) I'll try to answer the questions below and will think about how they could be accommodated in the docs.

For header X-KLM-ID above as it is a UUID that must always accommodate with request headers, how can I construct a header as such with my tests, would the following be the optimized way:

Is the passage of headers as above correct? or there must be a different way to pass X-KLM-ID and authorization token?

I think that it depends on a particular test's goals and reflects how deep it reaches into the application code.
If the goal is to go beyond authorization logic and 404 responses on non-existing ID, then yes, for Python tests it is the way to go. Maybe a more generic version might look like this:
@schema.parametrize()
def test_api(case, token):
    case.headers = case.headers or {}
    case.headers["Authorization"] = f"Bearer {token}"
    case.headers["X-KLM-ID"] = "d4dd94e9-dcb2-4e1c-927d-b257e5e73261"

In this case, the attribute itself is not overridden - if there are other headers, they won't be lost. But based on the schema you provided, your example should work :)
If the goal is to focus on the authorization code or code that handles this UUID value, then Schemathesis can generate them. In this particular case, Authorization header will be generated if the securitySchemes key defines it, and UUID requires a custom string strategy:
from hypothesis import strategies as st
import schemathesis

schemathesis.register_string_format("uuid", st.uuids().map(str))

The UUID format is not included by default in Schemathesis (but probably it makes sense to have it this way, though) as it is not defined in the OAS spec.

Where can I find all the options that can go with schemathesis.from_path(), for example, can I pass --checks=all the same way we do with CLI?

Unfortunately, they are quite underdocumented in the public API reference and not much visible at the moment. It surely can be improved.
The checks behavior is described in this section.

I know there is no JWT token refreshable option. But, how can we auto-refresh the JWT token while the program is running?
Should we consider some auto-refresh timed window inside this function:
Is there a way to have similar options to what RESTler carries?

There is a relevant issue for that, but it is mostly related to CLI. For Python code some caching (e.g. from the cachetools library) might solve it:
@pytest.fixture
def token_getter():

    @cached(cache=TTLCache(ttl=720))
    def retrieve_token():
        ...  # E.g. make a call to the API

    return retrieve_token

...
def test_api(case, token_getter):
    token = token_getter()
    case.headers = {"Authorization": f"Bearer {token}"}
    ...

As Hypothesis tests are executed many times within a single Pytest-level test, it is crucial to make a call within the test body. I will think about the problem more generally and maybe include some facilities to simplify auth handling.

Is there any analogous way to make the above in my python tests for Schemethesis. i.e., is the following the right way:

It depends on the number of possible values for each parameter. If there is only one single value, then yes, you can set them directly. If you'd like to take a random value from the list of possible values, it should be accounted with the underlying Hypothesis machinery (otherwise, the test may be concluded as flaky). Here is an example:
from hypothesis import strategies as st

@schema.parametrize()
@schema.given(data=st.data())
def test_password_reset(data, case):
    case.path_parameters["externalId"]  = data.draw(st.sampled_from(["a", "b", "c"]))
    ...

You may find more info in this docs section (Sphinx mangled all lists for some reason on readthedocs). Note that the sampled_from argument should be ordered.

I have a similar issue for the rest of the body path parameters as described above from OpenAPI for UUIDs.

Interesting! Schemathesis does not consider variables in servers for data generation. It just takes the default which is required by the spec (so it always there) and interpolates the URL template. path_parameters are only for the parameters(Parameter Object in terms of Open API) that have path in their in field. But I never actually thought about deferring server URL template interpolation to later stages. I need to think about it more.
Similar behavior might happen if there no header parameters defined - Schemathesis will generate None for such cases. For requestBody, it might also generate a special sentinel value NOT_SET to distinguish cases when the body is not defined, and it has None as the value.
At the moment, I can suggest passing the base_url parameter to call_and_validate explicitly if you'd like to use dataRegion different from the default:
...
def test_api(case, token):
    ...
    case.call_and_validate(base_url="'https://api-ca02.local.xyz.com'")

There is no public API to get that URL template, but you can do it with something like case.operation.schema.raw_schema.get("servers")[0]["url"] depending on your actual servers value.
I hope that it helps :) Let me know what do you think! I'd be happy to elaborate and will plan to work on the documentation to reflect these points.
Cheers,
Dmitry

Hi @Stranger6667,
Thanks for your response. I went halfway through your responses in the above, and first want to check a few things before moving on with the second half of your responses. Please see the enumerations as follows.

So, is this a correct Python test code:

from hypothesis import strategies as st
from hypothesis import settings, Phase
import schemathesis
import pytest

# Load the schema
pathToYAML="/path/openapi.yaml"
URL="https://xyz.com"
schema = schemathesis.from_path( pathToYAML,
	                            skip_deprecated_operations=True,
	                            validate_schema=True,
	                            code_sample_style="curl",
	                            base_url=URL)

@pytest.fixture
def token():
    return printToken() #<=== function call to extract the JWT token.

@schema.parametrize()
def test_api(case, token):
    case.headers = case.headers or {}
    case.headers["Authorization"] = f"Bearer {token}"
    case.headers["X-KLM-ID"] = xklmid
    schemathesis.register_string_format("uuid", st.uuids().map(str))
    case.call_and_validate()

I have a function for token that auto-generates JWT, and with the above, I would just run pytest myfile.py. Is this correct?

I see that all checks are applied by default. So we do not really have to do anything for activating checks in the above snippet.
By the way, it looks like the above test generates a new JWT token for every test, why is that? I can see from the logs that for every test that is reporting the failure, JWT token value is different!
How can I increase the response time as some of the failures are due to check if the response occurred in less than 500ms? I know two parameters from CLI for this, namely, --max-response-time=5000 and --hypothesis-deadline=5000. How can I apply them in my Python test snippet above? I could not check any of these in the API public reference guide.

First of all, I'd like to thank you for asking all these questions, I really appreciate that :)

So, is this a correct Python test code:

Generally yes, and here is a little thing I'd propose to change.
schemathesis.register_string_format("uuid", st.uuids().map(str)) mutates global state, and it is better to have it on the module level rather than in the test body (probably it worth mentioning in the docs as well).

By the way, it looks like the above test generates a new JWT token for every test, why is that?

schema.parametrize behaves similarly to pytest.mark.parametrize, and if your API schema has, e.g., 5 operations, then the schema.parametrize decorator will create 5 different pytest-level tests. Each of them will have its own token fixture as its scope defaults to "function", i.e. token will be called 5 times, and each pytest-level test will have its own token.
The next step is that Schemathesis converts each pytest-level test to Hypothesis test via hypothesis.given under the hood. Hypothesis executes this test many times and preserves pytest fixtures as is. Here is the workflow for some hypothetical API with multiple operations (e.g. A, B):
- test_api[A]. `token` is evaluated
  - test_api[A]-1. Hypothesis generates `case` for operation A
  - test_api[A]-2. Hypothesis generates `case` for operation A
  - ...
- test_api[B]. `token` is evaluated
  - test_api[B]-1. Hypothesis generates `case` for operation B
  - ...

Pytest will report 2 tests - test_api[A] and test_api[B]
token will be evaluated twice
Hypothesis will generate case instances and pass it and token to the test body

The usual way to solve it in non-Hypothesis-based tests is to change the fixture scope to module or session:
@pytest.fixture(scope="session")
def token():
    return printToken() #<=== function call to extract the JWT token.

The fixture above will be evaluated only once per test run, and all tests will use the same token.
However, the token may expire during the test run, and it will be nice to refresh it when it happens. As it can happen at an arbitrary moment that is not bound to any test phase, I think that the best way to solve it is to call a TTL-cached version of the printToken function inside test_api.
TOKEN_LIFETIME = 720
THRESHOLD = 5

@pytest.fixture(scope="session")
def token_getter():

    @cached(cache=TTLCache(ttl=TOKEN_LIFETIME - THRESHOLD))
    def retrieve_token():
        return printToken()

    return retrieve_token

...
def test_api(case, token_getter):
    token = token_getter()
    case.headers = {"Authorization": f"Bearer {token}"}
    ...

This way, if the token is older than 715 seconds at the beginning of a test, then it will be refreshed. The THRESHOLD value is in place to cover a bit of delay between getting the token and the actual token validation on the server-side. Still, it actually depends on the token validation rules (leeway and such).

How can I increase the response time as some of the failures are due to check if the response occurred in less than 500ms?

You can use the hypothesis.settings decorator:
from hypothesis import settings

...

@schema.parametrize()
@settings(deadline=None)
def test_api(case, token):
    ...

This will disable the deadline completely, but the test still may fail due to Hypothesis health checks - if the schema is too complex, etc. You can disable them via the suppress_health_check argument to settings.
I want to note some semantic differences between --max-response-time and --hypothesis-deadline.
The former controls the API call time that is considered as a test failure. In a Python test, it is equivalent to:
from datetime import timedelta

...
def test_api(case):
    response = case.call()
    assert response.elapsed < timedelta(milliseconds=5000), "Too slow!"

The latter controls the time for which the whole test should run to be considered as invalid and reported as an error. I.e., it is more like a health check to prevent too long test runs.

Thanks, @Stranger6667, for your reply. For the cache section in your comment above, it is noteworthy to mention that the Python cachetools library should be installed to get it to work. And maxsize must also be passed as a parameter to TTLCache.
pip3 install cachetools
from cachetools import cached, LRUCache, TTLCache

TOKEN_LIFETIME = 720
THRESHOLD = 5
...
@pytest.fixture(scope="session")
def token_getter():
    @cached( cache = TTLCache( maxsize = 1, ttl = TOKEN_LIFETIME - THRESHOLD))
    def retrieve_token():
        return printToken() #<=== function call to extract the JWT token.

    return retrieve_token

Hi @Stranger6667, here, I am reviewing the second half of your comments above.

I know there is no JWT token refreshable option. But, how can we auto-refresh the JWT token while the program is running?
Should we consider some auto-refresh timed window inside this function:
Is there a way to have similar options to what RESTler carries?

There is a relevant issue for that, but it is mostly related to CLI. For Python code some caching (e.g. from the cachetools library) might solve it:
@pytest.fixture
def token_getter():
@cached(cache=TTLCache(ttl=720))
def retrieve_token():
    ...  # E.g. make a call to the API

return retrieve_token

...
def test_api(case, token_getter):
token = token_getter()
case.headers = {"Authorization": f"Bearer {token}"}
...
As Hypothesis tests are executed many times within a single Pytest-level test, it is crucial to make a call within the test body. I will think about the problem more generally and maybe include some facilities to simplify auth handling.

For now, the above solution is working. Thanks for providing guidelines. But, yes, it would be great if, similar to RESTler, there could be a command option for a refreshable token in seconds to update the token bearer autonomously.
For example,
 --token-refresh-cmd": "/path/token.py",
 --token-refresh-interval": 720,

token.py could generate something like:
{u'db74fa8e-911f-40d5-94aa-774bc22002fc': {}}
Authorization: Bearer <....>

Since I have some experience with RESTler, the second line is always selected (the first line is ignored and I do not know why it is even needed).

Hi @Stranger6667, regarding the rest of your responses above.

Interesting! Schemathesis does not consider variables in servers for data generation. It just takes the default which is required by the spec (so it always there) and interpolates the URL template. path_parameters are only for the parameters(Parameter Object in terms of Open API) that have path in their in field. But I never actually thought about deferring server URL template interpolation to later stages. I need to think about it more.

For path parameters in headers, could there be a similar design we have for custom headers, e.g., Authorization, X-KLM-ID? Could we have something implemented for:
servers:
  - url: 'https://test-{dataRegion}.tune.xyz.com/path/vx'
    description: Regional service in the test environment.
    x-ijk-docs-review: true
    variables:
      dataRegion:
        description: Data region where data played.
        x-ijk-docs-review: true
        default: ca01
        enum:
          - ca01
          - ca02
          - qa01
          - qa02
          - qa03

dataRegion in the above is a path parameter in the header that specifies the server location. It does not need to be fuzzed since the server location is one fixed assignment only. Could we have an analogous template to path_parameters but for header, e.g.:
case.path_header_parameters["dataRegion"]  = "ca01"

Hi @Stranger6667,
In addition to the above discussions, I also have some questions for below:

For path parameters with fixed UUIDs, can we pass multiple of them as like below:

from hypothesis import strategies as st
from hypothesis import settings, Phase
import schemathesis
import pytest
...
@settings(deadline=None) # disable the deadline completely.
@schema.parametrize()
@schema.given(data=st.data())
def test_api(data, case, token_getter):
    token = token_getter()
    case.headers = case.headers or {}
    case.headers["Authorization"] = f"Bearer {token}"
    case.headers["X-KLM-ID"] = xklmid
    case.path_parameters["someId"] = "7dafa30d-25d9-4e1c-80b6-f842e4412f51"
    case.path_parameters["nextId"] = "316e513d-bcf1-474f-8273-8cfe96f9bd4f"
    case.path_parameters["manageId"] = "316e513d-bcf1-474f-8273-8cfe96f9bd4f"
    case.path_parameters["torId"] = "308051ea-8724-41ab-b22b-46dda920e2a6"
    case.path_parameters["wayId"] = "8537e5dc-0359-4af9-b88c-dcaf7b46376e"
    case.path_parameters["fontId"] = "b12b26e1-cb8c-4d72-8bdc-052aac79d981"
    case.path_parameters["ids"]  = data.draw(st.sampled_from(["b12b26e1-cb8c-4d72-8bdc-052aac79d981", "8dc3ade9-e2af-4c47-9309-350aab23517d"]))
    case.path_parameters["groupId"] = "MSxFdmVudDo6RW5kcG9pbnQ6Ok5vdFByb3RlY3RlZCw1MTMs"
    case.path_parameters["lastId"] = "8537e5dc-0359-4af9-b88c-dcaf7b46376e"
    case.call_and_validate()

And all the Ids are path params in openapi, for example, manageId:
'/management/{manageId}':
   get:
     tags:
       - Endpoints
     summary: Get endpoint details
     description: Get an endpoint based on manage ID.
     x-ijk-docs-review: true
     operationId: getEndpointById
     parameters:
       - name: X-KLM-ID
         in: header
         description: KLM ID.
         required: true
         schema:
           type: string
           format: uuid
       - name: manageId
         in: path
         description: Manage ID.
         x-ijk-docs-review: true
         required: true
         schema:
           type: string
           format: uuid

Is the above correct or is there any better way of describing fixed UUIDs?
Would the above additions extend the fuzzer into finding more thorough bugs?

Hi @mbiuki

dataRegion in the above is a path parameter in the header that specifies the server location. It does not need to be fuzzed since the server location is one fixed assignment only. Could we have an analogous template to path_parameters but for header, e.g.:
case.path_header_parameters["dataRegion"] = "ca01"

I think that it is a possible way to go; yep - I will experiment with the implementation, then I can provide more info on that matter :)

Will the above not work?

Yes, it should work.

Is the above correct or is there any better way of describing fixed UUIDs?

Yes, it is a valid approach. Depending on the test body size, you might want to move, split it, and make modifications via a hook:
from hypothesis import strategies as st

def before_generate_path_parameters(context, strategy):

    @st.composite
    def fill_parameters(draw, path_parameters):
        path_parameters["ids"] = draw(st.sampled_from(["b12b26e1-cb8c-4d72-8bdc-052aac79d981", "8dc3ade9-e2af-4c47-9309-350aab23517d"]))
        ...  # more modifications
        return path_parameters

    return strategy.flatmap(fill_parameters)

@settings(deadline=None) # disable the deadline completely.
@schema.parametrize()
@schema.hooks.apply(before_generate_path_parameters)
def test_api(case, token_getter):
    ...

It makes those modifications a bit more reusable as you can attach hooks to different functions + do filtration of generated values.

Would the above additions extend the fuzzer into finding more thorough bugs?

Usually, yes, as the input params will more likely pass validation. But it depends on the actual schema and app - passing explicit values is excluding some random values for inputs which may also have some positive effect in bug finding :) But generally, yes, such additions usually make the tests go deeper into the codebase.

Are there any logs that we could check live while fuzzing is in action to check which requests are being sent out and what are their responses?

I eventually plan to implement #701, which will provide a more or less common output format, but meanwhile, you can add some hand-crafted logging to the test function:
import structlog

log = structlog.get_logger()

def test_api(case, token_getter):
    ... # modifications go here
    response = case.call()
    log.info(path=case.path, method=case.method, ...)  # put all needed case/response parameters there
    case.validate_response(response)

The code above uses structlog installed via pip install structlog colorama (colorama provides a colored output style). By attaching various log processors (docs), you can either output these logs to stdout or some file or maybe even logstash or a similar tool, which seems quite flexible to me.
Sorry for the delay; I hope that my comments above help :)

Closing this as #966 is implemented. Once released, the docs will contain a separate section on auth. The parameters part will be a part of my future work on the docs.