Proposal for revamped docs pipeline, with example repo

📚 Documentation
I'd like to make a concrete proposal for how our docs are organized on github, built, and published.  I know this is a heavily discussed topic, and it's definitely with great appreciation for the previous work done here that I propose this.  I also recognize that there is a docs working group that I haven't been able to attend, so please accept my apologies if any toes feel stepped on.  Mostly, I'd like to propose a docs build pipeline/architecture, knowing well that this is complicated, and welcoming counter-opinions on anything I've overlooked here.
need for a sphinx theme
For me, one of the things that causes the biggest amount of difficulties is that we no longer have a pip installable sphinx them.  Our theme consumes the output of sphinx, rather than being an input to sphinx.  This is what makes it such that building and developing docs locally rarely results in a successful docs publish after PR.  Nearly every PR for the last year or so has led to a followup "fix docs" PR.
In discussion about how to let people see what the final docs will look like, things like netlify have come up.  To me, that just adds more complexity on top of the existing complexity.  If our docs had complex needs, it might be warranted, but they don't: they can very easily be purely static (and probably should be unless they really need otherwise).
So the primary requirement here is that our theme be a  pip installable sphinx theme, such that someone building locally can just make docs, see the result, and expect it to be the same as what happens when github actions does the same.
This also means that the result should effectively be a static site (no AJAX, no react, etc...).  We currently use react, but don't particularly need the power of react (we don't have any interactivity, and don't really have much need for it.  Versioned docs and simple javascript interactivity can definitely be achieved with static pages, so the two should not be conflated).
steps required to use our current theme
From conversations, I think the biggest disappointment here would probably be that our docs wouldn't match the look and feel of the hub, (until a sphinx theme was created).  Personally, I don't feel like the usage documentation needs to match the hub theme (and I do kind of like matching the general look & feel of other scientific python packages), but I can certainly understand if others feel differently on that, and I know a lot of work has gone into the current theme.  (Again, it's difficult to even suggest this...)
I recognize that's a big lift for our current theme, but when I weigh the aesthetic benefits of our current theme against the practical and structural difficulties we've had with docs this year, it feels like the right call (if perhaps just temporarily).  We could, for now, return to furo or pydata-sphinx-theme, etc... And if there is a desire to recover the look and feel of our current site, then it could be built as a sphinx theme (i.e. providing templates, CSS, and javascript).  From a webdev perspective, I know that that's a wholly unsatisfying set of tooling, and no modern interactive site would build on that sort of tech.  But a documentation site has different needs, and the complexity of the current pipeline is proving challenging for napari's needs.
proposal & example repo
I made an example git repo that has :
https://github.com/napari-docs-example/napari-docs-example.github.io

This is a single place for documentation (with the exception of API docs, which come from docstrings).  This would replace napari.github.io (which could then turn into a repository developing a sphinx theme that we could eventually use), and it would remove the docs folder and associated tooling from napari.
What you see when you clone, modify, and run make docs is exactly what you'll see when your PR gets merged.
It includes all of the tutorials, API docs, and everything.
It includes images without the need to upload them elsewhere and hotlink them.
It automatically builds upon merge to main and publishes to the gh-pages branch..

The resulting published site is here:
https://napari-docs-example.github.io/
with the exception of API docs, it's also building without any warnings (which @melissawm would probably appreciate, and would help us to catch errors).
one repo without API docs vs docs in napari
@jni had expressed a desire to not create a new repo for docs, which I do get.  But that leaves us with the repo size & images problem. Though it would be an awesome goal, it's not likely that we're going to be able to create a framework that lets us autogenerate everything we'd like to be able to show on our website (at least, not anytime soon), such as tutorial-oriented movies.  So if we stick with docs in napari, we're stuck finding some external place to host images, which has its own set of difficulties.  Even if we created a separate repo just for media, every docs PR with media would essentially be two PRs to two repos, trying to coordinate between them.  Building locally gets more complicated, etc...  it's just not awesome.
If we really wanted to maintain the feeling of a docs folder in the napari repo, we could include the "napari-docs" repo as a git submodule in the napari repo, then someone could just fetch submodules and build.
The main downside here, as I see it, is that API docs PRs go to napari, and everything else goes to napari-docs.  But I think, many people are used to the concept of API docs coming from source.  And if not, it's not a hard thing to explain to a newcomer.
what this isn't
this isn't a suggestion on the structural organization of our docs (diataxis, etc...), just a request/proposal on the build/publish pipeline and repo organization.
Thoughts?
Anyway, I hope you'll have a look at the example repo, perhaps clone and run make docs, or look at the gh-pages build, and list your concerns or thoughts here.  thanks
cc @jni, @sofroniewn, @melissawm, @neuromusic, @GenevieveBuckley, @DragaDoncila

Thanks for writing up the proposal.

Nearly every PR for the last year or so has led to a followup "fix docs" PR.

Unfortunately this has been my experience too (for PRs with large/ structural docs changes) (see #3927 as a recent example).
It seems like this would be something good to discuss at the next docs working group meeting. It looks like the next one is Wed 19th. I can try and attend then too

I'm glad I made it easy to pull out of the current theme lol
I think a lot of this makes sense. A big engineering decision for using React was to support interactive features we'd add in the future and enable code sharing with napari hub because of how similar the theme is to the hub. Versioned docs, the calendar, download matrix, and I think gifs of examples were things I had in mind. The developer tooling (fast refresh for example) and code sharing also allowed us to finish the theme in a short amount of time since we were also still developing features for the napari hub.
I'm fine with this, but it means we'll need to drop the current theme and rewrite it from scratch using HTML, CSS, and JS. We may need to drop some things like the Calendar, unless we look into a hybrid approach of using React just for specific features (which is possible, but I guess at this point I want to know if the community even wants React in the docs).
Thank you for the proposal!

So the primary requirement here is that our theme be a pip installable sphinx theme, such that someone building locally can just make docs

Isn't this something we could do with git submodules?

So the primary requirement here is that our theme be a pip installable sphinx theme, such that someone building locally can just make docs

Isn't this something we could do with git submodules?

Conceivably sure, but I haven't seen that pattern for a sphinx theme.  Is there an advantage there you're thinking about?

Versioned docs, the calendar, download matrix, and I think gifs of examples were things I had in mind

all good stuff, but versioned docs, the download matrix, and gifs of examples are all definitely possible without react (though I'm sure I'm saying something you already know).  don't know what tooling the calendar uses, so can't comment there, but surely it's possible to embed a calendar without react.  pydata-sphinx-theme does versioning with a little bit of vanilla javascript

It's mostly to get around the fact that it's not a pip installable sphinx theme. You can write the makefile to clone the theme repo and build the docs (which I thought @melissawm had in mind)

i see, so it's just to avoid having to put it on PyPI?  meh :)

Hi all!
I agree with the general gist of @tlambert03's issue, and I agree with him that a standard sphinx docs repo is preferable to the current situation. I'm a big proponent of "when in Rome...", and there should be a high barrier for doing non-standard stuff. So, I'd be happy enough with that approach.
As he's noted, though, I do prefer having docs together with the code. Part of my preference I'm sure is just habit and ecosystem practice, but I think I can at least rationalise my preference. 😜

if you have two repos, the two-PR dance is inevitable: updating an API in a PR to main will require an update to the docs in the docs repo. Ditto for updates that touch the UI.
increasing separation between docs and code increases the likelihood that docs will fall out of date with the code.
the best way for docs to be updated together with code is for them to be autogenerated from the code. This is easier to do in a monorepo.

In short, my vision for developing the perfect docs infrastructure is:

figure out example data storage (CZI provides unlimited storage in Dryad for grantees, for example)
figure out caching of said data on GitHub Actions
figure out autogeneration of screenshots (more or less trivial) and movies (less trivial, but progress was discussed a year ago already)
profit 😉

Once you have all that, it becomes ~easy to generate an entire documentation site that is up-to-date with every PR, and I think that's pretty golden. Yes, there's still the issue of e.g. diagrams, but I honestly don't have a huge concern with storing images in github PR comments — even if the system breaks eventually, the images are then easy to find based on git blame giving you the PR number.

I'm not a big fan of this idea. A full sphinx approach would be a major regression from a developmental standpoint. I would sooner have us write our own documentation engine than return to sphinx because it's just that outdated.
I believe that returning to pure sphinx would not be in our best interests long-term because:

sphinx has no multi-versioning capabilities. it's either been done via plugins (which, when last I checked, I couldn't find any that worked with the latest version), or by custom solutions such as ReadTheDocs.
themes would have to be written in plain HTML/CSS/JS which is less efficient and harder to maintain for web developers. furthermore, anyone without prior experience wishing to contribute to the theme would not be receiving exposure to the latest web technologies, so it's not all that useful to them.

Unfortunately this has been my experience too (for PRs with large/ structural docs changes) (see #3927 as a recent example).

I would like to point out that this is an issue with not having a unified docs repo (due to the copy docs script messing up) and not anything to do with the theme being built in React.
This brings me on to my next point, which is that I think many of the issues that @tlambert03 has brought up are more so because the docs are not in one unified place and less so because we customized our build process. If everything just lived in a single repo we could just use our custom build and everything would look 100% exactly the same when you build it locally vs. via CI.

so it's just to avoid having to put it on PyPI?

Not necessarily, it's something we had in mind but we need to figure out if it's possible to include node dependencies in the build pipeline. Or  we could download node and its dependencies at runtime, and run the theme build after jupyterbook build completes. For example, Furo overwrites the CSS for pygments when the build completes. Although that would be an additional layer of complexity.

(so much python tooling is based on a list of pypi installables... so having that one thing in the pipeline that doesn't fit in with the ecosystem is always a bit annoying. doable, but only with a good reason why)

The main reason for us was to improve developer experience of the theme itself. Static exports allows us to produce static HTML, CSS, and JS from React components, and fast refresh makes iteration really fast (No more 5 minute wait times for jupyterbook build to complete each time I hit Cmd + S) It also made sense from the perspective of the hub team since it means we could work in similar codebases and share code.

The main reason for us was to improve developer experience of the theme itself.

that makes lots of sense.  but it does seem like something you could sandbox a bit to your development process.  That is, we don't necessarily need every napari docs contributor to have to deal with the whole node toolset just because the theme developers work in node.
I've built websites elsewhere using react.  as I said earlier, I'm fully aware of how woefully antiquated the conventional sphinx pipeline appears to a modern web dev.  i just think we need to consider the target audience, and the specifics of our site interactivity use case here when considering whether it's worth it (even if it's clearly worth it in other webdev scenarios).

If we could package up the theme into a pip installable package that works (regardless of how it gets the node dependencies), would that be a good enough sandbox? Or is there more interest in being able to contribute to the theme without getting into Node + React?

no no, whatever you want to do on the theme dev side is fine.  you can use whatever tool chain you want there (there's no expectation that anyone has to be able to contribute to the theme easily) ... on our side, the requirements would just be that it is installable as a sphinx theme that we can add to our _conf.yml.
as mentioned in the original post, (and this is likely more limiting to you) I would also much prefer that the theme not require someone to spin up a local webserver.  you should just be able to open file://... after build

the requirements would just be that it is installable as a sphinx theme that we can add to our _conf.yml.

That's what I meant. We could set up the theme into a pip package that you can just pip install and specify in the configuration. You don't need to worry about node or anything, you can just run jupyter-book build.  The HTML will then be accessible to you (which is possible with the current theme if you do yarn build) from file://.

Nearly every PR for the last year or so has led to a followup "fix docs" PR.

I completely agree that the current process for building our docs is untenable, and it's a matter of very high priority to address this issue. I also agree that introducing more tooling e.g. netlify is complicating the matter, and not addressing the fact that PR previews should be in addition to an easy local process, not a replacement for it.

This also means that the result should effectively be a static site (no AJAX, no react, etc...). We currently use react, but don't particularly need the power of react (we don't have any interactivity, and don't really have much need for it. Versioned docs and simple javascript interactivity can definitely be achieved with static pages, so the two should not be conflated).

I tend to agree with this as well. The power of react comes into play when building websites with many, large interactive components. The only such component I can think of, as @codemonkey800 pointed out, is the calendar, and it's not clear to me that this alone is sufficient motivation (though I do love our calendar).
Versioning does remain a big question mark in my opinion. What are our current plans for solving this issue? @kne42 mentions that sphinx has no multi-versioning capabilities. How are other projects doing this? How do we plan on doing it?

That's what I meant. We could set up the theme into a pip package that you can just pip install and specify in the configuration. You don't need to worry about node or anything, you can just run jupyter-book build. The HTML will then be accessible to you fromfile:// (which is possible with the current theme if you do yarn build).

This is the holy grail imo. It should be of no relevance to someone contributing documentation what tooling the theme needs to be built, or how it is built. I think the theme should be built in whatever way is easiest for the developers, I just don't think that should change how we contribute documentation. If the theme can be easily installable for building and preview purposes, then the behind the scenes doesn't matter much to contributors.

Personally, I don't feel like the usage documentation needs to match the hub theme (and I do kind of like matching the general look & feel of other scientific python packages)

I do think this is important. As the napari hub grows, it's quite possible people will find out about napari through the hub, or through one of its plugins. From that perspective I think cohesion is important. That being said, I also think it's important that pages like our API reference are familiar to people used to browsing other Python package docs.

@kne42 mentions that sphinx has no multi-versioning capabilities. How are other projects doing this? How do we plan on doing it?

this isn't quite true, see for example how pydata-sphinx-theme does it.  yes, it requires a bit of javascript, but it's pretty minimal.  here is their implementation.

I'll also point out that, readthedocs (which has it's own versioning feature) now support jupyter-book.  but, we'd need to have a pip-installable them there

this isn't quite true, see for example how pydata-sphinx-theme does it. yes, it requires a bit of javascript, but it's pretty minimal. here is their implementation.

This seems pretty easy to implement 🤷♀

The only such component I can think of, as @codemonkey800 pointed out, is the calendar, and it's not clear to me that this alone is sufficient motivation (though I do love our calendar).

I did write up a doc sometime ago exploring React with napari.org. The features I mentioned in the doc were:

Table of Contents with automatic highlighting and collapsible sections.
Carousel of user submitted gifs demoing napari.
Installation matrix for different environments.
Unified search with the napari hub.

I'm not sure what other interactive features we'd want to add to naprai.org in the future, but given the list above, I felt it was appropriate to use React. It's hard to say because it's an investment on the future, but if we end up not implementing a lot of interactive features, then it's definitely overkill to use React.  @neuromusic @sofroniewn did y'all have other things in mind?

The version switcher should be easy to implement regardless of whether we do it with DOM APIs or React. A React equivalent would look something like this in fewer LOC (I didn't add the redirect though):
import { useRouter } from 'next/router'
import { FormControl, InputLabel, MenuItem, Select } from '@material-ui/core'
import { useEffect, useState } from 'react'

import { useJupyterBookData } from '@/context/jupyterBook'

export function VersionDropdown() {
  const { currentVersion } = useJupyterBookData()
  const router = useRouter()
  const [versions, setVersions] = useState([])

  useEffect(() => {
    async function fetchVersions() {
      const response = await fetch('/versions.json')
      const data = await response.json()
      setVersions(data)
    }

    fetchVersions()
  }, [])

  return (
    <FormControl>
      <InputLabel id="version-switcher" />
      <Select
        labelId="version-switcher"
        value={currentVersion}
        label="Version"
        onChange={event => {
          const version = event.target.value

          const url = new URL(window.location.origin)
          url.pathname = `/${version}${router.pathname}`

          window.location.href = url.href
        }}
      >
        {versions.map(version => (
          <MenuItem key={version} value={version}>
            {version}
          </MenuItem>
        ))}
      </Select>
    </FormControl>
  )
}

One docs site I like mentioning is Botorch which uses Docusuaurs for managing docs and built-in versionoing, and Sphinx for generating the API docs. This might be complicated for our needs but it's a nice example of how we can blend the python and web ecosystems together.

just to bring this back to the original point here, this isn't a referendum on react per se.  We can certainly debate whether react is "necessary" here, but this is ultimately about separation of concerns.  If you'd like to bundle react or other DOM APIs in with your theme, that's fine.  But we shouldn't depend on the theme for structure or content of the docs.  The theme shouldn't change the TOC.  There should be no problem with swapping out the theme for another theme (save, perhaps, a few special theme-specific features like a calendar, but those too should come with a theme directive or something that gets used in the markdown file).

This is some great discussion! Thanks for putting together concrete examples of how these things could look @tlambert03. One thing I would like to add which could potentially reframe the discussion a little bit...
napari.org is currently a mix between our docs and general project information, is separating these two things more explicitly something that has been considered? Most of the fancy features (calendar, download matrix) seem limited to the 'project site' side of things - this could be the 'hybrid approach' @codemonkey800 alluded to above.
Both numpy and pandas appear to have a larger separation between their 'project' site and their 'docs' site. Maybe separating concerns in this way could alleviate some of the issues around building docs and allow for the 'sandboxing' of dev tooling discussed above. I'm not sure how the numpy site is built, but their theming is more consistent between the numpy site and their docs than pandas, we could likely achieve a similar result with a docs specific sphinx theme for napari which matches the current react theme for the project site.
I'm also heavily in favour of 'docs should live in the repo if at all possible' but recognise the challenges - it seems like we can tackle this as a separate issue from the build pipeline though once a path forward has been agreed on?
Basically, what if we build docs completely separately from napari.org itself, then that static site gets pushed up to napari.org/docs which can have all of the fancy stuff?

Just for clarity, NumPy uses three repos:

API docs, how-tos, explanations are all in github.com/numpy/numpy, together with the code. These are pure sphinx, built with the pydata-sphinx-theme
Tutorials, which are Jupyter Notebooks, live in github.com/numpy/numpy-tutorials. These are built using jupyterbook/myst-nb and jupytext.
The numpy.org website, with landing page and a few informational pages, live in github.com/numpy/numpy.org

Those are all built independently, so contributions to one repo do not interfere with the others.

just to bring this back to the original point here, this isn't a referendum on react per see.

+1 @tlambert03 ... from my understanding, the current structure was implemented in early 2021 and justified by the points that @kne42 highlights above. this was before we started using React.

[@alisterburt ] napari.org is currently a mix between our docs and general project information, is separating these two things more explicitly something that has been considered?

I think that this is definitely worth considering. personally, I like the way that numpy handles the separation of concerns here.

There should be no problem with swapping out the theme for another theme

I'm not sure that I agree with this, but if it is going to be a requirement it narrows the solution space immensely and is probably the most important decision to be made here.

one benefit of shipping the theme as a pip-installable sphinx theme: plugin devs could us it on their own documentation sites for a consistent look-and-feel with the napari ecosystem

Yep, I agree, it does narrow the solution space, at least for now.  But in my opinion, the broad solution space has not worked well for us, for quite a long time now; we've been experimenting with this pattern for over a year, there's been plenty of time to iterate, and it's still causing routine difficulties.  I'd like to see us form a solid working system before we start thinking about big plans.  It may mean a small step backwards in scope for a little while, but that's what I'm proposing.  After we get a solid system, we can discuss how dependent on the theme we want to be.  As I mentioned above after the bit you quoted

save, perhaps, a few special theme-specific features like a calendar, but those too should come with a theme directive or something that gets used in the markdown file

That is: all themes come with custom directives and stuff like that, so it's not like i see all themes as completely interchangeable.  But those bits should be clearly delineated, and – most importantly – the theme should not be dynamically organizing the content after build-time.

The theme shouldn't change the TOC.

Furo does this too, just in Python:

https://github.com/pradyunsg/furo/search?q=furo_navigation_Tree
https://github.com/pradyunsg/furo/blob/d6b217f8bb021f137928aa30f1b41e829e87d73f/src/furo/navigation.py#L19-L87

There should be no problem with swapping out the theme for another theme (save, perhaps, a few special theme-specific features like a calendar, but those too should come with a theme directive or something that gets used in the markdown file).

This is already possible: https://github.com/napari/napari.github.io/blob/main/_config.yml#L45-L47
If you remove html_theme_path and change html_theme to a different theme, the docs will build with that theme like any other sphinx theme. If we moved forward with moving to a pip installable package, then there wouldn't be a html_theme_path

But we shouldn't depend on the theme for structure or content of the docs.

This is a good point but I'm also not sure where to draw the line in the sand for. Up to now I felt the affordances provided by the theme have been fine, but perhaps we need to find what things should be provided by the content vs the theme

If we want to go through with this, I think it would be useful to think through whether we want only some parts of the site to have multiple versions or for the whole site to be versioned. Currently, in Lia's designs, some content is versioned (e.g. API docs), while other content is not (e.g. developer guides).
I'm bringing this to attention because there are some caveats if we were to combine versioned and unversioned content. For example, it would require that the versioned and unversioned content be built in Sphinx separately and then given the appearance of a combined look by having the same theme. PyTorch does this, for example, and they achieve it by in fact hard-coding the top-level navigation into the sidebar.
Another issue that arises is that as the theme gets updated, previous builds of versioned docs can look out of place since they use the old theme. This happens if the full site is versioned too, but is more obvious when navigating a site where clicking on a link might bring you to a completely differently styled page.
I asked Eric Holscher, co-founder of Read The Docs, on how they addressed this and the following was his response:

There's a few ways to handle it, but generally you need to rebuild all the versions if your theme has changed in some way. This can be done in a couple ways: the theme can be specified in a requirements file without a pinned version, the theme can be a submodule, or you can have some logic in your conf.py to update the theme to a defined version.

Overall, if we want to keep things simple, I would recommend versioning the full site because otherwise you run into other conundrums such as how to handle searching between versions from an unversioned page, linking to a versioned page from an unversioned page, etc.

I'm all for a full versioning... it's simpler, and most of the dev guides are being co-written along with a developing code base.  There'd be no need, for example, to show the current plugin or event reference docs with < v0.4.

Maybe dev guides was a bad example – I was referring more to things such as Mission & Values, How to Contribute, etc.

i feel like versioning those is relatively harmless, compared to the gain in simplicity.  It's even kind of nice to be able to see how these things evolve over time.  The vast majority of people will see the current release, and as long as we have the standard "you're looking at old docs" notice for those who aren't, it seems ok to me?

The docs working group met to today to discuss this proposal. In attendance was @jni @tlambert03 @codemonkey800 @DragaDoncila @chili-chiu @nclack @dgmccart and @tdimino
To summarize:

A desirable goal is a pip installable package that comes pre-bundled with all of the javascript libraries it needs and doesn't require a local node environment to render the site.

Another goal is to improve the overall look and feel of the typography on the website - see https://github.com/napari/napari.github.io/issues/320 for specific details. We could either make changes to our current theme or match the look and feel we want by extending a sphinx theme like furo or sphinx-pydata.

The estimate for making these changes to the current theme (both pip install + typography) was ~4 to 6 weeks (though that is just an initial guess).
It has also been proposed that we could switch right away to using pydata or furo and begin modifying them. We could spend ~1 week making css changes so the color scheme matches what we have now and the transition is less of a jolt to users. We could then decide if we wanted to continue extending this theme or return to our more custom theme subject to the goals above.
@neuromusic @melissawm @GenevieveBuckley @liaprins-czi were unable to attend today, but we want to make sure to get your input here too.
cc @napari/core-devs as this is an important decision

@jni @tlambert03 @sofroniewn should the theme live in it's own repo napari/napari-sphinx-theme or be in the same repo as the docs? having it in the same repo would make some aspects of development simpler, but we can work around it otherwise if separate repos is preferred

I think the pip-installable theme is the best way to go :+1: There is still the question of image hosting and docs source location. I added a comment to explain what adopting git-lfs would mean for napari here: https://github.com/napari/napari/issues/3529#issuecomment-1017904329

As a path forward, discussed with @sofroniewn @justinelarsen & @jni ... propose the following...

Move forward to implement a new sphinx theme that will live in napari/napari-sphinx-theme that will implement the aspects of the current designs for napari.org that are meeting the needs of the community. We suspect the best path forward will be to start with a hard fork of furo or pydata as necessary for reasonable defaults where we haven't explicitly implemented custom designs (e.g. API docs).
While (1) is in development, to unblock community contribution to the docs, we'll rollback the designs to furo (with modifications of the color, etc as necessary) and work toward reorganizing the documentation infrastructure to be consistent with norms for python documentation (e.g. make docs, pip-installable theme, etc)

There was further discussion of this topic at the community meeting today with @melissawm @DragaDoncila @liaprins-czi @codemonkey800 present too and weighing in.
It was agreed that there would be high-value in @codemonkey800 exploring a hard-fork of furo and how to bring that inline with the overall look and feel of the designs of @liaprins-czi while preserving the defaults for the API reference etc that we didn't do custom designs for. This work can be done in the newly created https://github.com/napari/napari-sphinx-theme repo. @liaprins-czi can work with @codemonkey800 to determine how best to make her design implementable with furo.
One advantage of this approach that @jni has called out is that it will allow us to get to the level of customization that we want gradually, which will make it easier to review changes, and easier for other folks in the community who want to customize their furo themes to see how we did made certain changes if they want to do them too.
If we realize that there are essential features of the design we won't be able to achieve building off furo then we can decide if we want to adopt what we are able to do with furo only as a stop-gap measure and build a custom pip installable sphinx theme ourselves

I've created an issue to track the development of the new sphinx theme at napari/napari-sphinx-theme: https://github.com/napari/napari-sphinx-theme/issues/1
This includes a link to a Product Spec for the new sphinx theme. The Tech Spec is in progress & we'll review both at tomorrow's Documentation Working Group meeting, but feel free to review and weigh in on the docs or issue!

Thanks @neuromusic and everyone ... feels like we could probably close this issue now?  we've got enough other conversations and goal posts going on at this point.  If anyone wants to reopen that's fine.

Thanks for kicking off this convo @tlambert03!


Fixed private key link to backup page.

Fixed private key link to backup page. As reported by @qlpqlp here https://github.com/dogecoinfoundation/dogecoin.com/issues/138.

Much Thanks MishaBoar.  I actually fixed that issue and many more that I also found on my PR https://github.com/dogecoinfoundation/dogecoin.com/pull/140

Can I close this PR @MishaBoar  because was on the previous PR that I changed now to the new https://github.com/dogecoinfoundation/dogecoin.com/pull/146 ?


[BUG] - Skeleton Animation Not Working

NextUI Version
^2.4.2
Describe the bug
I'm having trouble getting the Skeleton animation to work.
Install NextUI and framer-motion dependencies.
Add the Skeleton component as shown in the code upper.
Observe that the Skeleton animation does not appear.

Expected behavior
As a user, I expected the Skeleton component to show a loading animation.
Screenshots or Videos
https://github.com/user-attachments/assets/9b7d56fa-228d-438d-a72e-ca7c00c9ad8e
Operating System Version
OS: macOS 14.5 (Apple M3 Pro)
Browser
Other (add additonal context)

@ahmetenesdur  I used the same code but I could not reproduce the bug.
Kindly provide some Minimal reproducible Enviroment like CodeSandBox or StackBlitz

Hi @abhinandan-verma,
While preparing a CodeSandbox, I found the issue in my setup. It was related to the backgroundImage setting in my tailwind.config.js. I moved the backgroundImage configuration to styles/globals.css and that resolved the problem.
Here are the changes I made:
tailwind.config.js:
import { nextui } from "@nextui-org/theme";

/** @type {import('tailwindcss').Config} */
module.exports = {
	content: [
		"./components/**/*.{js,ts,jsx,tsx,mdx}",
		"./app/**/*.{js,ts,jsx,tsx,mdx}",
		"./node_modules/@nextui-org/theme/dist/**/*.{js,ts,jsx,tsx}",
	],
	theme: {
		// Removed backgroundImage setting
		// backgroundImage: {
		// 	"brand-pattern":
		// 		"url('/img/background-pattern.svg'), linear-gradient(90deg, rgb(17, 178, 186) 0%, rgb(17, 178, 186) 100%)",
		// },
	},
	darkMode: "class",
	plugins: [nextui()],
};

styles/globals.css:
@tailwind base;
@tailwind components;
@tailwind utilities;

@layer utilities {
	.brand-pattern {
		background-image: url("/img/background-pattern.svg"),
			linear-gradient(90deg, rgb(17, 178, 186) 0%, rgb(17, 178, 186) 100%);
	}
}

Thanks for your assistance and sorry for the confusion!


ENH warnings for inconsistent models

We agreed that CCL should throw warnings when the models are not consistent. This issue is a start at listing all of the ways the models in CCL are inconsistent.

[x] halofit is not consistent with the modified growth cosmologies (both dfg and mu-Sigma)
[x] the growth function is not consistent for cosmologies with neutrinos
[x] the BCM model is not consistent with the mass function models
[x] the BCM model is not consistent with the halo concentration models
[x] the BCM model is not consistent with the halo bias parametrizations
[x] neutrino cosmologies are broadly inconsistent with the mass function models
[x] neutrino cosmologies are broadly inconsistent with the halo concentration models
[x] neutrino cosmologies are broadly inconsistent with the halo bias models
[x] neutrino cosmologies are not consistent with the BCM model
[x] neutrino cosmologies are not consistent with any of the modified growth models
[ ] non-flat models are not consistent with some of the projected statistic computations (see the CCL note)
[x] none of the linear power spectra we have are consistent with the effective linear power spectrum assumed by the emulator at high-precision

@joezuntz @slosar for viz

here is what this is going to look like:
In [4]: c = pyccl.Cosmology(Omega_c=0.25, Omega_b=0.05, n_s=0.9, sigma8=0.8, Omega_k=0, h=0.7, m_nu=0.1)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:379: CCLWarning: All of the halo mass function models in CCL are not properly calibrated for cosmological models with massive neutrinos!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:383: CCLWarning: All of the halo bias models in CCL are not properly calibrated for cosmological models with massive neutrinos!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:387: CCLWarning: All of the halo concentration models in CCL are not properly calibrated for cosmological models with massive neutrinos!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:391: CCLWarning: CCL does not properly compute the linear growth rate in cosmological models with massive neutrinos!
  category=CCLWarning)

In [5]: c = pyccl.Cosmology(Omega_c=0.25, Omega_b=0.05, n_s=0.9, sigma8=0.8, Omega_k=0, h=0.7, m_nu=0.1, mu_0=0.1)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:379: CCLWarning: All of the halo mass function models in CCL are not properly calibrated for cosmological models with massive neutrinos!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:383: CCLWarning: All of the halo bias models in CCL are not properly calibrated for cosmological models with massive neutrinos!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:387: CCLWarning: All of the halo concentration models in CCL are not properly calibrated for cosmological models with massive neutrinos!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:391: CCLWarning: CCL does not properly compute the linear growth rate in cosmological models with massive neutrinos!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:414: CCLWarning: mu-Sigma modified cosmologies cannot be consistently combined with cosmological models with massive neutrinos in CCL!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:430: CCLWarning: mu-Sigma modified cosmologies cannot be consistently combined with HALOFIT when computing the non-linear power spectrum!
  category=CCLWarning)

Another set of warnings that might be useful is to flag (LCDM) cosmologies outside of the range that halofit was calibrated for. Similarly, CLASS and CAMB probably have a parameter ranges where they can guarantee accurate results but make no guarantees outside of that.

Sounds good. I will add them to the list above!

Well, this is nasty, I agree. But can't we implement something like Jarvis suggested on slack?

Yup!

Hmmmm @joezuntz. On my machine they print each time.
(anl) localhost:~ Matt$ ipy
Python 3.6.7 | packaged by conda-forge | (default, Jul  2 2019, 02:07:37)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.8.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import pyccl

In [2]: c = pyccl.Cosmology(Omega_c=0.25, Omega_b=0.05, n_s=0.9, sigma8=0.8, Omega_k=0, h=0.7, m_nu=0.1, mu_0=0.1, baryons_power_spectrum='bcm')

In [3]: pyccl.growth_factor(c, 0.7)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:752: CCLWarning: CCL does not properly compute the linear growth rate in cosmological models with massive neutrinos!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:767: CCLWarning: Modified growth rates via the mu-Sigma model cannot be consistently combined with cosmological models with massive neutrinos in CCL!
  category=CCLWarning)
