Sunsetting Louketo Project

Sunsetting Louketo Project
After careful consideration, we have decided to pull the plug on Louketo and start the EOL procedure. The plan is during the next 3 months to fix only critical bugs and security issues. Everyone interested in capabilities provided by Louketo Proxy should look at OAuth2 Proxy project which is providing a similar set of capabilities and has a healthy and active community.
A few months ago, the Keycloak team started Louketo — a joint effort to build a generic OAuth2 Proxy and possibly also begin an umbrella project for a set of OIDC related integration libraries. The initial set of goals has not worked out. Keycloak Gatekeeper and OAuth2 Proxy projects hoped to merge and join efforts but for various reasons, this has not worked out.
With Louketo and OAuth2 proxy providing similar features, OAuth Proxy being a more popular project with a bigger community we reached a conclusion there's no reason to put more effort into Louketo, when we can just contribute there.
What does it mean in practice?
FAQ
Will Louketo Proxy be no longer maintained? Will there be no new releases?
Critical bug fixes will be merged and micro releases provided for the next 3 months. It is up to community members to step up and take over maintaining and driving this project further if they wish to do so. Please contact the Keycloak developers on the dev mailing list or add your comments here.
Are there any alternatives I should use instead?
OAuth2 Proxy is very close in a set of capabilities to Louketo Proxy and we highly suggest you investigate it as a replacement.
How do I migrate to OAuth2 Proxy?
We’ll provide high-level guidance on how to migrate. Although unfortunately there is no comprehensive guide nor magical script. Some corner cases, specific configurations, and capabilities may not be fully covered or addressed in exactly the same way.
Why are you abandoning Louketo Proxy as a project?
Initial goals failed. Which were merging with OAuth2 Proxy and creating a wider set of OAuth2/OIDC integration libraries. Some individuals originally interested in collaboration took a step back. The end result is the Louketo project duplicating efforts and capabilities of other much more popular projects - OAuth2 Proxy. As we believe in OpenSource we just don’t want to follow NIH syndrome :)
I would like to keep maintaining Louketo - what should I do?
Please comment on this GitHub issue so others can join the discussion. We’ll take it from there :)
What happens if nobody will step up to maintain Louketo?
After 3 months Louketo repository will be archived and made read-only.

@ramshazar that's correct. That's explained in the FAQ.

Took long time to migrate to OAuth2-Proxy but still failed.
Checked all step by step according to documents again and again.
My conclusion, for now louketo-proxy is simple and working as well. I'll stay louketo-proxy for long time.

Hey, is it planned to add a notice to the README? Currently it still states the following:

This repository is a work in progress

This is quite confusing for someone stumbling upon this repository. I propose a note at the top, something akin to this:

NOTE: This project has entered the EOL procedure and will only receive fixes for critical bugs and security issues. Take a look at OAuth2 Proxy project for similar functionality. More info here.

If you want, I can open a pull request.

Hey, Sorry to hear the project is EOL'ed. But understandable if the goals have not been fulfilled. Maybe someone will want to maintain it. The more Options the better
In that vein, here are some other projects ( hope that’s ok, it’s a tiny bit off topic ! ). None of these are a 1-1 replacement to Gatekeeper, so don’t expect to just plug and play. And both off these will likely require more adaption of existing tooling & infrastructure then switching to oauth2proxy. There are likely many others
There is the Pomerium Project:
Github:
https://github.com/pomerium/pomerium
Docs:
https://www.pomerium.io/docs/
Or the Ory.sh (Oathkeeper)
Github:
https://github.com/ory/oathkeeper
Docs:
https://www.ory.sh/oathkeeper/docs/reference/configuration

Would like to see suggested examples for how to adapt one specific element that louketo provides that does not seem to be available in oauth2-proxy - --headers=Authorization=Bearer XXXXXX
i.e. being able to add a static header to upstream request. In particular, for the very basic use case of "I want to simply expose my k8s dashboard"
I'm not seeing any way to support that function with oauth2-proxy.

@nneul please ask on the oauth2-proxy mailing list, it's the best place to understand the details of oauth2-proxy.

Hello @abstractj, where is the

We’ll provide high-level guidance on how to migrate.

Thanks.

@fadao23 are you looking for something specific? What kind of guidance you need?

@fadao23 are you looking for something specific? What kind of guidance you need?

Louketo/Gatekeeper works with "resources" restrictions.
Acutally I do not find in the Oauth2-proxy documentation something similar, we just can restrict access by "groups".
Do you know how reproduce the "resources" restriction provide by louketo in Oauth2-proxy ?
Thanks

i will miss forwarding feature of louketo, will see if something like that will find in other proxies

ok to all, these are my findings, when roughly checking for my requirements for proxy:

pomerium is not able to do bearer token validation
oathkeeper does not implement forwarding of token - probably in rework it will be there
oauth2-proxy seems to be mess to me, quite confusing docs of options and also looking at code doesn't make me very persuaded
all these does not support forward signing

Would like to see suggested examples for how to adapt one specific element that louketo provides that does not seem to be available in oauth2-proxy - --headers=Authorization=Bearer XXXXXX
i.e. being able to add a static header to upstream request. In particular, for the very basic use case of "I want to simply expose my k8s dashboard"
I'm not seeing any way to support that function with oauth2-proxy.

this might be option --pass-authorization-header=true

@fadao23 are you looking for something specific? What kind of guidance you need?

Louketo/Gatekeeper works with "resources" restrictions.
Acutally I do not find in the Oauth2-proxy documentation something similar, we just can restrict access by "groups".
Do you know how reproduce the "resources" restriction provide by louketo in Oauth2-proxy ?
Thanks

for keycloak provider there is - --keycloak-group

I'd be fine with oauth2 proxy other than that it seems to have a glaring missing capability, and that is just adding a static header.
i.e. the --headers=... option for louketo - which I use to send a fixed/static bearer token to upstream.
I could use oauth2 proxy in conjunction with other stuff to get that accomplished, but that's just extra steps.

I agree with @p53.I have tested alternatives of louketo proxy (pomerium,oathkeeper,oauth2-proxy). I'm not convinced by none of them (missing  features, documentation not clear or not updated, chaotic parameters,...)Currently, I'm not ready to use them in production. Knowing Keycloak, Louketo integration was efficient and full featured. For me, Louketo is more accomplished than known alternatives (Are there other candidates to replace louketo?)
@abstractj Because of difficulty to find a valid successor, EOL in november would be too soon?  Could do you reconsider your decision?
PS: It could be interesting to change Readme to add EOL informations.

For me it seems that the auth approach between the projects is quite different.
oauth2_proxy is more intended to be a global SSO solution for all services in a cluster at once (one proxy as ingress / right behind the ingress), whereas gatekeeper/louketo serves as sidecar container proxy directly in the pod, providing you with SSO and potentially very fine-grained access control to specific services.
Using oauth2_proxy as a sidecar container is possible, however without all the benefits and I had some issues with session inconsistencies as well using it that way... 🤔

Afraid we really don't have capacity to maintain Louketo/Gatekeeper at this point. It was intended that folks from OAuth 2 proxy (and another group) was going to help out with Louketo, hence the move from Keycloak Gatekeeper to a new project.
Personally, I do think Louketo/Gatekeeper has a better experience and is simpler to use than other things, but we just don't have the team around it to maintain it I'm afraid.
I would love to see a group of people take ownership of Louketo/Gatekeeper and make something really nice out of it, but we haven't had anyone step up to do that (at least not that I'm aware of).

I'm considering stepping up to keep louketo going!
I used gatekeeper because it was almost paired with keycloak back then, and I assumed that gatekeeper would just have the best integration with keycloak.
I'll take a quick look at oauth2-proxy to make sure that louketo/gatekeeper at least fills a niche that oauth2-proxy isn't intended for.
From https://github.com/louketo/louketo-proxy/issues/683#issuecomment-702989154, it seems that the alternatives are just missing features in the near term. Does anyone know if there's a specific niche that louketo fills?
I did feel that louketo provided a better experience. @stianst, do you see the experience as louketo's defining feature?
Is anyone else interested in maintaining louketo too?

I'm considering stepping up to keep louketo going!

That would be really awesome!

I'll take a quick look at oauth2-proxy to make sure that louketo/gatekeeper at least fills a niche that oauth2-proxy isn't intended for.
From #683 (comment), it seems that the alternatives are just missing features in the near term. Does anyone know if there's a specific niche that louketo fills?

What I miss in other solutions is:

fine-grained access control/authorization(let user with role X only use POST on path Y, whitelist url x,y,z etc.)
ease-of-use. Setting it up is like 5 minutes work.
support for roles (there's an issue for that in OAuth2-Proxy)
proper documentation

Some solutions provide No. 4 , but the rest are core features that only Louketo provides.

I did feel that louketo provided a better experience. @stianst, do you see the experience as louketo's defining feature?
Is anyone else interested in maintaining louketo too?

I would love to do that, but as an Ops guy with not much experience coding, (I have only (badly) written my fair share of bash/Python scripts and some OO Java/C# in college.) don't think I am capable of doing that. I can however step up and let others know that there certainly is interest to keep Louketo alive. It is actively used in the company I work for. As there are no alternatives it would be a real PITA to have to stop using it.
Was really sad when I read Louketo reaching EOL, as I really liket. I sincerely hope others jump in on your initiative.
Thank you in advance anyway. :)

@ackerleytng for me main problem of oauth2 was that it supports many things but it is not clear from docu which options belong to which type of provider+i wrote issue about forward signing and client credentials grants and they wrote there that oauth2 wasn't intended for not-user authentication, so probably this is main difference louketo is more service to service oriented and simpler because it doesnt support all those vendor oauth2 modifications. maybe i would join with few commits too, i am really interested in that client credentials pull request which is already there

https://github.com/oauth2-proxy/oauth2-proxy/issues/810#issuecomment-711065364

Okay! When I used gatekeeper, I used it because it was simple to understand and use. Thanks for all the suggestions!!
Louketo/gatekeeper seems to have found a niche in software with a few services, that need authentication and authorization, and also a forward signing proxy.
Louketo is like the little all-in-one executable that gets software off the ground and guides you to set up the correct auth settings. (Let me know if you have a nicer sound bite for the future landing page)
I'll get in touch with the current maintainers to see if there are any licensing constraints if I want to step up.
For the next few months I think we should first try and reverse the announcement on sunsetting! I've seen some articles mark louketo as EOL. I'll also start off by reviewing and improving docs, which was a key feature people like.

Hey @ackerleytng , have you a fork somewhere I can see ? I would be glad to try to find some time to contribute, and make some suggestions.

I don't have a fork now. I'm new to being a maintainer and would like to learn.
@stianst how do you currently maintain louketo? Who gets to merge to the louketo project?

@ackerleytng As it stands Louketo is EOL on 21st November and we will only merge security related issues, or critical regressions. We will only do another release of Louketo if it is absolutely needed.
We would welcome others to take ownership and continue the maintenance of Louketo. We'd have to define a group of maintainers that sign-up to owning the project, and have a conversation about how the transfer could be done.
@abstractj FIY

@ackerleytng there is also a fork here https://github.com/oneconcern/keycloak-gatekeeper.

Cool! Maybe they would be willing to maintain louketo instead!

@ackerleytng Hi, Any news about the possibility to maintain louketo with a new team ?
The EOL is coming and I would like to know if louketo is really dead to migrate to oauth-proxy.

@statik Have you contacted @fredbi from oneconcern to exchange and to know his position about louketo maintenance?

I was waiting for @abstractj and @stianst to define the group of maintainers and discuss the transfer. Let me also reach out to someone from oneconcern.

@malys I have not. I have a project https://github.com/kindlyops/havengrc that was using keycloak gatekeeper before it was briefly renamed to louketo. My plan is to simply work on porting HavenGRC to https://github.com/oauth2-proxy/oauth2-proxy and work with the existing oauth2-proxy community to make any fixes or enhancements that I need.

@ackerleytng there is also a fork here https://github.com/oneconcern/keycloak-gatekeeper.

I am the current maintainer of that fork. I am not actively adding features but keep currently focused on my main use case.
PRs to this fork from other contributors are welcome.
I've tried hard in the past to keep in line with the gatekeeper's master before eventually deciding to fork away and step back from the original repo.

Thanks @ackerleytng @statik @fredbi. I'm pessimist about louketo future. With a heavy heart, I will to switch to oauth2-proxy v7.
Thanks to louketo community.

@malys @ackerleytng @statik we could just fork this and set new targets, besides just maintaining backward compatibility with Gatekeeper (sorry I could never get used to the short-lived "louketo" name :) ).
It would take but a couple of volunteers joining forces to make something out of this codebase.
What I'd like is:

Keep keycloak as a reference implementation, but not constrain users with keycloak
Split away from the Keycloak governance structure, mailing lists, jira and similar impediments
Set clearer targets about the use cases we want to cover
Set up for modern cloud-based infrastructure, with baked helm chart, and possibly, integration with extensible service meshes (e.g. Traefik)

In short, if, say, 5 such volunteers declare here their will to dedicate some of their time to this project and agree with my 4 bullet points above, I'd be happy to continue working on this next year.

@fredbi i would give some help, from what i've seen there are quite old dependencies there, so it would need update

@fredbi I'm with you on that. :)

@ackerleytng @p53 @malys @statik @GerkinDev
After an offline discussion with @ackerleytng, we have decided to continue maintaining this piece of software.
I think that can skip the repo transfer and just start with a fork.
The first immediate action would be to collect available documentation and setup CI etc.
I have a lot of updates to contribute back from my fork, especially re-obsolete dependencies. I guess most early contributors just did the same....
I'd like this to be part of the keycloak contributed eco-system and remain interoperable with keycloak out-of-the-box.
@stianst @abstractj  feel free to chime, should you have any piece of advice or gotchas we should avoid.

@fredbi sounds great! I will try to help

Do join us on discord at https://discord.gg/Eq4rnkeMmP! @statik especially you!


COMMON ISSUES: [Package lombok does not exist]

Solution at https://github.com/CertifaiAI/certifai-wiki/wiki/How-to-Install-Lombok-Plugin


bpf: do not invoke llc from Makefiles

bpf: do not invoke llc separately
Update the various bpf Makefiles to not invoke llc anymore. This matches
what the loader does now.

Signed-off-by: Lorenz Bauer<EMAIL_ADDRESS>
tools/dev-doctor: do not check for llc
Compiling bpf doesn't invoke llc directly anymore, stop checking for its
presence.

Signed-off-by: Lorenz Bauer<EMAIL_ADDRESS>

/ci-verifier

/test

/test


FeaReq: Add an option to the change the day auto backups run on

The auto backups run on a Sunday and there seems no option to change.
I know there are already a lot of options but being able to change the auto day would be extremely useful.  My system is off on a Sunday.

Feel free to fork and add this feature.
The function is located here which configures the cron job.
https://github.com/sameersbn/docker-redmine/blob/master/assets/runtime/functions#L438
Alternatively, you can use the plugins post-install.sh script and create the cron job yourself.  Essentially take whats in the redmine_configure_backups_schedule function and modify they day_of_week. The example in the https://github.com/sameersbn/docker-redmine#installing-plugins section already shows how to add a cron job there.

Thanks jcormier, I'll give it a go.


📝  Revise admin api doc

fix #174

I updated the Tox version to target to v3 to unstuck the CI tests which caused by a tox V4 failure.
https://github.com/SatelCreative/spylib/actions/runs/5095339976/jobs/9160185371
Do we want to upgrade to tox v4 @hillairet ? Probably create an issue and assign to @rahulpatidar0191 ?


Widgets update issue fixed.

Fixes issue #1027
Changes: Widget is updated as soon as we add or remove a book mark

Closing this one, made a new PR #1077 .


[feature] Add an env command to make working with docker easier

Codecov Report

Merging #24 into master will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master      #24   +/-   ##
=======================================
  Coverage   48.60%   48.60%
=======================================
  Files          10       10
  Lines         502      502
=======================================
  Hits          244      244
  Misses        238      238
  Partials       20       20

Impacted Files
Coverage Δ

pkg/aws_config_client/completer.go
83.50% <100.00%> (ø)

Continue to review full report at Codecov.

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


Unnecessarily adding www. prefix is breaking most invidious instances

Please stop this practice.  Adding it serves no purpose and is breaking many of the available invidious instances because they already use subdomains.
Example: invidious.snopyta.org
If you add a www. to it, it becomes www.invidious.snopyta.org and won't load because it's not an existing domain.

Seconded. I've switched to using a different invidious extension

Thirded, it still does this.

Isn't this solved in the Firefox Addon store? It still happens to me as of today.

Isn't this solved in the Firefox Addon store? It still happens to me as of today.

Yep same issue here as of today.

Isn't this solved in the Firefox Addon store? It still happens to me as of today.

Yep same issue here as of today.

Same issue. For diehards of this add-on, you can use the following two instances. They do function, at least for the present moment.

invidious.tube
invidiou.site

Same issue. For diehards of this add-on, you can use the following two instances. They do function, at least for the present moment.

invidious.tube
invidiou.site

May default instance list work too:
https://redirect.invidious.io/
as
https://www.redirect.invidious.io/
is not enabled
Relate-to: https://mastodon.social/@rzr/106397984132797090

I have the same problem. I had a quick look at the source code but couldn't find a place where "www." is added. Since the developer has no motivation to correct this little thing, I consider this project abandoned. Can anyone recommend a usable extension?

I consider this project abandoned. Can anyone recommend a usable extension?

Indeed. Using Privacy Redirect.


Add Docker image

In GitLab by @LuiggiTenorioK on Jun 3, 2024, 15:25
MR to add a docker image spec of the app

In GitLab by @LuiggiTenorioK on Jun 4, 2024, 11:27
added 1 commit
db2701a2 - add README
Compare with previous version

In GitLab by @kinow on Jun 6, 2024, 10:46
Commented on docker/Dockerfile line 2
Is there a bookworm too?

In GitLab by @kinow on Jun 6, 2024, 11:13
I think I can test this one and approve the merge request now.

In GitLab by @kinow on Jun 6, 2024, 11:18
Commented on docker/build.sh line 5
Oh, now I see the &>build.log. Could we leave the logs in the terminal? I had to open another terminal and tail -f (it's slow on my machine as it's my first time downloading the files...).

In GitLab by @kinow on Jun 6, 2024, 11:20
Commented on docker/README.md line 25
This will build :latest, IIRC. Probably better to use the git branch as tag too.

In GitLab by @kinow on Jun 6, 2024, 11:27
Commented on docker/README.md line 25

Yup, it's latest by default.

In GitLab by @kinow on Jun 6, 2024, 11:29

It works! Left a few comments about tag & logs redirection. But everything works, so +1. Thanks @LuiggiTenorioK

In GitLab by @kinow on Jun 6, 2024, 11:29
approved this merge request

In GitLab by @kinow on Jun 6, 2024, 11:31
Commented on docker/Dockerfile line 10
BTW, are you going to pin on a commit/version here too?

In GitLab by @LuiggiTenorioK on Jun 6, 2024, 11:32
Commented on docker/build.sh line 5
It could be, but that's the example script :sweat_smile:

In GitLab by @LuiggiTenorioK on Jun 6, 2024, 11:34
Commented on docker/Dockerfile line 10
Yup, that change is going to be on cascade. First, we deal with Autosubmit, then API, then GUI.

In GitLab by @kinow on Jun 6, 2024, 11:41
Commented on docker/Dockerfile line 10
Sounds good! Sorry that I started the other way around :laughing:

In GitLab by @LuiggiTenorioK on Jun 12, 2024, 12:05
added 1 commit
e6f98a57 - fix subpath replace
Compare with previous version

In GitLab by @LuiggiTenorioK on Jun 12, 2024, 12:16
mentioned in merge request autosubmit!446

In GitLab by @LuiggiTenorioK on Jun 13, 2024, 16:10
An idea for the future:
We want to change API URL dynamically when doing docker run like this:
docker run -e "API_URL=https://..." --rm -d -p 8080:8080 autosubmit-gui

This is a limitation since this value is set on the build of the static files and cannot be changed easily from there.
An alternative is to set the AUTOSUBMIT_API_SOURCE=/api (as a relative path from the same host) and then proxy the desired API_URL to this subpath /api using nginx.
To do it, we can set an entrypoint.sh in the image which:

Add the proxy rule if the API_URL env variable exists
Starts the server

#!/bin/sh

# Replace %%_PROXY_RULE%% if API_URL exists else remove it
if [ -n "$API_URL" ]; then
    sed -i "s|%%_PROXY_RULE%%|location /api/ { proxy_pass $API_URL; }|g" /etc/nginx/nginx.conf;
else
    sed -i "s|%%_PROXY_RULE%%||g" /etc/nginx/nginx.conf;
fi

# Start nginx
exec nginx -g 'daemon off;'