Out[3]: 0.7971218865156218

In [4]: pyccl.growth_factor(c, 0.7)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:752: CCLWarning: CCL does not properly compute the linear growth rate in cosmological models with massive neutrinos!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:767: CCLWarning: Modified growth rates via the mu-Sigma model cannot be consistently combined with cosmological models with massive neutrinos in CCL!
  category=CCLWarning)
Out[4]: 0.7971218865156218

In [5]: pyccl.growth_factor(c, 0.7)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:752: CCLWarning: CCL does not properly compute the linear growth rate in cosmological models with massive neutrinos!
  category=CCLWarning)
/Users/Matt/miniconda3/envs/anl/lib/python3.6/site-packages/pyccl/core.py:767: CCLWarning: Modified growth rates via the mu-Sigma model cannot be consistently combined with cosmological models with massive neutrinos in CCL!
  category=CCLWarning)
Out[5]: 0.7971218865156218

I agree on reading the docs that it should print once. IDK why this is not working.

Wow ok. Apparently in ipython the warning registry attached to globals gets reset?
(anl) localhost:Desktop Matt$ ipy
Python 3.6.7 | packaged by conda-forge | (default, Jul  2 2019, 02:07:37)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.8.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import pyccl

In [2]: c = pyccl.Cosmology(Omega_c=0.25, Omega_b=0.05, n_s=0.9, sigma8=0.8, Omega_k=0, h=0.7, m_nu=0.1, mu_0=0.1, baryons_power_spectrum='bcm')

In [3]: pyccl.growth_factor(c, 0.7)
/Users/Matt/Desktop/CCL/pyccl/core.py:752: CCLWarning: CCL does not properly compute the linear growth rate in cosmological models with massive neutrinos!
  category=CCLWarning)
{'version': 1418, ('CCL does not properly compute the linear growth rate in cosmological models with massive neutrinos!', <class 'pyccl.errors.CCLWarning'>, 752): True}
/Users/Matt/Desktop/CCL/pyccl/core.py:768: CCLWarning: Modified growth rates via the mu-Sigma model cannot be consistently combined with cosmological models with massive neutrinos in CCL!
  category=CCLWarning)
Out[3]: 0.7971218865156218

In [4]: globals().get('__warningregistry__')

In [5]:

Given that more than one Cosmology class may be in use, we might want to use warn explicit to maintain our own warnings registry. It is just so ugly...

Well a custom registry won't work because ipython resets the warnings filters on each cell execution. :/

This is really weird behaviour for ipython. I guess it's because you can overwrite old cells and so could miss a warning if it only appears once.  But still seems odd.   Writing our own registry seems like major overkill.  So if no other solution presents itself I guess we could just put warnings in the documentation somewhere?

I think actually we want our own registry anyways. Basically the warnings should reprint for each cosmology object. So we want one attached to the object instead of in globals.
I have a simple work around that is not terribly complicated. I’ll push it and tag you.