In GitLab by @kinow on Jun 14, 2024, 10:13
That is a good idea! No objections :slight_smile:
Another idea/question, @LuiggiTenorioK; we spoke some time ago about API+GUI together (a version of GUI copied under an API folder, and point the static files of Flask to that folder).
I think that could simplify it a bit as well. That's how Cylc UI is deployed, inside the Cylc UI Service, their API (I believe we spoke about it).
Either way is fine for me :slight_smile:

In GitLab by @kinow on Jun 18, 2024, 19:03
Commented on docker/Dockerfile line 5
We can delete cached files.

In GitLab by @LuiggiTenorioK on Jun 19, 2024, 10:14
Commented on docker/Dockerfile line 5
Actually, in this case, Phase 1 is deleted and the second base is only left resulting in a final docker image of 28MB. So, no need to do it in this case.
https://docs.docker.com/build/building/multi-stage/

In GitLab by @kinow on Jun 19, 2024, 10:40
Commented on docker/Dockerfile line 5
Argh, missed that, sorry :sweat_smile:

In GitLab by @LuiggiTenorioK on Jun 21, 2024, 15:18
added 1 commit
d984f696 - add nginx proxy by changing env variable
Compare with previous version

In GitLab by @LuiggiTenorioK on Jun 25, 2024, 16:05
Commented on docker/build.sh line 5
changed this line in version 6 of the diff

In GitLab by @LuiggiTenorioK on Jun 25, 2024, 16:05
added 1 commit
6ee13b7a - update README
Compare with previous version

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 70.74%. Comparing base (2310b27) to head (0484fd4).

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #140   +/-   ##
=======================================
  Coverage   70.74%   70.74%
=======================================
  Files          52       52
  Lines        1528     1528
  Branches      192      192
=======================================
  Hits         1081     1081
  Misses        337      337
  Partials      110      110

Flag
Coverage Δ

fast-tests
70.74% <ø> (ø)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Update psuedo density to physical density in materials method

Description
Addresses one of the checkboxes in Issue #1097. This method needs to be using the physical density. Affected users have been notified and encouraged the change.

Checklist

[x] This PR has only one purpose or idea.
[x] Tests have been added/updated to verify that the new/changed code works.

[x] The code style follows good practices.
[x] The commit message(s) follow good practices.

[ ] The release notes (location doc/release/0.X.rst) are up-to-date with any bug fixes or new features.
[x] The documentation is still up-to-date in the doc folder.
[x] The dependencies are still up-to-date in setup.py.

I think this is an important enough bug fix to go in the Release Notes (in the /doc/ folder).

I think this is an important enough bug fix to go in the Release Notes (in the /doc/ folder).

Done! will merge when Ci finishes


bold syntax overflow

Prerequisites

[ ] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
Markdown isn't being processed correctly
Steps to Reproduce

create new file
set language to github markdown
type a sentence.
use the bold syntax
don't put a space and continue

Expected behavior: [What you expect to happen]
only the the bold part is bold
Actual behavior: [What actually happens]
everything after the bold markup is bold.
Reproduces how often: [What percentage of the time does it reproduce?]
idk, idc, just reporting a bug i really don't care what you do with it.
Versions
0.90.2
You can get this information from copy and pasting the output of atom --version and apm --version from the command line. Also, please include the OS and what version of the OS you're running.
Additional Information
Any additional information, configuration or data that might be necessary to reproduce the issue.
your contribution guideline is stupid and atom-editor specific, this doesn't make sense for a package.

Thanks for taking the time to contribute!
We noticed that this is a duplicate of https://github.com/atom/language-gfm/issues/117, you can subscribe there for updates if you'd like.

Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


hello! I can't download large files

I'm a rookie, I don't know if I'm doing it right, I've tried many times but I can't download, and Git Lfs has been installed. Initialize Lfs after using GitHubDesktop to download the project, and large files can not be downloaded down! I really need and want to study this program. Can anyone help me? Thank you very much

Goes git-lfs report that it's installed?

是否git lfs报告已安装？
I type git lfs --version
Show this. I think it's installed successfully
git-lfs/3.4.0 (GitHub; windows amd64; go 1.20.6; git d06d6e9e)

How did you solve it?

How did you solve it?

remain to be solved

It just means they are in the repo instead of LFS storage.


warp model

Will you release the warp model as well? Also does your experiment include results for 1024x768 resolution?

Yes, we will update the warping model soon. About other resolution model, we do not plan to release. You can train it by modifying the model config. Thank you for your interest in our work.

@Limbor Hi, should we load the warp model using https://github.com/geyuying/PF-AFN/tree/main since the params' dimensions mismatch the default network setting in PF-AFN

Hi @garychan22 We have released the inference and training code for warping module

do we need pose, densepose, cloth_mask, and others? It seems cp_datasets.py read these message. https://github.com/bcmi/DCI-VTON-Virtual-Try-On/blob/872b823f1daec9a187dc7a943434bf9520245070/warp/test/data/cp_dataset.py#L202C27-L202C27

Yes, the VITON-HD dataset should include these data. If you want to test on your own data, you should do some preprocessing to get these data.


Deprecate v0 custom element reactions

https://github.com/eavichay/slim.js/commit/bfcb46438f0cf24af90f8e1ad13412dfe28ba9f4
If we are going to migrate to v1 registration I feel we can deprecate the hooks for the v0 callbacks (i.e. attached / detached) . Will make slim a touch slimmer. ;-) <3
Let me know if you need me to PR this.

You should update your code. Im beyond that already.

On 29 May 2017, at 14:03, snuggs<EMAIL_ADDRESS>wrote:
If we are going to migrate to v1 registration I feel we can deprecate the hooks for the v0 callbacks (i.e. attached / detached) . Will make slim a touch slimmer. ;-) <3
Let me know if you need me to PR this.
bfcb464 https://github.com/eavichay/slim.js/commit/bfcb46438f0cf24af90f8e1ad13412dfe28ba9f4
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/eavichay/slim.js/issues/13, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCMK4i_9-ywOH6M3pmClqmOXSG8yLcuks5r-qXtgaJpZM4NpLZz.

Not certain you understand what I mean @eavichay.
For example: v0 callback
https://github.com/eavichay/slim.js/blob/master/src/Slim.js#L737
Can be inlined to v1 callback
https://github.com/eavichay/slim.js/blob/master/src/Slim.js#L721-L723

Currently it should support V1 with fallback to V0 if someone decides to use document.registerElement. If you think it should be dropped completely - your'e welcome but It smells like a breaking change so as long as it's not an issue, I'd prefer keeping it, at least until version 3 it out. Currently it looks like version 3 has real performance issues and good chances i'll drop it completely, though the code is half-size... WDYT?

:thinking: great question. However I feel the current API is great and should encourage NOT having the author define the custom element themselves. I feel this is one of the main reasons to even use slim.js.Let someone else worry about the movement of the spec. Like i said the thing i learned best from ruby is enforced conventions often remove tons of edge cases of configuration. #FreeJewelry 💍 💎 .
Let's think on it a bit and make a decision later today/tomorrow. To your point we don't want to break anything. On the other side of the coin it won't be missed if no one is encouraged to use the feature. A win win win for your future self IMHO @eavichay

As you said yesterday. Can remove an extra function call on the call stack... :-) @eavichay

What if someone is not using onAdded/onRemoved but is overriding attachedCallback and calling super? It will not execute at all.

Well as you mentioned in the comments it's recommended to not override. Just move that comment to the README et voila (as they say in Paris 🇫🇷 )
https://github.com/eavichay/slim.js/blob/master/src/Slim.js#L734

viola

join the gitter channel please

As an addendum the one thing we lose from moving to customElementRegistry we begin to lose the ability to extend from derivatives of HTMLElement (i.e. HTMLParagraphElement) however. Which is another can of worms for later. You don't expose that api so that's not such a concern for slim.js. /cc @RobertChristopher

I agree. It should be deprecated.

Ok will work on this this weekend @eavichay


No fallback to MIX_ENV

Should fallback to MIX_ENV=dev by default.
** (Mix) Could not start application sentry: exited in: Sentry.start(:normal, [])
    ** (EXIT) an exception was raised:
        ** (RuntimeError) environment_name not configured
            (sentry) lib/sentry.ex:84: Sentry.check_required_env!/0
            (sentry) lib/sentry.ex:37: Sentry.start/2
            (kernel) application_master.erl:273: :application_master.start_it_old/4

If you check outhttps://github.com/getsentry/sentry-elixir/blob/master/lib/sentry.ex#L78 you need MIX_ENV or environment_name set.

I think using System.get_env("MIX_ENV") at https://github.com/getsentry/sentry-elixir/blob/master/lib/sentry.ex#L82 is the wrong way to grab the mix environment. The standard way to do so with Mix is with Mix.env. I find it very annoying to have to pass in MIX_ENV=test mix test just to do testing with mix test automatically sets the Mix environment to :test.

Using Mix.env in your application code is an anti-practice. I will make a
new issue to fix this.
On Sat, Oct 15, 2016 at 12:33 AM, Alex Garibay<EMAIL_ADDRESS>wrote:

I think using System.get_env("MIX_ENV") at https://github.com/getsentry/
sentry-elixir/blob/master/lib/sentry.ex#L82 is the wrong way to grab the
mix environment. The standard way to do so with Mix is with Mix.env. I
find it very annoying to have to pass in MIX_ENV=test mix test just to do
testing with mix test automatically sets the Mix environment to :test.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/getsentry/sentry-elixir/issues/71#issuecomment-253964394,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGKFjrAgz0fIua0VDC4TXHlmQ8hklnMks5q0GXGgaJpZM4KT_YU
.

@alexgaribay @omin You could also juset set environment_name in your test.exs


Fix several small issues related to ambuda-bot

ambuda-bot's activity floods the "Recent changes" page and makes it
almost useless. For now, remove all changes by ambuda-bot so that
contributions by other users are more visible.

ambuda-bot has so many contributions in production that its Activity
page loads very slowly, even with an index. The root cause is an
unoptimized query. With a small fix, the page should be much more
performant.

ambuda-bot has so many contributions that its Activity page is a
little overwhelming. For now, show just the 100 most recent revisions
for a given user.

Fix a bug in "Recent changes" where the list of revisions + products
isn't properly truncated after the sort.

Test plan: tested all of these on the dev server.

Landing to fix ongoing performance issues -- happy to clean this up later.


Conflicting Recipes

Few recipes that are conflicting with one another:
Chisel Recipes (From Chisel)
Iron now gives Mr Crayfish Knife
Diamond now gives Diamond Trowel from Botany
Heated Furnace from BuildCraft Additions
Gives Modular Furnace Core
Hope this helps,
Rk

This will be fixed soon. Seems its only server side.

Coal Pellets


electron-installer-windows expect electron.exe

electron-installer-windows verion 0.2.0
node version 6.9.4
npm version 3.10.10
windows 10
I'm building an installer using the command line without using config file and doing that the installer expect a file named electron.exe even if I pass name in params
electron-installer-windows --src bin/Myappname-win32-x64/ --dest bin/installers/ --name "Myappname" --icon resources/mast.ico --options.version 0.0.20 --options.name "Myappname" --options.product-name "Myappname" --options.icon-url resources/myappico.ico --options.setup-icon resources/myappico.ico --options.skip-update-icon true --options.remote-releases "http://myappdomain.com:48821/update/win32_x64/0.0.20"

If I rename the exe file by electron.exe it's working, but then the name of the is become electron :(
I not using a config file because name and version are parameters set to the console

Actually I just try using a json file with config inside and this is the same, the builder keep looking for electron.exe :(

ok so I don't know if this is expected but here it's what is happening:
the function getDefault is building the exe name using the name set in package.json only (and default is electron.exe),
then the script is using the property passed in the config file but it never rewrite the exe name, so the name have to be set on the package.json from the src folder.
my issue with that is the name of the app is a bit dynamics because we have a dev a staging and a prod version.

You don't have to rename electron.exe. You should be using a tool like electron-packager, which renames the app based on your productName or name fields. So the correct fix in your case is to provide the right info in your package.json file, so that electron-packager does the right thing.

When in doubt, look at the example app: https://github.com/unindented/electron-installer-windows/tree/master/example


School Closures

JCPS uses OneCallNow, which has a SOAP api available that could be polled for retrieving messages.
http://www.onecallnow.com/
https://help.onecallnow.com/euf/assets/Help/OCN_WebServices/WebServices3-2.pdf

Or, alternatively we could setup a Twilio number, but the service does a verification call to your number.

This issue was moved to office-of-civic-innovation/IFTTT-Smart-Louisville#21


Fix issue #3680

BTW please use a better commit message:
"Clean up error messages, fixing #3680" or so

Closing this for now, feel free to re-open


Use built-in no-restricted-syntax to ban null instead of plugin, ban null type too

Not sure how valuable this is, but there's not really a need to use a plugin to ban null; ESLint already provides no-restricted-syntax which can be used to ban specific matching nodes.
The upside is that with #57684, we won't need any plugins anymore.
Also, no-null only banned the value null, which is inconsistent from our guideline of not using null unless strictly required.

This would be helpful as a precursor to #57684, as this package is untyped.


Add getTypes route.

In the current form I'm allowing filtering by type:

I would like to have a route to get all the types. It would also be nice to add some bean validation to make all types have the following format: RESTAURANT, BAR, COFFEE_SHOP, etc. This can be done with the @ Pattern annotation. Thoughts @ZaneBartlett1?

I think having validation like this is good, but for adding an API for it, is there going to be a case where you would need that, but not also be loading a list of POI? The route that serves the POI should have the Type included. Also makes it impossible to do something like present a type that we possibly have in the database but don't have POI for yet. In a case like that we would probably not want to present that type.

Yes, I need to load these types on page load so I can display them as options in the form. Does that make sense? Because otherwise I don't have a dynamic list of all the types. Just the ones I manually entered.
For the last issue that actually won't occur. Since it is going to pull the types from the POI table it has to exist in the DB.

I guess I'm thinking of when this is in on it's own page, it's going to need to grab the actual list of POI to present on page load, and I figured it would get grabbed from that. I just now remembered at the bottom of the page that won't happen, so having to hit the POI route for just the types, when you're not actually displaying the POI, is a bit much. So sure, we could add that.
Good point that with how types work it necessitates having a POI for it. Kind of odd that we didn't think to denormalize that as well lol


polar-bookshelf: 1.0.13 -> 1.1.0

Motivation for this change
# 1.0.14

- Upgrade to latest semver and firebase-tools

- Fixed bug where the lightbox was kept enabled after we deleted an annotation

- We can now capture a new class of documents that use a vertical height on
  their CSS selectors.

- We can now capture XML documents which used XSL stylesheets.

- Major refactor of the disk datastore for the pending cloud sync functionality
  we're working on.

# 1.1.0

Polar 1.1 is fresh out the door and a lot of amazing features and bug fixes are enabled in this release.

The biggest feature by far is our support for the 'Save to Polar' chrome extension that allows you to send the URL of your active tab to Polar for content capture.

This makes it a lot easier to work with Polar as you can just click a button in Chrome and have it sent to Polar.

We plan on adding support for Safari, and Firefox in the future but we're taking things one step at a time.

Other features in 1.1 include:
- Disabling amp for now until we have a better solution on how to show the user that an AMP page is displayed and how to disable / enable it. Otherwise its confusing and often the amp page is WORSE not better.
- Fixed bugs with the browser size not changing during capture browser changing and also fixed some issues with it not properly accepting the browser change in some situations.
- Fixed bug in HTML zoom where the page would be truncated improperly.
- Blocked amp ads during the capture but they aren't blocked during the preview at the moment.
- "Fixed" nasty anti-aliasing bug in electron by blocking amp ads. They were annoying anyway but for some reason they were breaking chrome rendering - probably due to some web component nonsense.
- Implemented a new strategy with the vertical height algorithm in the capture system to revert it back to auto instead of a fixed max-height. Works a lot better now.
- Date/times no longer include ' ago' to be a bit more concise.
- Added small FAQ entry to enable Anki sync.
- Fixed a bug where we could select text and not properly work with elements.
- Renderer analytics didn't understand that a callback without an error wasn't a failure.
- Upgraded a number of important react packages: react react-dom react-moment react-select @types/react-table @types/react-select @types/react @types/prop-types @types/node-fetch
- removed inversify package (were not using it)
- latest fontawesome
- latest node-fetch
- fixed issue with electron-builder where it was forcing us to upgrade to the latest version for each release.

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Gee this thing gets updated a lot :)
@GrahamcOfBorg build polar-bookshelf


"**" prefix redundant in vscode files.exclude and search.exclude default?

The "files.exclude" and "search.exclude" both point to Basic Editing in Visual Studio Code to explain glob patterns. There it states the following:

If you enter example, that will match every folder and file named example in the workspace. If you enter ./example, that will match the folder example/ at the top level of your workspace.

But the defaults for both files.exclude and search.exclude prefix their entries with "**/". Is that prefix redundant or is the documentation incorrect?
	"files.exclude": {
		"**/.git": true,
		"**/.svn": true,
		"**/.hg": true,
		"**/CVS": true,
		"**/.DS_Store": true
	},

	"search.exclude": {
		"**/node_modules": true,
		"**/bower_components": true,
		"**/*.code-search": true
	},

It's probably worth noting that, unlike the above, files.watcherExcludeexplicitly states it uses absolute paths and therefore does need the "**/" prefix.

Configure glob patterns of file paths to exclude from file watching. Patterns must match on absolute paths (i.e. prefix with ** or the full path to match properly). Changing this setting requires a restart. When you experience Code consuming lots of CPU time on startup, you can exclude large folders to reduce the initial load.

It's probably also worth mentioning that those instructions list ! for excluding, but that isn't actually supported in the settings - https://github.com/microsoft/vscode/issues/869.