Alright the PR for this as-is is the best we can do. It will repeat warnings in ipython due to ipython, not the code itself. These can OFC be turned off completely so that will be fine.


The "Reshare" button is not responding quickly.

The "Reshare" button of unconfirmed share in "My Keepers"  is not responding quickly.

Verified this issue on dev app v1.8.0(321)


HBASE-22410 add the notion of the expected # of servers for non-fixed server sets; report an alternative dead server metric 01

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
22
Docker mode activated.

_ Prechecks _

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

-0
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ master Compile Tests _

0
mvndep
24
Maven dependency ordering for branch

+1
mvninstall
239
master passed

+1
compile
84
master passed

+1
checkstyle
92
master passed

+1
shadedjars
259
branch has no errors when building our shaded downstream artifacts.

+1
findbugs
266
master passed

+1
javadoc
63
master passed

_ Patch Compile Tests _

0
mvndep
15
Maven dependency ordering for patch

+1
mvninstall
234
the patch passed

+1
compile
87
the patch passed

+1
javac
87
the patch passed

+1
checkstyle
91
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
255
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
507
Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0.

+1
findbugs
299
the patch passed

+1
javadoc
59
the patch passed

_ Other Tests _

+1
unit
30
hbase-hadoop-compat in the patch passed.

+1
unit
31
hbase-hadoop2-compat in the patch passed.

+1
unit
8093
hbase-server in the patch passed.

+1
asflicense
62
The patch does not generate ASF License warnings.

10922

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/238

Optional Tests
dupname  asflicense  javac  javadoc  unit  findbugs  shadedjars  hadoopcheck  hbaseanti  checkstyle  compile

uname
Linux 359eeaf29a13 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 GNU/Linux

Build tool
maven

Personality
/testptch/patchprocess/precommit/personality/provided.sh

git revision
master /<PHONE_NUMBER>

maven
version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z)

Default Java
1.8.0_181

findbugs
v3.1.11

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/1/testReport/

Max. process+thread count
4442 (vs. ulimit of 10000)

modules
C: hbase-hadoop-compat hbase-hadoop2-compat hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/1/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
177
Docker mode activated.

_ Prechecks _

+1
hbaseanti
0
Patch does not have any anti-patterns.

+1
@author
0
The patch does not contain any @author tags.

-0
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ master Compile Tests _

0
mvndep
31
Maven dependency ordering for branch

+1
mvninstall
314
master passed

+1
compile
105
master passed