Search works differently than those settings. We automatically assume **/.../** in search for ease of use but settings are more precise


mergeAll()

Hi,
I've added a class method which allows you to create a signal by merging an array of existing signals together.
I found it useful, so I thought I'd see if you wanted to include it upstream.
Thanks,
Jason Pepas

Hey @cellularmitosis,
thanks for contributing!
How do you think about having this as an extension on array instead of a static function? Something like
[Observable(5), Observable(4)].merge() // Observable([5,4])

As you might have noticed I'm using observables here, because signals will be deprecated with the next version :)

This has been implemented as part of fe930ea9405f85a8aac656af261458e4c07f6ec4. Thanks for your work! 👍


fix crosspost hover

An external reddit css file was telling the crosspost image to be at a larger width that it should be when hovered, so I created a new css file "crosspost.css" in the css folder that should override that, and leave the other expando buttons untouched. for #188

Hey, thanks for trying to tackle the issue
Generally we work with SCSS files which allows us to have a single CSS file for the subreddit style. Your implementation won't work as Reddit doesn't allow you to have multiple CSS files. The only way your fix would work is when you implement this in a SCSS file like _core.scss and compile it to CSS with a SCSS tool

hi @TheTimeWalker, thanks for info. that is good to know! I have experience with sass and can implement that if it would help. If you'd like to take it or have someone else that's no problem 👍

Hey, just add it to _core.scss and it should be good to go(if it's working properly)

It does a slight jump whenever state changes, would be good if you adjusted it to this
 .expando-button.collapsed.crosspost {
    width: 20px !important;
    &:hover {
         width: 20px !important;
 }
 }

So that the both states are at the same size and there's no jumping.

@corinneling any progress?

@Jasius, I added the requested code, thanks for checking in again 👍

Thanks.


[WIP] Refactor

Pull Request Test Coverage Report for Build 73

550 of 739 (74.42%)  changed or added relevant lines in 6 files are covered.
258 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-26.3%) to 51.944%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pyswip/swipl.py
139
150
92.67%

pyswip/prolog.py
106
119
89.08%

pyswip/term.py
181
220
82.27%

pyswip/discover.py
53
179
29.61%

Files with Coverage Reduction
New Missed Lines
%

pyswip/easy.py
258
0.0%

Totals

Change from base Build 71:
-26.3%

Covered Lines:
561

Relevant Lines:
1080

💛  - Coveralls


bugfix: no more 'fatal' error on empty cloned repositories

This is a proposed fix for #11.
command git rev-parse --abbrev-ref <rev> will output  as it was given if it is not recognized as some ref, revision, or file. Therefore, wrapping it in a test will always succeed.
By checking $status explicitly we avoid this problem and know if we actually have an upstream or not.

:+1:


#103 Jobs-Section

Completed the front-end part of the Jobs-Section.

There is overflow on the x axis for mobile devices. This is probably treason why there is a white bar on the right. This should be resolved.

Since @Aleks1908 worked on this ticket on a different branch, I will close this Pull request as incomplete/duplicate.


End-user interface

From<EMAIL_ADDRESS>on January 18, 2011 16:32:38
Must be provided an enduser interface
Original issue: http://code.google.com/p/syncope/issues/detail?id=75

From chicchiricco on January 19, 2011 08:11:23
Also for managing password reset (password hint, CAPTCHA,...)
Summary: Enduser interface

From chicchiricco on January 20, 2011 00:33:17
Issue 41 has been merged into this issue.

From chicchiricco on April 11, 2011 03:38:27
Labels: Milestone-Release-2011Q2

From chicchiricco on April 11, 2011 03:59:42
Summary: End-user interface

From chicchiricco on April 12, 2011 09:28:29
Labels: -Milestone-Release-2011Q2 Milestone-Release-201107

From chicchiricco on May 16, 2011 03:32:38
Status: Accepted

From chicchiricco on May 16, 2011 03:32:51
Owner: chicchiricco

From chicchiricco on July 07, 2011 02:19:48
Labels: -Milestone-Release-201107 Milestone-Release-201112

From chicchiricco on September 19, 2011 05:16:13
Blocking: 167

From chicchiricco on September 19, 2011 05:18:08
Enduser interface will be part of current console webapp: an URL like /self will be provided for self user management.
Such interface will allow self-registration for anonymous users, if enabled in configuration.
Status: New
Owner: ---

From chicchiricco on November 10, 2011 00:48:05
Status: Started
Owner: chicchiricco

From chicchiricco on November 10, 2011 06:06:54
This issue was updated by revision r1239 .
Everything ready on core & client, let's move to console...

From chicchiricco on November 10, 2011 06:22:39
This issue was updated by revision r1242 .
Improving test case when password policy is not matched

From chicchiricco on November 14, 2011 09:01:27
This issue was closed by revision r1247 .
Status: Fixed


How to calculate total-num-updates in glue ?

Like RTE, it's training data size is 2490, if I train it 10 epochs with batch size 16, it will have 2490 * 10 / 16 = 1556 updates, which is different with 2036  in README.glue.md.

--total-num-updates are calculated in the way as you mentioned.
In the case of RTE, it is slightly different due to some initial oversight in the finetuning scripts. --total-num-updates is only used by lr-scheduler. So in this case, the final lr at the end of training, will be slightly higher than zero. We kept the same in readme for reproducability.
Feel free to experiment with 1556 updates.


PLT-8100 Allow deactivation of SSO users

Summary
Allow deactivation of SSO users. Adds a warning note when deactivating SSO users. PM please review the text.
Ticket Link
https://mattermost.atlassian.net/browse/PLT-8100
Checklist

[x] Has server changes (mattermost/mattermost-server#7952)
[x] Has UI changes
[x] Includes text changes and localization file (.../i18n/en.json) updates

Text approved by LB, moving to dev review


Remove HasNSeriesSKU

HasNSeriesSKU used case sensitive matching, which cause driver configuration to be skipped if sku name doesn't match "Stardard_N"

/lgtm

/lgtm


xWaitForCluster not accepting "Credential" parameter

Receiving the following error when trying to run xWaitForCluster on node attempting to join the cluster:
Chef::Exceptions::PowershellCmdletException
Powershell Cmdlet failed: Invoke-DscResource : Undefined property Credential
It seems that maybe that parameter was removed but the documentation hasn't been updated?

It appears as though the "xWaitForCluster" part is not ready yet, from what I can tell. I was assuming it would allow a node to join the cluster once it was ready but I don't see the code that does that yet. Or, am I missing something?

@aarsan I noticed you posted this some time ago, However I would still like to try to answer your question.
I think xWaitForCluster was only created to check if the cluster is available for an additional node to join it.
Where you first use xWaitforCluster to see if the cluster exists, followed by xCluster to join the cluster.
I personally use it in the following order:
WaitforAll, xWaitforCluster, xCluster

@aarsan  I tend to agree with @DdenBraver .


Displaced Person Camps in Sudan Needs to be Released

id:f96cbe75893b48139d8ec3c96ef9bd50
Owned by @nfeuerstein

Set extent and Released to ReleasedIntelligence


warn people via banner to use pmcares@sbi instead of pmcare@sbi which is a fraud UPI

according to wikipedia (https://en.wikipedia.org/wiki/PM_CARES_Fund):
"While the original UPI account was PMCARES@SBI, Delhi Police booked unknown individuals for creating an account removing the 'S', PMCARE@SBI, intended to scam people."

Out of scope.


Bijector error during data transformation in Turing

In this example, Bijectors throws an error when the data are transformed inside the main loop of the Turing model. The last example in #31 shows a workaround.

On a user-experience note:
The fact that one needs to pass a data object to the model formatted differently (as a tuple of individual tuples) than the data object expected by the SSM distributions (as a tuple of vector) makes it feel a bit clunky.
I wonder if it would not be easier to (additionally) allow for an independent specification of choice and rt in the distributions. For instance, add the rt=none keyword arguments to LBA(data; **kwargs), and in case data is a vector (i.e., someone just passed choice alone) & rt != none, we just re-format data = (choice=data, rt=rt) as a first step in the function.
This would give some flexibility and hopefully make the practical usage smoother (also it would remove the need to do extra data transformation to make a vector of tuples)

Wait no actually no this wouldn't work since we need something that can be indexed in the for i in n loop of Turing... Okay nevermind then

@DominiqueMakowski, no problem. These things can be a bit tricky. The convention I adopted with NamedTuples follows the same convention used throughout Distributions.jl. For example, rand(Normal()) returns a scalar while rand(Normal(), 1) returns a vector. In this package, we return a NamedTuple of scalars for rand(LBA()) and a NamedTuple of vectors for rand(LBA(), 1).
You are right that the lack of indexing in the case of vectors is inconvenient. I did consider using a 2D array of floats instead, but the potential problem is that the choice indices are actually integers, and are often used for logical indexing (e.g. [rt[choice .==1]). Unfortunately, logical indexing could potentially fail due to float point error. I'm not sure how likely it would be in the scope of these models, but it could potentially create a silent bug which could invalidate someone's analyses. Depending on what you are doing, destructuring the NamedTuple can convenient, e.g., choice,rt = rand(LBA(), n) . As shown the doc strings, this works with broadcasting. Although the system is not perfect, I think some degree of pre-processing  of data is almost unavoidable.
By the way, if you want a simpler way to generate a vector of NamedTuples, you can use a list comprehension or map:
n_obs =50
data1 = [rand(LBA(ν=[3.0, 2.0], A=0.8, k=0.2, τ=0.3)) for _ ∈ 1:n_obs]
data2 = [rand(LBA(ν=ν=[1.0, 1.5], A=0.8, k=0.2, τ=0.3)) for _ ∈ 1:n_obs]
data = vcat(data1, data2)

I think we can close this

I think there still might be a bug in Turing or Bijectors. We circumvented the problem by writing better code, but it seemed to be performing an unnecessary transformation. When I have time, I still raise the issue with devs at Turing.


Create IndyVdrPoolService in AFJ

Create an IndyVdrPoolService using the indy-vdr library that can be used to write and read objects from the ledger.
Create the @aries-framework/indy-vdr package
As the Indy VDR code will be hosted outside of the AFJ core package we need to create a new indy-vdr package first.
General steps to create a new pacakge:

Copy an existing 'simple' package (e.g. action-menu) protocol.
Rename all occurences of the previous package name (Action Menu, action-menu, etc..) to indy-vdr.
Remove dependencies that are specific to the old package (not sure if there's any for action menu), and delete all files from the src/ directory except for an empty src/index.ts file
Add the indy-vdr-test-shared package to both the peerDependencies and devDependencies and set the indy-vdr-test-shared peer dependency as optional (https://classic.yarnpkg.com/en/docs/package-json#toc-peerdependenciesmeta).
For now in the index.ts file add the following code to the top of the file to dynamically register the nodejs bindings. This is to prevent a hard dependency on the node implementation and will be improved upon in the future. You can eslint disable any eslint errors you're getting. Now whenver in the code you're importing something, make sure to import it from the shared library, not the nodejs library.

try {
  require("indy-vdr-test-nodejs");
} catch (error) {
  throw new Error("Error registering nodejs bindings for Indy VDR");
}

Done!

The indy-vdr-test-shared and indy-vdr-test-nodejs will need to be updated to the non test package once these are released to npm. Also, the indy-vdr-react-native should be added as optional peer dependency once this is released to npm.

Create the IndyVdrPool
The IndyVdrPool is a class that wraps the PoolCreate object  from the indy-vdr library and allow us to connect to a pool. The IndyVdrPool class manages a single pool. The IndyVdrPoolService that will be created in the next step will be able to manage multiple IndyVdrPool instance to achive multi-ledger support.
The interface of the IndyVdrPool should look as follows. This doesn't have to be an interface, but just so it's clear which methods should be exposed on the class. You can look at the implementation of IndyPool currently present in AFJ ,however do not this is based on Indy SDK which has quite a different api.
interface TransactionAuthorAgreement {
  version: `${number}.${number}` | `${number}`;
  acceptanceMechanism: string;
}

interface IndyVdrPoolConfig {
  genesisTransactions: string;
  isProduction: boolean;
  indyNamespace: string;
  transactionAuthorAgreement?: TransactionAuthorAgreement;
}

interface IndyVdrPool {
  get config(): IndyVdrPoolConfig;
  get indyNamespace(): string;
  connect(): void;
  close(): void;

  submitReadRequest<Request extends IndyVdrRequest>(
    request: Request
  ): Promise<RequestResponseType<Request>>;

  submitWriteRequest<Request extends IndyVdrRequest>(
    request: Request
  ): Promise<RequestResponseType<Request>>;
}

Create the pool services and related files in the pool directory in the src. This shouldn't be exported from the pacakge. Do create an index.ts in the pool directory to export the files from that directory.
Add the methods from the interface above. Here's some pointers on how to implement the different method:

the constructor takes in the poolConfig (IndyVdrPoolConfig and the logger)
config getter just returns the config
indyNameSpace getter returns the indyNameSpace from the config
connect should create instance of PoolCreate from the indy vdr library, and pass the transactions from the config to it. The pool should be stored as private property in the class
close should call close on the pool that is stored as private property (if defiend, could be undefined if pool is not created yet)
submitReadRequest should call pool.submitRequest and pass the request to it.
submitWriteRequest should call pool.submitAction and pass the request.handle to it (this will soon be updated to also take a request

That's it!
Creating the IndyVdrPoolService
The IndyVdrPoolService is going to manage all pool instances for the different ledgers we want to connect to. The IndyVdrPoolService can be based on the IndyPoolService currently present in AFJ Core.
One of the most complex parts of the IndyVdrPoolService is going to handle legacy identifiers that don't specify which ledger an object should be retrieved from.
New identifier types are structured like this:
did:indy:sovrin:7Tqg6BwSSWapxgUDm9KKgg
Old identifier types are structured like this:
7Tqg6BwSSWapxgUDm9KKgg
The old identifier type doesn't hint at from which ledger (sovrin) we need to get the did.

TODO

@TimoGlastra were you intentional about the code below cus' I assume it is supposed to be an import instead of a require?
try {   require("indy-vdr-test-nodejs"); } catch (error) {   throw new Error("Error registering nodejs bindings for Indy VDR"); }

I don't think you can do conditional imports as we'rs using node modules. So using require is sort of an hack

@Vickysomtee updated the issue with more details and also made an amendment to a previous step. First it mentioned submitWriteRequest should call pool.submitAction, but that should actually be  _submitWriteRequest should call pool.submitRequest `

Both should call submitRequest. submitAction is used for some specific calls that we aren't using


doc: extensions: add kconfig search extension

Introduction
This PR adds a new Sphinx extension to handle Kconfig documentation. The way this extension works differs significantly from the current approach, mainly due to technical limitations that will be detailed next.  These pages get parsed and rendered by Sphinx when the documentation is built. It turns out that adding ~10K individual pages to Sphinx slows things down, to a point we had to create the KCONFIG_TURBO_MODE or html-fast targets. In practice, this means that any viable solution needs to stay away from individual pages. In fact, the way bindings docs work suffer from the same issue, just that we still have less of them.
Technical aspects of the solution proposed here:

It is a native Sphinx extension (no more CMake hackery required)
It uses kconfiglib to build a JSON database for all Kconfig symbols
Introduces a new Sphinx language domain for Kconfig. The domain provides a Sphinx directive (.. kconfig:search::) that can be used to insert a Kconfig search tool on any RST page. When building HTML docs, that directive gets replaced by an actual search form. The :kconfig:option: role is now available to reference options (goes to Kconfig search form pre-selecting the option). Thanks to using a regular Sphinx domain, Kconfig options can also be referenced in other projects using Intersphinx.
A client-side Javascript library takes care of the rest: fetches the database and, based on user input, it renders Kconfig content dynamically. The library also handles URL hash, that is, if the page holding the Kconfig form is queried with #KCONFIG_OPTION_TO_DISPLAY it will just display it. This allows for permalinks, e.g., CONFIG_SPI.

Pros:

A native Sphinx extension
Only a single page is needed: this means docs will be faster by default
We can quickly search Kconfig options (it's faster than Sphinx search!)

Cons:

Kconfig options don't have a page now, so search engines will not index them.

Demo
https://teslabs.github.io/zephyr-kconfig-test/kconfig.html

Kconfig options don't have a page now, so search engines will not index them.

can we just list them somewhere without any individual rst pages for search engines to index with instructions to use the search capability for more details?

Kconfig options don't have a page now, so search engines will not index them.

can we just list them somewhere without any individual rst pages for search engines to index with instructions to use the search capability for more details?

Maybe by rendering the whole database will help if crawler is detected: https://developers.google.com/search/docs/advanced/javascript/dynamic-rendering

Maybe by rendering the whole database will help if crawler is detected: https://developers.google.com/search/docs/advanced/javascript/dynamic-rendering

that kind of sounds like an html-slow ;)

+1 assuming the issue I pointed out is fixed

Would it be possible to add some html param that would allow to capture search list? This would be useful in case when you need to inform somebody on list of Kconfig options that are dedicated to specific subsystem, for example:
https://teslabs.github.io/zephyr-kconfig-test/kconfig.html?seach=CONFIG_FS_LITTLEFS_
would redirect user to page with the CONFIG_FS_LITTLEFS_ already placed in search bar and list narrowed to Kconfig options beginning with CONFIG_FS_LITTLEFS_.

This looks great.
Some observations.
Old style will print all help texts (just like menuconfig),  meaning very often settings will not duplicate the help.
For example like here: CONFIG_BT_CTLR_ADV_PERIODIC
But with new approach, the duplicated setting gets its own description, but without help, like here: https://teslabs.github.io/zephyr-kconfig-test/kconfig.html#CONFIG_BT_CTLR_ADV_PERIODIC
But we should be careful not to start duplicating help texts, cause that will mess up menuconfig, for example as it can be seen here:

So at the current moment I don't have a good solution to this, and I don't think we should start duplicating help texts (instead we should clean up those that are duplicated today)
Also, due to supporting optional Zephyr modules, we source symbols with an if 0 causing the symbols to be unconfigurable, while still ensuring Kconfig tree works even when the module is missing.
However, this also results in duplicated symbols (both in old docs and in new):
https://teslabs.github.io/zephyr-kconfig-test/kconfig.html#CONFIG_BUILD_WITH_TFM
But I notice, the location is identical:

Is it possible to remove the entry, if the location field is identical to the location field of similar entry ?

Should we consider to make prompt more distinct from the help text  ?

Is it possible to remove the entry, if the location field is identical to the location field of similar entry ?

Yes, it's possible.

Should we consider to make prompt more distinct from the help text ?

Maybe render it in bold or italics?

This is definitely a massive improvement. As discussed at dev-review, I remain concerned about the way defaults are displayed. I think it should be clearer to the user that a system-wide default is not the same as what may appear on their target.

@mbolivar-nordic added support for other defaults in latest version
https://user-images.githubusercontent.com/25011557/154976100-011e542b-b901-4af3-94ef-c3e54f9b9e53.mp4

Is it possible to remove the entry, if the location field is identical to the location field of similar entry ?

Yes, it's possible.

Great :+1:

Should we consider to make prompt more distinct from the help text ?

Maybe render it in bold or italics?

Both are fine with me, but I see you already changed to italics , so let's keep it with that :+1:
Great work.

@mbolivar-nordic @henrikbrixandersen @carlescufi @nashif should be ready now


Fix score overflow issue in ScoreTiesAdjusterReranker for SPLADEv2

The method of rounding used in ScoreTiesAdjusterReranker causes overflow issues
because SPLADEv2 scores can get very big. Doesn't affect the actual ordering of
docs, hence everything is fine with MS MARCO output format, but does cause issues
with TREC format and trec_eval.
With this bug fixed, added SPLADEv2 regressions.

hi @MXueguang I've asked @JMMackenzie to take a look since we've discussed this on Slack.
However, another pair of 👀 on this wouldn't hurt either. Thanks!


Docs: Add Zenodo badge on the main page

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 68.43%. Comparing base (735211f) to head (70ad1c1).

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #147       +/-   ##
===========================================
- Coverage   83.95%   68.43%   -15.52%
===========================================
  Files          15       15
  Lines        1901     1901
  Branches      303      286       -17
===========================================
- Hits         1596     1301      -295
- Misses        209      526      +317
+ Partials       96       74       -22

Flag
Coverage Δ

pytest
68.43% <ø> (-15.47%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 5 files with indirect coverage changes


[ID] Remove Covid-related default keywords from Keywords

Under https://gost-grants-tools.onrender.com/#/keywords, currently we have a bunch of pre-seeded keywords. Partners have given feedback that this is no longer as helpful since CARES is wrapping up, and they tend to delete it and replace it with other keywords instead.

Started looking at this as a starter task (don't seem to have permission to claim/assign it on github?). Some observations and questions:

The keywords are seeded into the database for each agency listed when npx knex seed:run is run. Are we good with just removing them from the hardcoded list for future runs of this (i.e. newly added agencies) or do we want to also run a migration(?) to remove these rows for existing agencies?
There are unit tests for permissions logic related to the keywords table and associated routes and some of them expect these pre-seeded rows to exist for every agency. What sort of environment(s) do the tests run in and is it safe for a test to insert rows for the purpose of the test?
We also seed a single global keywords row with empty string query and NULL agency_id. What is this for?
What is the mode field on the keywords table used for? It seems to be set to autoinsert ALL keywords matches for the pre-seeded keywords and empty string for keywords created by users.

The keywords are seeded into the database for each agency listed when npx knex seed:run is run. Are we good with just removing them from the hardcoded list for future runs of this (i.e. newly added agencies) or do we want to also run a migration(?) to remove these rows for existing agencies?

Since we'll need to set up new tenants and new agencies from scratch anyways, removing for future runs only is fine.
I do not have answers to the other questions, but I'll get you access to the tool for you to poke around in case it helps to answer!


100% Unachiveable

Seems the percentage math is setup so that 100% can't be achieved.
In my particular case, I have a functionRate of 1, a lineRate of 1, and a branchRate of 1. However, the coverage percentage comes out to 99%.
var percent = (((functionRate + lineRate + branchRate) / 3) * 100).toFixed(0) - 1;

Humm @destroyerofbuilds ... Let me guess... Do you see this -1 in the formula??? :D I'm sure I messed it up some day change the "toFixed(0)" from other functions...

Will be sending the fix to this https://github.com/intuit/istanbul-cobertura-badger/commit/e76a6e38a728987e7a6723209c9ccc262d950408#commitcomment-15004608

@destroyerofbuilds Please verify the new version 1.2.1!!! I added the test case for the problem as well!!!

@marcellodesales I can confirm the latest code is behaving as desired.
Thank you for all the hard work!

@destroyerofbuilds Awesome!!! I'm glad it is working properly now! :+1: Thank you for the verifications!


Feat/add init py

Description
__init__.py is gonna generated by openapy, that enables to call each function like processor.get_pet()
Type of change
Please delete options that are not relevant.

[ ] Bug fix
[x] New feature
[ ] Document
[ ] Test
[ ] CI/CD
[ ] Refactor

How has this been tested

[x] Unittest
[ ] Others:

Checklist:

[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Codecov Report

Merging #32 (14a77e7) into main (f292995) will decrease coverage by 0.90%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #32      +/-   ##
==========================================
- Coverage   96.40%   95.50%   -0.91%
==========================================
  Files          12       12
  Lines         278      289      +11
  Branches       56       58       +2
==========================================
+ Hits          268      276       +8
- Misses          5        7       +2
- Partials        5        6       +1

Impacted Files
Coverage Δ

openapy/commands/generate.py
100.00% <100.00%> (ø)

openapy/config.py
100.00% <100.00%> (ø)

openapy/parser.py
89.13% <0.00%> (-6.53%)
:arrow_down:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


"Create New Scene" dialog doesn't follow naming conventions

Godot version
master (46424488e)
System information
Godot v4.1.rc (46424488e) - Arch Linux #1 ZEN SMP PREEMPT_DYNAMIC Wed, 21 Jun 2023 20:46:07 +0000 - Vulkan (Compatibility) - AMD Radeon R9 380 Series (tonga, LLVM 15.0.7, DRM 3.52, 6.3.9-zen1-1-zen) () - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)
Issue description
This is the dialog that shows up when you right click in the FileSystem dock and select Create New -> Scene...
We are prompted for a required filename to save the scene as, and an optional root name to use for the root node. If I leave the optional name empty, and use a snake_case name for the filename, the root node of the scene will also be set to the same snake_case name. I'd instead expect to have it converted to PascalCase.
Note that this only happens through this specific dialog. Creating a scene through main menu Scene -> New Scene creates an "unsaved" scene with a PascalCase root node, and when saved, it will correctly be renamed to snake_case.
Steps to reproduce
In FileSystem dock, right click and select Create New -> Scene....
Minimal reproduction project
None.

The tooltip simply says it will use the scene name, so there's no indication it will change any syntax

Be aware of editor/naming/node_name_casing and editor/naming/scene_name_casing. If this is implemented, it should follow those.

The tooltip simply says it will use the scene name, so there's no indication it will change any format

Right. I wouldn't expect any case change to happen if we were to manually fill in the root node. But if left empty I'd assume it would get auto-guessed correctly.

It doesn't say that though, it says "Leave empty to use scene name", so the assumption is unfounded

Fair.
In my mind, since I'm used to the case always changing between node and filename, the concept of "scene name" exists outside of case choice. But I can see how the literal interpretation of "scene name" in the context of this dialog would rather refer to the filename. Mostly because "Scene Name" identifies the filename in the other textbox.
Screenshot to aid in discussion:

Maybe the wording needs to be changed? What if the "Scene Name" textbox was labelled "Scene Filename" instead? Could the tooltip's "scene name" then be more readily thought of as the generic concept of the name rather than the specific filename / case choice? Or maybe the tooltip needs to change?

After some thinking, this is what I've come up with for the dialog:

"Scene Name" is changed to "File Name". And the tooltip now reads "Leave empty to infer from file name"
To me it seems more clear this way. Thoughts?

I'd also like to extend this issue to the "Attach Node Script" dialog, opened from right clicking on a scene node -> "Attach Script". The path of the script should be auto-guessed respecting the casing choices.
On that note, the editor setting for the filename casing is "scene name casing", but if we are to use this for the script name as well (which should follow the same rules as the scene filename), then maybe it could be more appropriately renamed as "file name casing"?

Closed by #79756 ?
Alternative wording suggested in https://github.com/godotengine/godot/issues/78946#issuecomment-1629260967 might still be nicer. But good enough for me.


Add --dev to installation instruction

You don't really want to share exceptions when not in dev

Thanks!


Missing previous releases of cloudsql-proxy

Hey,
I'm trying to deploy cloudsql-proxy, but one of the issues I'm facing is managing releases.
It appears that you only expose one version at a given time (only the tag for 1.05 is visible) which makes it really hard to reproduce a build for an old version.
It also appears that the binaries you provide does not contain the version number, I assume this means that they are always the 'latest'. I'd like to package one specific version and in order to do it securely I want to be able to verify its checksum. If this changes over time (a new version replacing the old one) this will no longer work.
1) 'd like to ask that you provide a URL for downloading the static binaries which include the version number. Guarantee some kind of retention for old versions (e.g. 6 months).
The URLs I'm referring to right now are the ones listed here:
https://github.com/GoogleCloudPlatform/cloudsql-proxy/releases
2) Can we guarantee that tags for old releases remain available after a new release is made available. This would allow us to setup a build for the project, but without it, it would be something we would have to attempt to maintain ourselves.
3) What guarantees do you intend to provide between Major vs. Minor version bumps? You do not appear to use semantic versioning right now so this is unclear.
Thank you for your time!

Hey there, glad to hear you're using the Cloud SQL Proxy! Please continue to open feature requests for anything else that would make that sort of setup easier, along with any issues the Proxy caused.

Sure thing, for the next release I'll try to get this set up. I'll keep the existing URLs and have them point to the 'latest' release after some amount of time, but I'll also release URLs to point to specific versions of the code.

Do you want me to post the hash of the binaries or do you want to do it yourself? If you want me to, can you suggest a place where it should go? I've been wanting to do this but can't think of the best place to put it for it to be easily accessible by automation. Maybe in the repo?

Are you referring to the docker containers that are released? If so, I recently was told that I should be doing this and have already started doing so. Before I always just updated 'latest', but now I will be doing the update in a staged way. That is, do a release and create a new tag for the release, and then after a bit of time update the 'latest' tag to be the new release. As of now, the 'latest' tag is version 1.04.

Let me know if there's some other way you think is best to do this.

Well, it's kind of semantic version, depending on your definition. (Barring bugs in the release) each release has been a non-breaking minor change from the previous version. Some of the releases probably could have been a patched version of the previous version (e.g. 1.03.1), I suppose. I can start doing the patched releases when it really is a small set of changes which just fix bugs.

As for guarantees, the thing that comes to mind is that I'll be changing the default of the -check_region to true instead of false, and at some point setting the flag to false will have no effect and the region will be mandatory (and it's likely that all previous versions of the proxy will no longer work). I suggest you start setting it to true on your own to ensure that you'll be ready for all of that. There's no hard plan about the full requirement to say the region when specifying instances, but the default flip will happen sometime soon.
There's still not a hard guarantee between versions though. There are not yet any plans to make breaking changes, and if any come up I will fight hard against them. But, as the Proxy and Cloud SQL evolve there may not be anything I can do about a breaking change due to some backend change I am not involved with (this is the case with the -check_region flag, for example).

Great for fixing the URLs, that will help a lot. For me there's no need to publish the hash, we'll be generating them as new releases are made available.
For 2) I was referring to the git tags.
Also, thanks for clarification on 3), it's mostly about can be expected from future versions.
Thanks for the help!

Hey, it also appears as if the current available binary doesn't match the latest version. I get the following issue when using the uploaded binary:
the default Compute Engine service account is not configured with sufficient permissions to access the Cloud SQL API from this VM. Please create a new VM with Cloud SQL access (scope) enabled under "Identity and API access". Alternatively, create a new "service account key" and specify it using the -credentials_file parameter

Which is not present if I compile master myself.

Hmm, the static binary URL hasn't been updated yet. Investigating now.

Forgot to update this bug. The static URL should be pointing to 1.05 now.
As for git tags, I will now be adding them each time there's a release. I just discovered this feature and I think it's great.
Please let me know if there are any more things you'd like answered!


LNK2001 error

Hi, im trying as hard then i can for compile everything... But im stuck with LNK2001. Particularly with the libcef_dll_wrapper.
I tested in VS 2015, VS 2017 on 32 bit and 64bit but always getting that error. Normally it's a runtime problem but even switching over /MT or /MD give me the same error.
Any idea ?
Thanks!

Did you fix this problem？ I meet this problem else in VS2017.
I try to change the lib link and lib path, but it‘s not mean anything.
if you find the way to fix this problem, I m thanks for that.

I fix this problem. The version of CEF that the include folder is 3.2987.1601, but the download DEBUG RELEASE and RESOURCE is 3.27. So same function is not match. To fix  you should download version 3.2987.1601 DEBUG RELEASE and RESOURCE files in http://opensource.spotify.com/cefbuilds/index.html.
My project can be Built successfully, but it can't run well. I run the DirectX11 project, and is stuck in CInitialize() function. VS throw a exception and i don't know how to DEBUG it. The problem maybe the CefApp object.


glib: Add helper functions to spawn a non-Send future on the curren…

…t thread-default MainContext

CC @elmarco @pbor @A6GibKm

This is apparently not too useful because g_application_run() and g_main_loop_run() are not pushing their main context as the thread default one.

Maybe something like this. It would take the thread-default main context if any, otherwise the global default. And then make sure that the current thread actually owns it.

I guess there is not really any interest in having such a function? Let's close this then?

Huh? This would definitely be helpful

I got no feedback at all so I assumed nobody actually needed it :) As it's apparently useful to you, do you have suggestions about the name and where to put it? Where/how would you expect it?

Huh? This would definitely be helpful. Apps currently use a macro for this.

Note that they do ``MainContext::default()rather thanMainContext::thread_default()`

Note that they do MainContext::default() rather than MainContext::thread_default(), that has me a bit confused, if they are equivalent then sure this would be rather helpful.

For an application that didn't configure a custom thread default main context this would end up the same.

Conclusion seems to be to make a new glib::futures module and add this as glib::futures::spawn(), and I guess move various other function in there too.

Has anyone started working in that direction?

I'm not aware of anybody having started such work


doc generation

It would be great if we could generate docs using jbuilder + odoc. @diml and @trefis said that there are some Jenga rules somewhere for this, it would be really nice if these would be imported in jbuilder.

This would be very useful for migrating https://github.com/moby/datakit and https://github.com/moby/vpnkit to use jbuilder by default :-)

WIP in #74

Feedback required: https://github.com/janestreet/jbuilder/pull/74#issuecomment-301509438

I've made a PR to make topkg doc happy so that topkg publish doc will push the docs to GitHub pages: https://github.com/diml/topkg-jbuilder/pull/3
That seems to work very well (yay!) and as indicated on that PR, the only missing bits are either:

a top-level index page, similar to what odig generates for http://docs.mirage.io/; or
support for turning a mld file into a top-level index file.

Any opinion?

Cool, if that works, we are getting closer to 1.0.0 :)

For the toplevel index file, something needs to be done in odoc first (/cc @trefis)

Here a snippet to generate a page similar to the index page of http://docs.mirage.io but for local packages only:
(* FIXME *)
let version = "1.0"
let name = "git"
let url = "https://github.com/mirage/ocaml-git.git" (* FIXME *)

(*---------------------------------------------------------------------------
   Copyright (c) 2016 Daniel C. Bünzli. All rights reserved.
   Distributed under the ISC license, see terms at the end of the file.
   %%NAME%% %%VERSION%%
  ---------------------------------------------------------------------------*)

(* Generator *)

type gen = { b : Buffer.t }

let addc c g = Buffer.add_char g.b c
let adds s g = Buffer.add_string g.b s
let adds_esc s g =
  (* N.B. we also escape @'s since ocamldoc trips over them. *)
  let len = String.length s in
  let max_idx = len - 1 in
  let flush b start i =
    if start < len then Buffer.add_substring b s start (i - start);
  in
  let rec loop start i =
    if i > max_idx then flush g.b start i else
    let next = i + 1 in
    match String.get s i with
    | '&'  -> flush g.b start i; adds "&" g; loop next next
    | '<'  -> flush g.b start i; adds "<" g; loop next next
    | '>'  -> flush g.b start i; adds ">" g; loop next next
    | '\'' -> flush g.b start i; adds "'" g; loop next next
    | '\"' -> flush g.b start i; adds """ g; loop next next
    | '@'  -> flush g.b start i; adds "@" g; loop next next
    | _    -> loop start next
  in
  loop 0 0

(* Generation sequences *)

let empty _ = ()
let ( ++ ) g g' b = ignore (g b); ignore (g' b); ()

(* HTML values. *)

let attv = adds_esc
let att k v g = adds k g; adds "=\"" g; v g; addc '\"' g; ()
let data = adds_esc
let el el ?atts content g = (* not T.R. *)
  let atts = match atts with
  | None -> empty | Some a -> fun g -> addc ' ' g; a g
  in
  addc '<' g; adds el g; atts g; addc '>' g;
  content g;
  adds "</" g; adds el g; addc '>' g;
  ()

(* Derived attributes *)

let href l = att "href" (attv l)
let class_ l = att "class" (attv l)
let id i = att "id" (attv i)

(* Derived elements. *)

let list el l g = List.iter (fun e -> el e g) l

let a = el "a"
let link ?(atts = empty) l = a ~atts:(href l ++ atts)
let div = el "div"
let meta = el "meta"

let nav = el "nav"
let ol = el "ol"
let li = el "li"
let p = el "p"
let h1 = el "h1"
let h2 = el "h2"
let span = el "span"
let body = el "body"
let html = el "html"

(* Output *)

let doc_type _ = adds "<!DOCTYPE html>\n"
let doc_typify do_it h = if do_it then doc_type ++ h else h

let buffer_add ?(doc_type = true) b h = (doc_typify doc_type h) { b }

let kbuf ?doc_type k h =
  let b = Buffer.create 65525 in
  buffer_add ?doc_type b h;
  k b

let output ?doc_type oc h =
  kbuf ?doc_type (fun b -> Buffer.output_buffer oc b) h

(*---------------------------------------------------------------------------
   Copyright (c) 2016 Daniel C. Bünzli

   Permission to use, copy, modify, and/or distribute this software for any
   purpose with or without fee is hereby granted, provided that the above
   copyright notice and this permission notice appear in all copies.

    IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
   ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
   WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
   ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
   OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  ---------------------------------------------------------------------------*)

let strf = Format.sprintf

let head ~style_href title = (* a basic head *)
  el "head" @@
  meta ~atts:(att "charset" (attv "utf-8")) empty ++
  meta ~atts:(att "name" (attv "generator") ++
              att "content" (attv "odig %%VERSION%%")) empty ++
  meta ~atts:(att "name" (attv "viewport") ++
              att "content" (attv "width=device-width, initial-scale=1.0"))
    empty ++
  el "link" ~atts:(att "rel" (attv "stylesheet") ++
                   att "type" (attv "text/css") ++
                   att "media" (attv "screen, print") ++
                   href style_href)
    empty ++
  el "title" title

let anchored_cl = "anchored"
let anchor_id ?(classes = []) aid =
  let classes = String.concat" " (anchored_cl :: classes) in
  id aid ++ class_ classes

let anchor ?(text = empty) aid =
  a ~atts:(href (strf "#%s" aid) ++ class_ "anchor") text

let name_list names =
  let li_pkg name =
    let l = strf "%s/index.html" name in
    let pid = strf "package-%s" name in
    li ~atts:(anchor_id pid) @@
    anchor pid ++ link l (data name) ++
    data " " ++
    span ~atts:(class_ "version") (data version)
  in
  let pkg name = li ~atts:(id @@ "name-"^name) @@ ol (list li_pkg [name]) in
  let compare x y = String.(compare (lowercase_ascii x) (lowercase_ascii y)) in
  let pkgs = List.sort compare names in
  let packages = "packages" in
  div ~atts:(class_ "by-name") @@
  h2 ~atts:(anchor_id packages) (anchor packages ++ data "available packages")
  ++
  ol (list pkg pkgs)

let index_page names =
  let style_href = "odoc.css" in
  let title = strf "Package documentation for %s" name in
  html @@
  head ~style_href (data title) ++
  (body ~atts:(class_ "odig") @@
   nav ~atts:(id "top") (data "\xF0\x9F\x90\xAB") ++
   h1 (data "OCaml package documentation") ++
   p (data "This is the documentation generated for " ++
      a ~atts:(href url) (data name) ++
      data ".")
   ++ name_list names)

let () =
  let index = index_page ["git"; "git-unix"; "git-mirage"] in
  output stdout index

Note: this is mostly copy/pasted from odig so appropriate credits should be given to @dbuenzli. Also it would probably be useful to have a better intro paragraph, displaying more details about the packages (e.g. author, maintainer, license, etc). I am happy to add this once we have a basic page in place.

Ok, it's bit more code than I imagined. I think this should be sorted for 1.0.0 though. I'll see if I can just take a html file generated by odoc and add some %s in it. That should do until odoc knows how to generate a global index.

@samoht looks like this is fixed. close?

This could be closed once https://github.com/janestreet/jbuilder/pull/224 is merged


Archive charts - enable downloading the chart

In archive.py, if there is a valid chart displayed there should be a way to trigger a download of the .svg object for that chart.

Add links to download and view stats just above the chart. Brings up stats with the same set of filters that are used for the charts shown.

Download link added with 47d88230e4f37eecbebf607ac1f662f0b42fcbfe


Replace snooze with NewRequeueKey

Changes
Adopt the NewRequeueKey to replace the snooze functions.
/kind cleanup
WIP until https://github.com/tektoncd/pipeline/pull/4129 lands
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[ ] Docs included if any changes are user facing
[ ] Tests included if any functionality added or changed
[ ] Follows the commit message standard
[ ] Meets the Tekton contributor standards (including
functionality, content, code)
[ ] Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes
NONE

/retest
I think this is a flake, let's see

Hello , I am trying to learn about EnqueueAfter or EnqueueKey of knative. Can you help me point in right direction.
Basically, inside pipelinerun controller,  can I schedule some piece of code without creating a goroutine (e.g. time.After or defer).

@ScrapCodes Probably not the best place to discuss.  Is there an issue or some place that I should read through for more context about what you are trying to do?  If you link it here or DM it to me on slack, I can try to weigh in.  In general, I see the enqueue functions as fairly low-level mechanisms, so we should probably only reach around the controller abstractions we have in place fairly intentionally, and consider whether it's possible to do the same within the abstraction or extend the abstraction for the use case you have in mind.

/easycla

Can I schedule some function, without creating a goroutine inside a reconciler?
e.g. if I use time.AfterFunc it creates a goroutine.
A reconciler may maintain its thread pool, in order to schedule something e.g. after 1 min check if there is update otherwise timeout.  Do we have this from knative?
In my PR, I am trying to timeout a run (i.e. it does not support retries) if the custom task controller does not respond within a short timeout. This can be achieved by scheduling a reconciling event for that PipelineRun and then checking if the last update time has elapsed the timeout duration.

cc @imjasonh @vdemeester
I've rebased this and it should be RFAL.
@CI-Gods 👇
/sacrifice 🐐

Hmm, let's try another 🐐 .  This looks like a flake.
/retest

I'm seeing this in the detailed logs, which seems very unlikely to be related to my change:
googleapi: Error 400: The disk resource 'projects/tekton-prow-1/zones/us-central1-a/disks/gke-tpipeline-e2e-cls1-pvc-1e50c020-13f7-4269-90d2-01c6ae94703b' is already being used by 'projects/tekton-prow-1/zones/us-central1-a/instances/gke-tpipeline-e2e-cls142-default-pool-6e83aa5f-n4cm', resourceInUseByAnotherResource

/retest

Weird, this one's reporting 0 Failed.  I wonder if this is somehow related to the large log files @sbwsg noticed.

/retest

/retest

/lgtm

@mattmoor btw this is the PR I was referring to when I started that whole thread about asking reviewers check look at the checklist requirements b/c I didnt feel the commit message had enough context - In this specific case looking at the PR it's hard for me to understand what NewRequeueKey is and why it replaces snooze (i think id have to go digging into the knative/pkg code to figure that out?)

Yeah, this is a bit better: https://github.com/knative/pkg/pull/2201

Ah that's great, thanks for the extra conext @mattmoor


Remove "Dropping unknown message"

As reported and fixed in pull request by @TobiasWalle to drop the unnecessary logging of "Dropping unknown message". This message is really only relevant for the browser extension and now pollutes the console for no particular reason if other libraries/frameworks use browser post messaging.

@TobiasWalle I just pushed 0.3.1 with your fix to npm, once ok can you close this issue?
Sorry that the pull request was closed but it always does that automatically on merge and I tend to forget that. So you can continue the chat here if you like.

@mreuvers Everything works fine now :) Thank you for accepting my pull request
The issue can be closed.

You're welcome and thank you for the pull request. :)


Rename withDepends to withNeeds

withDependencies is too long and GitHub already uses the concept of "need" for referring to job dependencies.

Method withDepends is used to append dependencies, it doesn't set "the" dependencies property. This conflicts with the naming schema, but there could be a remark on the docblock to remark this feat.


Updated Performance icon in Meshery UI

Notes for Reviewers
This PR fixes #8078 Updated Performance icon in Meshery UI
Signed commits

[x] Yes, I signed my commits.

Looking good, @vednp. Thank you.

Thanks @leecalcote for trusting me with this issue, surely I will try to improve with future contributions


[Cthulhu No Kami] New Sheet

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

New Sheet Details

The name of this game is: < Cthulhu No Kami  >  (i.e. Dungeons & Dragons 5th Edition, The Dresden Files RPG)

The publisher of this game is: < Studio Deadcrows  > (i.e. Wizards of the Coast, Evil Hat)

The name of this game system/family is: < Chroniques Oubliées > (i.e. Dungeons & Dragons, FATE)

[x] I have followed the Character Sheets Standards when building this sheet.

[x] This sheet has been made on behalf of, or by, the game's publisher.
[ ] This game is not a traditionally published game, but a copy of the game rules can be purchased/downloaded/found at: <   >
[ ] This sheet is for an unofficial fan game, modification to an existing game, or a homebrew system.

Changes / Description

Character Sheet Info Roll20 Internal Use only.

Hello @Zakarik! Could you provide me with a public link to where this game can be purchased/read? Our policies prohibit submissions that are not publicly accessible.

It's a crowdfunding finish here : https://www.gameontabletop.com/cf227/cthulhu-no-kami.html
He can be purchased here (in pre-order... And currently out of stock) : https://www.philibertnet.com/fr/cthulhu-no-kami/86457-cthulhu-no-kami-pack-revelations-2100000683734.html