+1
checkstyle
109
master passed

+1
shadedjars
339
branch has no errors when building our shaded downstream artifacts.

+1
findbugs
285
master passed

+1
javadoc
75
master passed

_ Patch Compile Tests _

0
mvndep
17
Maven dependency ordering for patch

+1
mvninstall
303
the patch passed

+1
compile
106
the patch passed

+1
javac
106
the patch passed

+1
checkstyle
108
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedjars
335
patch has no errors when building our shaded downstream artifacts.

+1
hadoopcheck
928
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1
findbugs
356
the patch passed

+1
javadoc
75
the patch passed

_ Other Tests _

+1
unit
34
hbase-hadoop-compat in the patch passed.

+1
unit
41
hbase-hadoop2-compat in the patch passed.

-1
unit
17808
hbase-server in the patch failed.

+1
asflicense
76
The patch does not generate ASF License warnings.

22035

Reason
Tests

Failed junit tests
hadoop.hbase.master.TestSplitWALManager

hadoop.hbase.client.TestFromClientSide3

hadoop.hbase.client.TestSnapshotTemporaryDirectoryWithRegionReplicas

hadoop.hbase.master.TestAssignmentManagerMetrics

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/238

Optional Tests
dupname  asflicense  javac  javadoc  unit  findbugs  shadedjars  hadoopcheck  hbaseanti  checkstyle  compile

uname
Linux f7ffdeee99db 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 GNU/Linux

Build tool
maven

Personality
/testptch/patchprocess/precommit/personality/provided.sh

git revision
master / ada772a1d3

maven
version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z)

Default Java
1.8.0_181

findbugs
v3.1.11

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/2/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/2/testReport/

Max. process+thread count
4648 (vs. ulimit of 10000)

modules
C: hbase-hadoop-compat hbase-hadoop2-compat hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/2/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
5
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/3/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
5
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/4/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
6
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/5/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
6
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/6/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
4
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/7/console

Powered by
Apache Yetus 0.9.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
9
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/8/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
9
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/9/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
9
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/10/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
10
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/2/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
10
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/3/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
8
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/4/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
13
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/5/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
0
Docker mode activated.

-1
patch
11
https://github.com/apache/hbase/pull/238 does not apply to master. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/in-progress/precommit-patchnames for help.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hbase/pull/238

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-238/6/console

versions
git=2.7.4

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Close since the PR is stale, feel free to reopen.


S1E firmwares 2.0.8_0002支持了吗

现在支持2.0.8固件了吗，我看已经add S1E firmwares 2.0.8_0002，但是redeme里还写着不要升级

Don't use official firmware to avoid disabled telnet. Use modified firmware 2.0.8.

Don't use official firmware to avoid disabled telnet. Use modified firmware 2.0.8.

But I am currently in version 2.0.8. Can this still be upgraded to the modified version 2.0.8 in your code

Yes

thanks


OCP Prep -- https://www.opencompute.org/summit/global-summit - OCP in San Jose -- October 15-17th

What are we delivering? Is it a video demo? -- still finding out about space -- videos will do the work if we get a spot in a booth

LF discussing taking the videos and fixing them a bit.


Broken "ToC" link

The "the docs" link at https://welpo.github.io/tabi/blog/mastering-tabi-settings/#table-of-contents links to https://welpo.github.io/blog/toc/ which 404s — the correct link would be https://welpo.github.io/tabi/blog/toc/

Thank you! I didn't notice there were a few broken links. Appreciate the report.


Fix seeding functionality

Fix for small oversight in @dcposch’s recent changes. Broken when
adding the distinction between active and inactive torrents.
Please code review, @dcposch

LGTM


[SPARK-2930] clarify docs on using webhdfs with spark.yarn.access.nam…

…enodes

Test build #49148 has started for PR 10699 at commit f304363.

Test build #49148 has finished for PR 10699 at commit f304363.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/49148/
Test PASSed.

Merged build finished. Test PASSed.

Merged to master


Edited version of raylib-mruby to comply with 2.5 (Renamed to 2.4-dev)

As i said, There are functions from raylib 2.5, I assume it's better to rename it to 2.4-dev instead of 2.4

@Rabios Nice! Thanks for caring for that detail!


ImportError: cannot import name 'soft_unicode' from 'markupsafe'

ImportError: cannot import name 'soft_unicode' from 'markupsafe'
Above error in tryng out example. Solution is mentioned below.
https://stackoverflow.com/questions/72191560/importerror-cannot-import-name-soft-unicode-from-markupsafe

The solution in the link above does not work for me. When I follow the solution in the link above, and install markupsafe 2.0.1, I get another error:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
werkzeug 2.2.0 requires MarkupSafe>=2.1.1, but you have markupsafe 2.0.1 which is incompatible.

When I try earlier versions of wekzeug, I get other errors.


Government user history

#439
Added user activity in the Admin tab.
Changelog:

Added User Activity
Updated some fixtures
Added additional tabs for Admin
User Activity for government covers all users for the government as opposed to just one person

Seeing a test failure. I think that some of the checks in test_credit_trade_history.py are selecting too generally (it's  picking up a trade history with status id 4 and failing, since it's asserting that a user with id 4 does not exist in the response).

Updated the test. It shouldn't have hardcoded values. It does use the variables set in the base_test_class

 History | Add Government User History to Administration Page |5|


Add Facebook support

#tutorial
https://www.youtube.com/watch?v=MNfrBdyEvmY

@adriaanbalt I believe you're opening these on the wrong repo

So sorry 🙈

On Mar 19, 2019, at 8:59 PM, Robert Payne<EMAIL_ADDRESS>wrote:
Closed #576.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


feat(leap): add performance article

To make the links work, this should  be merged after #759
To make the image work, https://github.com/exercism/images/pull/24 should be merged beforehand. :heavy_check_mark:

Hej!
When I ran the tests on my computer I got significantly different results:

I compiled with GCC-13.2.0 and -O3
I ran cpupower frequency-set --governor performance to avoid any interference from the processor
I ran benchmark_leap --benchmark_repetitions=100

On my computer (with a AMD Ryzen 1920X) I got these results (slightly shortened):
BM_Leap_boolean_chain_mean                 1925 ns         1924 ns          100
BM_Leap_boolean_chain_median               1952 ns         1952 ns          100
BM_Leap_boolean_chain_stddev               37.9 ns         37.9 ns          100
BM_Leap_boolean_chain_cv                   1.97 %          1.97 %           100
BM_Leap_boolean_chain_inverse_mean         1213 ns         1213 ns          100
BM_Leap_boolean_chain_inverse_median       1210 ns         1210 ns          100
BM_Leap_boolean_chain_inverse_stddev       20.2 ns         20.2 ns          100
BM_Leap_boolean_chain_inverse_cv           1.67 %          1.67 %           100
BM_Leap_ternary_mean                        976 ns          976 ns          100
BM_Leap_ternary_median                      968 ns          968 ns          100
BM_Leap_ternary_stddev                     19.6 ns         19.6 ns          100
BM_Leap_ternary_cv                         2.01 %          2.01 %           100
BM_Leap_chrono_mean                         949 ns          949 ns          100
BM_Leap_chrono_median                       947 ns          947 ns          100
BM_Leap_chrono_stddev                      7.14 ns         7.11 ns          100
BM_Leap_chrono_cv                          0.75 %          0.75 %           100
BM_Leap_boost_mean                         1685 ns         1685 ns          100
BM_Leap_boost_median                       1683 ns         1683 ns          100
BM_Leap_boost_stddev                       9.90 ns         9.93 ns          100
BM_Leap_boost_cv                           0.59 %          0.59 %           100
BM_empty_read_mean                        0.000 ns        0.000 ns          100
BM_empty_read_median                      0.000 ns        0.000 ns          100
BM_empty_read_stddev                      0.000 ns        0.000 ns          100
BM_empty_read_cv                           1.78 %          1.20 %           100

It looks like "boolean_chain" is among the slowest approaches, "boolean_chain_inverse" is significantly faster but "ternary" beats both. That's surprising. Or am I misinterpreting the numbers?

BM_Leap_boolean_chain_median                   1952 ns
BM_Leap_boolean_chain_inverse_mean         1213 ns

That is strange. I used  g++ leap_benchmark.cpp -std=c++20 -isystem benchmark/include  -Lbenchmark/build/src -lbenchmark -lpthread -o leap_benchmark, compiled with g++ version 14.10.0. So the article's values are without -O3.
I can't change my CPU to performance, as the VM does not support it, but that should not change things so drastically. I reran the tests many times and always got those results. Even with -O3.
Another go:
❯ gcc leap_benchmark.cpp -std=gnu++2a -O3 -isystem benchmark/include  -Lbenchmark/build/src -lbenchmark -lpthread -o leap_benchmark -lstdc++ -lm
❯ ./leap_benchmark --benchmark_report_aggregates_only=true --benchmark_repetitions=10
BM_Leap_boolean_chain_mean                  937 ns          937 ns           10
BM_Leap_boolean_chain_median                937 ns          937 ns           10
BM_Leap_boolean_chain_stddev               4.00 ns         4.01 ns           10
BM_Leap_boolean_chain_cv                   0.43 %          0.43 %            10
BM_Leap_boolean_chain_inverse_mean         1334 ns         1334 ns           10
BM_Leap_boolean_chain_inverse_median       1333 ns         1333 ns           10
BM_Leap_boolean_chain_inverse_stddev       3.36 ns         3.32 ns           10
BM_Leap_boolean_chain_inverse_cv           0.25 %          0.25 %            10
BM_Leap_ternary_mean                       1060 ns         1060 ns           10
BM_Leap_ternary_median                     1062 ns         1061 ns           10
BM_Leap_ternary_stddev                     2.95 ns         2.90 ns           10
BM_Leap_ternary_cv                         0.28 %          0.27 %            10
BM_Leap_chrono_mean                        1144 ns         1144 ns           10
BM_Leap_chrono_median                      1143 ns         1143 ns           10
BM_Leap_chrono_stddev                      4.75 ns         4.75 ns           10
BM_Leap_chrono_cv                          0.42 %          0.42 %            10
BM_Leap_boost_mean                         1018 ns         1018 ns           10
BM_Leap_boost_median                       1018 ns         1018 ns           10
BM_Leap_boost_stddev                       2.51 ns         2.45 ns           10
BM_Leap_boost_cv                           0.25 %          0.24 %            10
BM_empty_read_mean                        0.614 ns        0.614 ns           10
BM_empty_read_median                      0.614 ns        0.614 ns           10
BM_empty_read_stddev                      0.001 ns        0.001 ns           10
BM_empty_read_cv                           0.13 %          0.12 %            10
```text

Finally managed to run benchmarks on my old, slow computer 😉
$ ./leap_benchmark --benchmark_report_aggregates_only=true --benchmark_repetitions=10
2024-01-11T07:30:31-05:00
Running ./leap_benchmark
Run on (4 X 2712 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 3072 KiB (x1)
Load Average: 0.85, 0.63, 0.62
-------------------------------------------------------------------------------
Benchmark                                     Time             CPU   Iterations
-------------------------------------------------------------------------------
BM_Leap_boolean_chain_mean                17235 ns        17235 ns           10
BM_Leap_boolean_chain_median              17157 ns        17157 ns           10
BM_Leap_boolean_chain_stddev                193 ns          193 ns           10
BM_Leap_boolean_chain_cv                   1.12 %          1.12 %            10
BM_Leap_boolean_chain_inverse_mean        35652 ns        35652 ns           10
BM_Leap_boolean_chain_inverse_median      34359 ns        34359 ns           10
BM_Leap_boolean_chain_inverse_stddev       2747 ns         2747 ns           10
BM_Leap_boolean_chain_inverse_cv           7.70 %          7.70 %            10
BM_Leap_ternary_mean                      21083 ns        21084 ns           10
BM_Leap_ternary_median                    20425 ns        20425 ns           10
BM_Leap_ternary_stddev                     1350 ns         1350 ns           10
BM_Leap_ternary_cv                         6.40 %          6.40 %            10
BM_Leap_chrono_mean                       20505 ns        20506 ns           10
BM_Leap_chrono_median                     19862 ns        19863 ns           10
BM_Leap_chrono_stddev                      1577 ns         1577 ns           10
BM_Leap_chrono_cv                          7.69 %          7.69 %            10
BM_Leap_boost_mean                        36426 ns        36427 ns           10
BM_Leap_boost_median                      35927 ns        35927 ns           10
BM_Leap_boost_stddev                        824 ns          824 ns           10
BM_Leap_boost_cv                           2.26 %          2.26 %            10
BM_empty_read_mean                         1834 ns         1834 ns           10
BM_empty_read_median                       1833 ns         1833 ns           10
BM_empty_read_stddev                       5.73 ns         5.71 ns           10
BM_empty_read_cv                           0.31 %          0.31 %            10

Looks like on my computer, boost is much slower than chrono, which differs from @vaeng's results. Aside from that it seems to be similar (slower but proportional).

@clechasseur at least chain and inverse chain are in a "sensible" order.
What do you and @siebenschlaefer  think?  Should I add or edit some of the article, or let it stand as it is for my machine?

@ErikSchierboom have you had diverging benchmarks for an approach article before?

When I read the different approach documents for the Leap exercise, I wondered whether results could vary depending on how the CPU handles pipelining. The "inverse chain" is an example; on paper, it looks worse because the edge case is checked fist. But what if instructions are reordered in some way? I am wondering whether @siebenschlaefer's results can be explained by the fact that they're using an AMD processor (I am on Intel).
I will also admit to not being a fan of such very low-level optimizations in general. Optimizing a method to determine if a year is a leap year seems a bit extreme: is that really the performance bottleneck of your program? Let's say that it's true that the ternary approach is 27% slower; it's 27% of such an infinitesimal amount of time, does it really matter? But I will leave it to you to determine whether the article should be posted: in itself, it seems fine.

AMD processor (I am on Intel)

My results are AMD as well.

Let's say that it's true that the ternary approach is 27% slower; it's 27% of such an infinitesimal amount of time, does it really matter?

I should include that into the article.

@ErikSchierboom have you had diverging benchmarks for an approach article before?

Nope, but I've been the only one doing them on my articles :D

I think the wording in the article is a good summary of our discussion here @siebenschlaefer @ErikSchierboom.
I'd like to merge the article to see the new invert mechanism :)

Merged. Everyone feel free to do follow ups if appropriate but it's good for us to test this -invertible functionality before Tues :)


CHAIR hallucination evaluation

Hello! I encountered some problems when using code to reproduce the CHAIR metric in the paper.
When I set max new_tokens to 64, I obtained CHAIRs=19.4 and CHAIRi=6.4. This is somewhat different from the CHAIRs=14.2 and CHAIRi=5.2 in the paper. And when max_cew_tokens is set to 512, the results obtained are similar to those in the paper. In these two experiments, I only changed the max_new_tokens of the model.generate in the chair_eval. py file.(Change from 512 to 64).
Therefore, I would like to inquire about how to reproduce the result of max_new_tokens=64 in the paper. Do I need to change any other parameters or code?

Hi,
Since the model usually generate more than 64 tokens and max_new_tokens=64 may truncate the sentence. Thereby, we will discard the last sentence if it is incomplete. You are recommended to do this step when running chair_eval.py.

Thank you for your reply!


Feature/repo structure

Description: Added the repository structure
Relevant Issues:

Added PULL_REQUEST_TEMPLATE.md
Added LICENSE
Added the required folders for the repository as discussed

Methods:

Utilized ChatGPT to generate PULL_REQUEST_TEMPLATE.md
Added MIT License temporarily because it's the most common and straightforward
Added empty folders with .gitkeep to represent the structure for now

Could you also add the VCS document?

Could you also add the VCS document?

added


Add option to "remove unused imports"

Love this extension 👍
Any chance you could add an option to remove unused imports?

Took a while to get back to this project. The feature added in 3.3.0. You need to set   "importSorter.sortConfiguration.removeUnusedImports": true


Interaction Entity System

Fixes #20
Interaction system parses click on clickablecomponents within range of the attacker into attackhand, attackby, and useentity. It makes it so if you want something to have attackhand, attackby, or item use functionality you only need to add the interface and define the function.
Replaces the need for interactable component on anything that can be interacted with, and replaces the need to register attackhand, attackby, or item use on the interactable component. This would likely have been an annoyance at least and a point of failure for new coders at worst.
WIP: Primarily just need a way to hook into the clickable component so that it will know to fire the interaction system. I've tacked on some hacky add/remove event onto components that use the interactions but that is obviously far from what I wanted to do.
I also think assigning it to the delegate is somewhat silly and would rather have the interaction system get directly called but since the clickable component is in the engine I can't do that.
Also requires clicktype PR on the engine repo

Help fix shitcode, where should I put a hook into clickable to register it or tell it to use the interaction entity system

Updated submodule so this works now


WIP

I think we should rid ourselves of the global variables as well; move all those to a record and keep that with the browser instance.

Also, we should have an opt-in warning of using the global browser instance/alt opt-in crash on using it.

You mean pass in all options when you start the browser?
I moved them all to a record and made it mutable one time, and it was not that great.

Not sure how yet. I haven't looked into it; but passing around a context with that configuration is a nice way to make it thread safe.

Yes I am happy with anything that is 'more correct'.
Ultimately need two results:

Mostly backwards compat 'classic' version, people like it because its low barrier of entry and really simple/clean API, even though its not idiomatic.
Idiomatic F# + Parallel friendly version.  I don't have conventional feelings about what idiomatic F# is, so I am happy to follow community guidelines there.

If you can add travis testing it would ensure I don't inadvertently break something.

I think I have something that could work... Now it needs testing. I'm going to revert all XX functions now.

Also, it would be nice to have this running on .Net Core and perhaps even on NodeJS?

There is another WIP for .net core support, but I think its stale.
When you say node js, you mean a javascript version of the library?

Food time

Ok, that's that. Compiles again and should support passing the browser. Next up:

Bring in a Compat module that restores the globals and obsoletes them.
Write a sample with the new parallel support

I'm not going to tackle the naming yet.

To consider: making the thread sleep async in wait.fs.

What do you say about moving the test framework to another assembly to keep it lean?

You should definitely document companion.fsx — it looks sweet!

For now I would like to keep the runner part together.
You can check out companion here: https://chrome.google.com/webstore/detail/canopy-companion-css-sele/jehfnloleecojodohcdfpbhjahhaplje
It works pretty well!

Nice tool :)
A split would look like this:
Canopy.Core — what was just changed
Canopy — depends on Canopy.Core and Canopy.Runner
Canopy.Runner — the runner
That way, people who reference Canopy still get the same stuff.
I convert this to .Net Core if you let me.

Also; can I convert the naming of modules to F# standard PascalCase?

I am fine with PascalCase for everything except classic mode.
Converting to .Net core is great also.
I am not a fan of code organization through assemblies, but I will think on it.

Left to do: sort out the TODOs about global variables. Leaving for the evening. Parallel running should work now.


update to latest list of material icons (including achievements icon)

please add support for achievement icon.

i think in general the list of material icons needs an update

I don't see an "achievements" icon here. Which achievements icon are you referring to?

like this one :-)

Hm, where did you see that one? I don't see it in the material iconfont

just a simple google search , i found it on "Noun Project". I sent it to give you idea what i am talking about.

Ah I see. For anything not in the Material Icons list, you can just drag any SVG from your desktop instead of using the clipart feature.


[Feature] Include player UUID and if the message is hidden on chat box event

Describe your feature idea
Include 2 arguments with the sender UUID and if the message is hidden (prefixed with $) on the chat event of the chat box.
Describe alternatives you've considered if you've any
For getting player UUID: Connecting to an API that returns the player UUID along with other info.
For checking if message is hidden: None.
Additional context
Maybe use it like this:
local _, name, message, uuid, hidden = os.pullEvent("chat")
if hidden then
  -- do things...
end

Added in 0.7a


⚠ Bofrost.at has degraded performance

In fa2a4ea, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1158 ms

Resolved: Bofrost.at performance has improved in 9fc36b0 after 7 minutes.


Curl::setHttpHeaders passing headers in an incorrect format to curlopt

Override Curl::setHttpHeaders to pass headers with format:
[Key: value]

Today the method pass:
 [key => value]

The headers are not passed to the request this way

Solved


What is the IP adddress of the server that runs SPD worflows in Office 365.

we are using Sharepoint online, and have built number of Workflows, I am curious to see why share point Workflow  server IP  address are not posted. Where do they execute form the range given for share point in the above article is not correct.  is someone going to post that information.
Regards
Sunil

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 077406d8-bff1-496e-3ea2-b38558fd9355
Version Independent ID: 57db3dec-2250-2dee-fd1a-ec6656911798
Content: Office 365 URLs and IP address ranges
Content Source: Enterprise/urls-and-ip-address-ranges.md
Service: o365-administration
GitHub Login: @JoeDavies-MSFT
Microsoft Alias: josephd

@sunilprabha - Thank you for submitting feedback.
I will get this issue over to the Enterprise writing team for investigation.
Thank you for reporting and making the docs better. Much appreciated.
I made a note to request the team to update this when the work is complete.

@JoeDavies-MSFT - Can you please share your insights on this issue?
Thank you.
cc: @kenwith

@sunilprabha Can you tell me the URLs/FQDNs you are connecting to and the IP addresses you are seeing? Thanks

we are using Office 365 [.SharePoint.com ] , and workflows are built under that domain or subsite/list which are trying to access our Azure hosted Web API. Currently the web api is open to public in order the  share point to post data.  So I have added the above IP for SharePoint so that the API[*.azurewebsites.net] will allow the communication in firewall rules.
What is see is WF are not getting triggered form the above IP range, I get a different IP in the logs, which is owned/assigned by MS. I need the IP address so that i can make changes to the  API firewall .

@sunilprabha I have forwarded your question to the team that manages these endpoints for their comment. Thanks for your feedback.


Adding .NET Core binary serialization doc

Relates to https://github.com/dotnet/docs/issues/2770
Adding a doc which describes the differences between .NET Core and .NET Framework in regards to binary serialization.
@mairaw I haven't spent time to figure out how to add the doc into the navigation pane and what else is required. You could either tell me or commit directly into the PR here.

I can finish the PR for you. I'll put myself as the ms.author so that I'm responsible for looking at feedback, etc. but leave you as the author of the article. Is that ok?

Perfect. Thanks Maira!
cc @danmosemsft

@ViktorHofer please take a look at what I did:

updated metadata
renamed file to have important keywords
transformed the list in active links

What do you think?
Also, I can't seem to find TreeSet. Is this already available?
Thanks.

What do you think?
LGTM. Thanks for the changes. I think the active link list makes sense :)

Also, I can't seem to find TreeSet. Is this already available?
https://github.com/dotnet/corefx/blob/master/src/System.Collections/src/System/Collections/Generic/SortedDictionary.cs#L960
Maybe you can't find it because it is marked as obsolete.

Ok, this is done. As soon CI is green and things look good, I'll merge, unless I hear otherwise. Thanks!


Feature detection

This API will take time to propagate to all browsers. As web developers, we need a way to detect whether the API is available or not.
I tried this on Chrome, Firefox and Safari:
s = new Intl.Segmenter("en", {granularity: "line"})

and they all throw an error because "line" isn't a supported granularity.
So a developer could use a function like this to check for "line" support:
function isLineSegmenterSupported() {
  try {
    new Intl.Segmenter("en", {granularity: "line"})
    return true;
  } catch(_) {
    return false;
  }
}

Is this an okay way to do feature detection for this new API?

I believe that is the intended way to do so.


Trackpad not perfect on Oculus GO

First of all, CONGRATS!. What a great project!. It works really well and it's amazing the improvement compared to any other solutions out there.
I'm using v1.7 and the control of my Oculus Go is working pretty well with some number of buttons limitations (I was expecting that), but seems like the trackpad is working, but not perfectly. The click is working perfectly, but the movement with the trackpad is not. You can see what I'm saying if you start Google Earth VR and try to move around. The trackpad seems to be working up and down backwards and just one small portion on the trackpad is usuable.
Again!, congrats on the project, really looking forwad to see how far you can get it!. THANKS!

Thank you for comment!
Trackpad position was wrongly reported to SteamVR.
Now this bug is fixed.


App Crashes in [MobFoxAd loadAd] on users 32Bit Devices in iOS 9 and iOS 10

The SDK (3.5.4) causes my App to crash on 32Bit Devices.
I was able to reproduce it on an iPad 3 with iOS 9.3.5
Call Stack:

Log Output:

2018-11-03 12:50:49.117 NiceClockFB[589:18767] Setup MobFox Ad
2018-11-03 12:50:49.327 NiceClockFB[589:18767] *** -[NSKeyedUnarchiver initForReadingWithData:]: data is NULL
2018-11-03 12:50:51.560 NiceClockFB[589:18767] -[__NSArrayI stringByAddingPercentEncodingWithAllowedCharacters:]: unrecognized selector sent to instance 0x155d4260
2018-11-03 12:50:51.561 NiceClockFB[589:18767] crash logger disabled
2018-11-03 12:50:51.562 NiceClockFB[589:18767] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSArrayI stringByAddingPercentEncodingWithAllowedCharacters:]: unrecognized selector sent to instance 0x155d4260'
*** First throw call stack:
(0x21aff91b 0x2129ae17 0x21b052b5 0x21b02ee1 0x21a2e238 0x223414ff 0xfdd03 0xd162f 0xaba51 0xf18b7f 0xf228d5 0xf18b6b 0xf2c557 0xf1ab0d 0xf1d157 0x21ac1b6d 0x21ac0067 0x21a0f229 0x21a0f015 0x22fffac9 0x260e3189 0xcfeb5 0x216b7873)
libc++abi.dylib: terminating with uncaught exception of type NSException

This is a crash report of a user:
2018-11-02_16-13-07.1991_+0100-e65ae9c94196cf91d777489ab70d5f6b6e1a0102.crash.txt

Hi,
Sorry for not responding, our iOS dev was not able to get to this yet. I hope we can return with meaningful feedback tomorrow.

The error happens when a GDPR Consent is present.
You can reproduce it in your DemoAppSwift by adding the following two lines in MainViewController.swift after line 67:
mobfoxAd.gdpr = true
mobfoxAd.gdpr_consent = "BOW36lnOW36lnAhADBENB1-AAAAid7_______9______9uz_Gv_v_f__33e8__9v_l_7_-__u-33d4-_1vf99yfm1-7ftr3tp_86ues2_Xur_959__3z27EA"
I think the error happens in your consent string parsing. My CMP had the same issues on 32Bit devices. There is some hex string parsing happening which results in a int number that would take more than 32 bits.

Thank you for your feedback.
Seems we found and solved the problem. We want to verify the fix with you if possible. Can you please write which version you are using so we can do this fix on that version and send you to download link ?

Wonderful, thank you!
Sorry, forgot to mention that. I'm using the latest version (3.5.4) via CocoaPods.

Hi,
The framework (version 3.5.4S2) can be downloaded from here  http://static.starbolt.io/MobFox-iOS-SDK-3.5.4S2-binaries.zip
Following manual installation instructions (integrating framework 3.5.4S2 to project):

  For integrating static lib: Drag MobFoxSDKCore.embeddedframework from the Finder into your project.

   For dynamic lib: Drag MobFoxSDKCoreDynamic.embeddedframework from the Finder into your project. (MobFoxSDKCoreDynamic.framework must be under 'Embedded Binaries' and 'Linked Frameworks and Libraries')

The framework API information is here  https://github.com/mobfox/MobFox-iOS-SDK
If you have any more questions please let me know.

Thanks, I integrated it and tested it. The App does not crash anymore, but it also does not show a test advertisement.
When I start it on a newer device it shows a test banner ad, not on the old device under iOS 9.

Thank you the feedback, I'm happy to know that it's not crash anymore.
referring for the test Ad which is not showing, we found that Apple's JSCORE running old iOS 9,
not working with js "let" command.  We need to replace it with "var" command. We will do it remotely on our server, once done we will let you know so you can test and verify that Ad works.

We'll update the server today and update this space.

I can see ads now, thank you very much!


potential RAM memory leak for the transformer model

When training a transformer model, I observed (from the top command)  that the RAM memory increased by almost 20% after several epochs. And when I inserted the below snippet to monitor the RAM usage, and tried to inference with the 'interactive.py' file, the result given by py.memory_info()[0]'s increases despite feeding the same sentences. The total item number in gc.get_objects() doesn't change accross the setences, and I executed gc.collect() before every memReport() function.
The fconv model also has but a marginal increase, maybe about an order of magnitude smaller and slower than the transformer model.
Experiments were done on pytorch version 0.4.0 or 0.5
`By @smth
def memReport():
for obj in gc.get_objects():
if torch.is_tensor(obj):
print(type(obj), obj.size())
def cpuStats():
print(sys.version)
print(psutil.cpu_percent())
print(psutil.virtual_memory())  # physical memory usage
pid = os.getpid()
py = psutil.Process(pid)
memoryUse = py.memory_info()[0] / 2. ** 30  # memory use in GB...I think
print('memory GB:', memoryUse)
cpuStats()
memReport()`
updates: Pytorch 1.0.0 greatly alleviates this problem.

https://github.com/pytorch/pytorch/issues/13243
This PR solves the problem.


PLUTO-661 added a system property called test.browser.binary

Merged. Thank you. See code review commit https://github.com/apache/portals-pluto/commit/518089566e25805b3aa6a2572b19f3d87ffac4f2


Add redux

Hello Microverse 👋, In this PR the following is done:

[ ] Add Redux Toolkit.
[ ] Create a directory that will contain all your Redux logic (/src/redux).
[ ] Configure a Redux store (/src/redux/store.js).
[ ] Define a slice of state for books that:
[ ] Includes an array of books (initial state: empty array)
Includes a reducer that adds a book
Includes a reducer that removes a book
[ ] Define a slice of state for categories that:
[ ] Includes an array of categories (initial state: empty array)
[ ] Includes a reducer that checks the status and always returns "Under construction" (the initial state should check to that string)
[ ] Structure application files using a "feature folder" approach and, the ducks pattern for Redux files.

Thank you! @TedLivist


Simplify delegation model for static table and picker views

Custom table and picker view delegates are currently required to call back into the source view for information about static content. However, this approach relies on overrides of UIKit view methods such as numberOfSections, numberOfRowsInSection:, and cellForRowAtIndexPath:, which already have established and documented semantics. The redefined behavior may not always reflect the original intent, which can lead to bugs.
A better approach would be to allow a custom data source or delegate to call directly into the respective protocol implementations provided by LMTableView and LMPickerView. This way, the view methods do not need to be overridden, allowing them to retain their original behaviors. To accomplish this, LMTableView and LMPickerView simply need to make their delegate methods public so they can be accessed by a custom implementation.
To avoid the need for casting, the Markup categories on UITableView and UIPickerView will implement their respective data source and delegate protocols. Default (no-op) implementations will be provided for required methods. The existing implementations in LMTableView and LMPickerView will remain unchanged.
This will result in a much cleaner and deterministic delegation model. However, it will not be backwards-compatible. All custom data source and delegate implementations will need to be updated to call into the delegate methods rather than the view methods. Source code templates will also need to be updated to reflect the new model, as will the documentation.
Note that templates will now need to include an implementation for tableView(_:viewForHeaderInSection:) and tableView(_:viewForFooterInSection:). These methods were previously handled exclusively by LMTableView but now must be implemented by the custom delegate.
Because this is a significant and breaking change, it may make sense to increment the major version number (from 2 to 3).

This has been implemented but has not been fully tested or documented yet. Templates also have not been updated.

The table view code template has been updated. See issue #81.

This is done. Table view controllers that provide custom content or behavior for LMTableView instances should be updated to extend LMTableViewController and delegate to the base class as needed. For example:
override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    let n: Int
    if (tableView.name(forSection: section) == "dynamic") {
        n = ...
    } else {
        n = super.tableView(tableView, numberOfRowsInSection: section)
    }

    return n
}

override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let cell: UITableViewCell
    if (tableView.name(forSection: indexPath.section) == "dynamic") {
        cell = ...
    } else {
        cell = super.tableView(tableView, cellForRowAt: indexPath)
    }

    return cell
}

override func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    if (tableView.name(forSection: indexPath.section) == "dynamic") {
        ...
    } else {
        super.tableView(tableView, didSelectRowAt: indexPath)
    }
}

Additionally, controllers that provided custom content or behavior for LMPickerView instances should be updated to delegate to the picker view as shown below:
func numberOfComponents(in pickerView: UIPickerView) -> Int {
    return pickerView.numberOfComponents(in: pickerView)
}

func pickerView(_ pickerView: UIPickerView, numberOfRowsInComponent component: Int) -> Int {
    let n: Int
    if (pickerView.name(forComponent: component) == "dynamic") {
        n = ...
    } else {
        n = pickerView.pickerView(pickerView, numberOfRowsInComponent: component)
    }

    return n
}

func pickerView(_ pickerView: UIPickerView, titleForRow row: Int, forComponent component: Int) -> String? {
    let title: String
    if (pickerView.name(forComponent: component) == "dynamic") {
        title = ...
    } else {
        title = pickerView.title(forRow: row, forComponent:component)!
    }

    return title
}


Handle multi-streams files gracefully

I noticed a tricky case that may be related to #13: when a file contains several streams (for example if it was created with pxz, a parallel compressor).
From what I understand, to handle such a case, it is possible to do the following:

open the file
loop:

keep the current offset in the file (let call it offset_before)
create a XzDecoder for the current xz stream
loop to decompress this stream by calling read
if it ends with an error and if some bytes were read for this stream, then try to move to the start of the next stream by seeking in the file to offset_before + total_in() and skipping all the null bytes (optional stream padding). If there is an error but no byte was read, then it is really an error and we stop everything here.

I think it would be better if the case of the multi-stream files was transparently handled by XzDecoder.
edit: In fact, now I think it would be mandatory for non-seekable files (like Unix pipes)

Interesting! This sort of sounds like the MultiGzDecoder in flate2 where gz streams can be concatenated to create one file that actually has a few inside of it. I think it'd definitely be ok to add a dedicated struct for handling this case!

Sorry for the late reply. I don't get what would be the advantage of creating three new structs (related to bufread::XzDecoder, read::XzDecoder and write::XzDecoder) compared to adding builder methods (with distinct flags for the liblzma decoder) to the existing structs. In MultiGzDecoder, there is specific code to manage the multiple streams, but for xz everything is managed by liblzma.
I did create new structs, but in the end it means that the functions (for Read and Write) will have to be implemented, and either they will contain the same code than the single-stream ones, or they will forward to new shared structs/functions.
(I'm not familiar with how modules and types should be organized in Rust, I'm more familiar with Java/C++/Python; also, it's not a blocker for any project I have, I'm just playing a bit with Rust)

Oh ok sure yeah that makes sense. I think so long as it's an opt-in I'm down for that, if it's with a new type or just a flag that sounds fine.

Has evolved into pull request #31, following the two last comments.


[FEATURE] quiz | the "next question" button - modifications

I know it just the design of the button is always at the right bottom that's what people are used of in this case it is a "next" button .So i think that we can add the "show answer " button on that side for an optimal user experience .

Originally posted by @ZizouX0 in https://github.com/thecyberworld/TheCyberHUB/issues/632#issuecomment-2082117842
The "nextQuestion" button is on top.

change the text to "next question"
let's discuss if to leave it on top or move it to under the possible answers in the bottom.

@kabir0x23 what do you think?

hello @ArkadiK94 , assign me to this issue

@AhmedKarray005 it is in discussion phase.
@kabir0x23 what do you think? should we implement it?

@kabir0x23 ????

yes, good idea

@ZizouX0 Thanks for the idea.
@AhmedKarray005 I will assign you.

@ArkadiK94 you want the button under the possible answers in the bottom.

@AhmedKarray005 yes

@ArkadiK94

@AhmedKarray005 Looks great 👍

looks good

@AhmedKarray005 did you created pr for this issue?

@ArkadiK94 yes


report command: Rename --format flag to --output

The timetrace report command has a flag called --format for specifying the output format, e. g. JSON.
However, since #114, the timetrace status command has a --format flag for specifying a custom output format and uses a flag called --output for specifying JSON as output format.
How it is

Command
Flag
Description

status
--output
Output format, e.g. JSON

status
--format
Custom format

report
--format
Output format, e.g. JSON

This should be changed: The --format flag of report should be renamed to --output so that it serves the same purpose as the status --output flag.
How it should be

Command
Flag
Description

status
--output
Output format, e.g. JSON

status
--format
Custom format

report
--output
Output format, e.g. JSON

Don't forget to update the documentation accordingly! 😄

@KonstantinGasser Sorry for not making this clear when you worked on the report feature, but we had to find a name for the status --output flag first.

Oh I see - yes makes senes to keep the logic the same way. Sure, I will change that and create a PR 😄. That also means that the report command does not need a --format flag. The --out flag for the output file name however can stay the same?

The --out flag for the output file name however can stay the same?

I'm afraid that an --output flag with a coexisting --out flag will be a bit confusing, but I don't know a better name 🤔

how about a --file flag to specify the output file?

@dominikbraun I opened a PR with the aligned naming convention.

how about a --file flag to specify the output file?

I also thought about --file or --path. Feel free to pick the one you prefer if you want to :-)

Closed by #138.