DefaultRepoUnits doesn't seem to be loaded from app.ini

Gitea version (or commit ref): 1.14
Git version:
Operating system: FreeBSD
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[X] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[X] Not relevant

Log gist:

Description
DEFAULT_REPO_UNITS setting seems to have no effect. A glance at:
https://github.com/go-gitea/gitea/blob/c8d7ae1ee33e31ed15632a26c74ba9a3ea115043/modules/setting/repository.go
reveals that it isn't even loaded from app.ini as far as I can tell. Please advise.
Screenshots

Type, Gitea Release 1.11.4

Maybe you're looking for this?
https://github.com/go-gitea/gitea/blob/c8d7ae1ee33e31ed15632a26c74ba9a3ea115043/modules/setting/repository.go#L213
Cfg.Section() will automagically fill in the values from app.ini.
If you make any changes to app.ini, make sure you restart the instance. If you're having problems, maybe checking in in our Discord chat first would help.

Hi guillep2k, thank you for your comment. Agreed, it seems as it is being loaded. Nevertheless it doesn't work, i.e. always all units are added to new repositories. The settings in app.ini seem to be correct specifying:
[repository]
DEFAULT_REPO_UNITS=repo.code
and the app has been restarted multiple times. Nevertheless, all new repositories are created with all units activated. I took another look and in:
https://github.com/go-gitea/gitea/blob/4be7cf04054e5eab3b2cf4a63ad31a9333ab4732/models/repo.go#L1054
one can see that DefaultRepoUnits are referenced but I am afraid this is not the DefaultRepoUnits from:
https://github.com/go-gitea/gitea/blob/c8d7ae1ee33e31ed15632a26c74ba9a3ea115043/modules/setting/repository.go#L41
I believe those are rather the array of all repo units from here:
https://github.com/go-gitea/gitea/blob/3c07d03c0388d3b86138572401281b51f2db9282/models/unit.go#L74
Could you please confirm and if so - is somebody working on a fix? Thank you in advance. BR, -- Stanislaw

This feature was added in #8788 which is on the 1.12 milestone.


Separate the processing.Processors into a minimal set and the rest. O…

…nly use the minimal set when generating the concrete document types.
@bratseth PR

@gv PR

@hmusum PR

@aressem FYI this fixes a regression in 6.286, we should make sure this is included in the 6.287 release.

👍


Pathogen override (or break) commands like tabstop tabwith

I've tested many times, Idk how it broke vim on my system.
Environment:
My bundle dir is empty (for testing)
if I add 'execute pathogen#infect()' to my .vimrc next functions doesn't work,
but pathogen work properly
if I put this options before pathogen it still doesn't work,
if I comment execute line, everything works, but doesn't work pathogen,
please help
work on ubuntu14.04,
`execute pathogen#infect()
syntax on
filetype plugin indent on
set ignorecase
set smartcase
set relativenumber
set smartindent
set list listchars=tab:→\ ,trail:·
set number
set shiftwidth=4
set tabstop=4
colorscheme delek
`

I'm sorry, found that 'filetype plugin ident on', break it, but idk what this command do for pathogen

Now I clear understand, it was 'jedi-python', how it destroy code, idk


Subcommands documentation

Depends on the subcommands PR.
Added/updated docstrings to be inline with: http://sphinxcontrib-napoleon.readthedocs.org/en/latest/example_google.html

Cool - thx.


docs(README): fix example failed

"https://google.com" title is "Google" not "google"

Given that we're fixing this, how about also changing the Feature title from The Facebook to Google and the Scenario from Opening a social network page to Visiting a search engine? :)

Given that we're fixing this, how about also changing the Feature title from The Facebook to Google and the Scenario from Opening a social network page to Visiting a search engine? :)

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


real newbie! How do I make http://jsbin.com/ecenux/2/edit?html,css,js work, please?

Hello
I'm not sure whether this is the right place for my question, but it'll just have to do for the moment :-/
I want to make a pretty fraction like the linked example, but....
I've copied in the html and the css, but I don't know what to do next to make the smart dividing bar.
Would someone kindly explain what I should do next?
Thanking you in advance for your help (and the lesson)
regards
NotherCodingNovice

Best to file on stackoverflow. This issue tracker isn't for code help, but for software bugs in jsbin itself.


How do you modify verbosity?

Does Diagnostic logging respect the verbosity settings outlined in https://learn.microsoft.com/en-us/azure/azure-functions/configure-monitoring ? If so, which settings?

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

ID: bceaf516-a1b0-eb1e-e106-62c31db3e69c
Version Independent ID: abbbd2d6-e0fc-d370-f4a7-ac669fc4acd6
Content: Monitoring Azure Functions with Azure Monitor Logs
Content Source: articles/azure-functions/functions-monitor-log-analytics.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

@marlobello
Thanks for your feedback! We will investigate and update as appropriate.

@marlobello Yes, all verbosity (None, Warning, and Verbose) is supported as documented here. You can use the CLI command to change the verbosity.

@marlobello Hope the above helps and clears things up. We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


Release 1.1.0 - big rewrite

Changes finding of first jobs for all assays to an eggd_conductor job
After querying Jira tickets in a queue, only stores tickets for sequencing runs for relevant assay types within the audit period (+ 5 day buffer) to compare to 002 projects to make things a lot quicker
Removes references and functions relating to SNP runs (including in html), making logic a lot simpler
Changes finding last jobs per assay via a the name of the job for that assay given in the config file (closes #23)
Splits each assay TAT plot by week via plotly subplots, including weeks with no runs
Adds ticket hyperlinks in the TAT plot X-axis labels to link to the run's Jira ticket (closes #21)
Adds date and time report was generated (closes #22)
Gets changelog of a Jira ticket so we can add extra statuses to plots in future
Adds example new config to README and update description of how it works

This change is

Hello @rklocke! Thanks for opening this PR.


Add Windows Support

Coming from https://github.com/opensearch-project/opensearch-plugins/issues/95, add Windows support.

[ ] Passing CI on Windows
[ ] Documentation

@lezzago Are we clear to close this issue?  Thanks!


Not working?

In newer versions of Automatic1111 it wont work?
*** Error executing callback ui_tabs_callback for ...\stable-diffusion-webui\extensions\sd-webui-panorama-tools\scripts\panorama-tools.py
Traceback (most recent call last):
File "...\stable-diffusion-webui\modules\script_callbacks.py", line 180, in ui_tabs_callback
res += c.callback() or []
File ",,,\stable-diffusion-webui\extensions\sd-webui-panorama-tools\scripts\panorama-tools.py", line 268, in on_ui_tabs
sendSketchToTxt2ImgControlNet.click(fn=None,inputs=[],outputs=[sendto_controlnet_inputs["txt2img"][0]], show_progress=False,
IndexError: list index out of range

Nevermind (for future stumpers -if any-):
Solved once ControlNet extension was correctly installed.
I would suggest not to mark it as recommended but stated as pre-requisite instead  (https://github.com/Flyguygx/sd-webui-panorama-tools#recommended-extensions)

This is a bug actually, it's supposed to just grey-out those buttons if ControlNet isn't detected but it looks like that check is missing in the initialization code which causes that error.
Fixed in commit d60055b


Requirement for beta kata approval needs to be more transparent

I constantly get asked by people I know "when will my beta kata get approved?", and honestly, not even I know either.
I think a comprehensive list of "score required to make a kata able to be approved" along the table that shows all honor sources and privileges would be helpful to pretty much everyone, especially power users. There are several thing we'd really want to know:

How many score (upvotes) are required before I can approve a kata?
How does 'somewhat satisfied' and 'not satisfied' affect this process? Because I've seen katas like this which has way too many solves and upvotes and nevertheless is still showing "Testing & feedback needed".
How does translations affect kata approval? Because again, while I appreciate @GiacomoSorbi 's effort to translate lots of beta katas in many languages, approving them seem to just make a kata impossible to move past beta, which makes some of us joke that 'don't approve translations before your kata is approved'.
How much extent does the number of already published number of katas affect kata approval? I've seen a table about it somewhere on CW or here (possibly by @kazk), but I couldn't find it again anymore. Having this information handy would be really helpful.

agreed, i hated the process because it's not clear at all, i think it should be automated

people are also total assholes about it

@Voileexperiments

I've seen a table about it somewhere on CW or here (possibly by @kazk), but I couldn't find it again anymore. Having this information handy would be really helpful.

The following table is from https://github.com/Codewars/codewars.com/issues/866#issuecomment-288581775.
Note that I never got a reply from @jhoffner if this is correct interpretation, so this might be wrong.

Level
Satisfaction %
Required Votes by # of Approved Kata

<10
<20
<30
30+

White
90+
12
10
8
6

Yellow
85+
10
8
7
5

Blue
75+
8
6
5
4

Purple
70+
5
4
3
3

Based on https://github.com/Codewars/codewars.com/issues/757#issuecomment-270100977 and rounding to nearest integer.

The starting point of the new documentation is awaiting for @jhoffner's review and licensing. We can add more information about the beta process there.

@kazk this should be implemented as an algorithm

good work

How many score (upvotes) are required before I can approve a kata?

This value is dynamic based off of overall ranking feedback and what voting privileges someone has. You can have up to 4x voting power. @kazk's chart looks to be correct.

How does 'somewhat satisfied' and 'not satisfied' affect this process? Because I've seen katas like this which has way too many solves and upvotes and nevertheless is still showing "Testing & feedback needed".

It only affects the satisfaction score. If a score is too low, a kata cannot be approved. The limits here are also based off of ranking feedback.

How does translations affect kata approval? Because again, while I appreciate @GiacomoSorbi 's effort to translate lots of beta katas in many languages, approving them seem to just make a kata impossible to move past beta, which makes some of us joke that 'don't approve translations before your kata is approved'.

If anything translations should help the process, because more languages means more users solving which means more feedback/voting. How have you seen translations hurting the process? You will note g964's kata tend to come out of beta very fast and it's because he translates his kata into so many languages.

How much extent does the number of already published number of katas affect kata approval? I've seen a table about it somewhere on CW or here (possibly by @kazk), but I couldn't find it again anymore. Having this information handy would be really helpful.

@kazk's chart above shows. The more kata you have approved, the less restrictive the system is on approvals since you have shown (in theory) that you consistently produce quality content.

sounds way too complicated just make it really simple -> when it get enough upvotes it becomes approved

and make it automatic because the seeming subjectivity is so retardedly annoying

if it falls beneath a certain amount of upvotes it gets put back into beta

this is a subjective part of codewars and no surprise it blows

@kazk @jhoffner Thanks for the information. However, based on my actual observation the above system is not working quite well in practice:

For high-difficulty katas the people solving it are power users anyway, so you can expect them to behave as ideal person and give straight 100% score before approval
For the lower end of katas (mostly white katas), yes, there are lots of solves, but also people that put in "somewhat satisfied" votes (I guess they think the kata is too easy) and then run away forever. These dead weight easily drags down the overall score, and not even 4x votes can counteract that. In practice, white katas usually stay around 80% score even for good ones, so lots of them are pretty much doomed unless all the votes are cleared.

So, I think maybe the required percentage should be reversed (75/80/85/90 instead of 90/85/80/75)? Because based on actual statistics, clearly white/yellow katas have lower overall score percentage than blue/purple katas.

@jhoffner

How have you seen translations hurting the process?

When the translations are low-quality and the translator isn't responsive. No notification, too busy, no longer active, etc. This is obvious, but the damage is catastrophic when one translator produces multiple low-quality translations and doesn't maintain them.
g964's kata doesn't suffer from this because the author is the translator for most of the languages and maintains well.

@Voileexperiments

In practice, white katas usually stay around 80% score even for good ones

The satisfaction % tends to drop after the approval regardless of the color and usually the easier ones drop more, but this is irrelevant when discussing about approval process.
Do you think a 8 Kyu kata with 75% satisfaction rating should be approved?
Note that this number is during beta and votes are mostly from "power users".
I agree that the current system isn't ideal, but I haven't seen a proposal that's realistic to implement and works better.

Do you think a 8 Kyu kata with 75% satisfaction rating should be approved?

Ideally the one who approves the kata (i.e power user) should check the obvious things about the kata before approving. But it seems that some people approve beta katas without even first solving said kata :V The approval process is not as light as many of us thinks, and when approving a kata we really should be cautious and careful.

it's easy to fix -> have a threshold satisfaction and threshold number of upvotes -> if both thresholds are met approve -> if a kata or a translation fall beneath put into beta (if translation just put the translation in beta, if that's not possible then delete the translation)

Shouldn't the percentage that votes affect satisfaction rating scale like points? Meaning someone with 4x vote power would affect the satisfaction rating 4x.
For example, a new user's(1x vote power) negative vote affects the satisfaction rating by 25% of a user with 4x vote power. So if a kata that has a 100% satisfaction rating with 9 votes gets a negative vote from me, it will have 10 votes and a 90% satisfaction rating. If instead the kata received a negative vote from a new user, it would have 10 votes and a 97.5% satisfaction rating since he would have 4x less vote power than I have.

no definitely not way to complicated way too subjective

codewars does one thing very well -> it provides user generated coding challenges to other users. that's all it does. there is no need for a fancy approval system. just a good search system, efficient running of code, and that's it

does youtube have some fancy system for monetizing? no it's stupid simple

does youtube approve certain videos and not others? no it just ranks them by views and likes and related content

With regards to beta Kata approval, I would like to bring this suggestion back into the light.  The system as described in the proposal should minimize the chances of an irresponsible power user / moderator approving a substandard Kata that is overrated by "new" users.

that also looks way too complicated, complicated is bad

google is also based on a really simple concept

it's easy to fix -> have a threshold satisfaction and threshold number of upvotes -> if both thresholds are met approve -> if a kata or a translation fall beneath put into beta (if translation just put the translation in beta, if that's not possible then delete the translation)

Automating the process seems like a viable idea.  @jhoffner perhaps this should be considered in the future.  Only thing to note though if the process really does become automated - the thresholds for "automatic approval" would need to be even higher, e.g. 95%/90%/85%/80% and the minimum number of upvotes would have to at least double.  We don't want the system to "objectively" approve a substandard Kata that just happened to receive an influx of upvotes from inexperienced Codewars users subjectively voting on the Kata based solely on their enjoyment/satisfaction of solving it and not on the quality.
@ericswenson15 As for putting a Kata back into Beta when the satisfaction score drops below the threshold, consider the impacts it would have on the users' ranks and honor points.  If a high-kyu approved Kata is put back into Beta by the system then the users who have solved it would immediately lose the huge amounts of rank and honor they gained when solving it as an approved Kata which would lead to a large number of frustrated and confused users.

true it would impact their rank and honor negatively, they would drop in honor for sure. very necessary if they write a kata that doesnt meet the standards of other users on codewars

this group would not be large, and is currently greatly outnumbered by those experiencing frustration with the approval process. also it's totally necessary, if they write a kata which used to be good enough and now no longer is, then their honor should be docked, and restored if they get it back out of beta. it's idea capitalism, survival of the fittest

if enough people enjoy the kata then that's a good reason to have it approved. it's not all about production level quality, there is also idea exploration, fun, exploration of libraries, and other things which should be approved if enough users think it's good

I was talking about the rank and honor of the users who have solved the Kata not just the author.  Consider how the average solver would feel if he/she suddenly lost a lot of rank and honor just because a Kata they solved was put back into Beta (which would entirely be the author's fault, not the solver's)?

i dont give a shit about how they feel and they probably won't notice

the feelings of people trying to actively add kata, which is the literal backbone of codewars, are much more important to me

they probably won't notice

I can prove from experience that that's certainly not the case.  Even though I currently have like 25k+ honor, I most certainly notice it when it drops from something like 25750 to 25748.

they will understand if they've tried to create a kata and if they havent they are relatively much less valuable to the platform

that's a weirdly high sensitivity i think most people arent that concerned

not necessarily in a bad way but it is definitely not normal

alright enough we agree it should be automated that is good

What would be the criteria to approve a kata? Can an automated process catch duplicate katas? How would it evaluate what is a duplicate? Automating the process sounds complicated.
There are already 3425 approved katas, there isn't a shortage. Though there can't be too many high quality katas. I trust the people who have completed a large amount of katas/moderators to have higher standards and more insight than an automatic approval system could. I doubt there is enough time/resources to create such system either.
I agree with @Voileexperiments. There should be a clear standard that katas should meet before approval. Randomized tests is a significant one that I've seen but the other requirements should be outlined somewhere officially, suitably in the new documentation as suggested by @kazk.

duplicates should be handled how youtube handles copyrights, that the original can call out others for copying or being duplicates, but if he or she doesnt then they get left alone

automating is easy, have 2 if statements that checks the number of votes and the ratio of likes to dislikes and if these 2 numbers are above a certain threshold they are approved and if not they are put back into beta

it's not all about production level quality

Disagree. Quality does matter. If you lower the bar then all that will happen is every man and his dog will just publish awful Kata just because they can;  and the entire site deteriorates.
On the contrary, I think inactive Kata (Beta or not) with low satisfaction (below some threshold) should be put to sleep. Users who already solved them can keep their points but hibernated Kata should not be visible anymore unless the author updates and re-publishes it.

On the contrary, I think inactive Kata (Beta or not) with low satisfaction (below some threshold) should be put to sleep.

I think that is already done by occasionally retiring Kata, though I agree that it should perhaps be done a bit more often, especially at the lower levels.

There are some beta katas (and some broken JS katas, see #940 for a comprehensive list) that really should be retired or something.
However, there are also lots of katas that is actually pretty okay, but nevertheless still gets stuck by the dead weight (protip: there are lots of them). Putting them to hibernation is obviously a bad idea, but in the current system they're just going to stay at the status quo forever and there's nothing anyone can do to offset the satisfaction rating by much.

Thanks @Voile for your comment to my feature request some hours ago. So my question/suggestion once again, i think it's the right place here (@jhoffner): What about an entry like "Waiting for approval" at "Kata Search -> Sort by:"? For example at the moment i completed 1512 beta katas and probably some/a lot of them are ready for approval - but i don't know which. So this point would be helpful to make them visible;-)?!

Wow, this is a chatty thread. Kinda hard to extract the useful bits but I'll try to summarize

When the translations are low-quality and the translator isn't responsive. No notification, too busy, no longer active, etc. This is obvious, but the damage is catastrophic when one translator produces multiple low-quality translations and doesn't maintain them.
g964's kata doesn't suffer from this because the author is the translator for most of the languages and maintains well.

I can see that, though this just makes me think that a kata should not be able to be approved if there are pending translations. This of course would cause kata to take even longer to come out of beta, which sucks - but it would force pre-approval translations to go through a more proper QA process. Of course translations having their own beta process would be ideal here but it's a lot of work and I don't have the bandwidth yet.
Forcing translation approvals could lead to authors rejecting translations just so they can have their kata approved so IDK if this is a great idea.

but also people that put in "somewhat satisfied" votes (I guess they think the kata is too easy) and then run away forever. These dead weight easily drags down the overall score

I agree, something needs to be put in place to try to separate the idea of them not liking the kata due to issues vs them just not liking the kata. We could try to make the concepts more well defined but I'm sure frustrated users will downvote it due to issues regardless.
Perhaps one change that could be introduced is a special notification for when an issue is closed, prompting users to reconsider their vote if it was a negative one.

automating is easy, have 2 if statements that checks the number of votes and the ratio of likes to dislikes and if these 2 numbers are above a certain threshold

Standards use to be static but was changed. If the standards were static, those standards would be too high and cause higher ranked kata (purple) to take forever to come out of beta. Ideally the standard could be higher for purple/blue kata but it just isn't practical. The system became more complicated over time to counteract beta purgatory while trying to minimize low quality standards. The easy ability to quickly reason about how many more votes are needed was a compromise that was made for this.
As for an automated process - I don't think the actual approval stage is the major bottleneck, and adding a human element to at least give a chance of catching things that can't be determined automatically (or at least not without a ton of new work to do automatically) is better than nothing.

if it falls beneath a certain amount of upvotes it gets put back into beta

Satisfaction score and issue count is enough to indicate that a kata isn't great. However I could see value in sending out a notification to an author that their kata was demoted due to quality issues and that would encourage them to fix it faster. However issues are often for a specific post-approval translated language and I don't see why solvers of other languages should be docked their honor/ranking because of this.
I think this issue is hard to iterate on without improving translations by them having their own beta process - which is ideal but a lot of work and not likely to happen any time soon.
Another feature that would be useful is tracking towards which language an issue was logged against, this of course would only be useful if there was a way to demote a specific language within a kata.

Shouldn't the percentage that votes affect satisfaction rating scale like points? Meaning someone with 4x vote power would affect the satisfaction rating 4x.

IDK maybe but I'm leaning towards no. Having a power user's opinion count more towards getting something out of beta makes sense to me, but having their opinion matter more than others when it comes to "general satisfaction" doesn't. I realize it might not be the most obvious distinction - but for approvals we are relying on a user's CW experience to help us determine if something reaches our standards. Experienced users will have a better understanding of this. The overall satisfaction score however is more gauging overall user enjoyment of the kata regardless of how experienced with CW they are, which makes sense since experienced or not, someone's opinion should matter the same in terms of how much they enjoyed something.

get rid of somewhat approved that is a useless rating

everyone should have the ability to improve a kata like wikipedia

I don't think the actual approval stage is the major bottleneck - is absolutely delusional

totally disagree the human element is the most annoying part, and it's easy to automate just use user satisfaction

adding a human element to at least give a chance of catching things that can't be determined automatically (or at least not without a ton of new work to do automatically) is better than nothing - this is the worst part it's subjective and slow and annoying and frustrating and everyone hates it besides the approvers

which is why it's constantly coming up as an issue, and it's easy to fix

haha put a rating system on your approval system and let's see how that goes

if kata approval standards could be as low as the approval system rating is every beta will come out

thanks for responding @jhoffner

your community appreciates it and will be better for it

@ericswenson15

I don't think the actual approval stage is the major bottleneck - is absolutely delusional

There are 16 kata currently awaiting approval. Yesterday it was 27. There are 2552 kata currently in beta. Yes, it is not the bottleneck. This isn't up for subjective debate, it's simple math.

it's easy to fix

The amount of times I have witnessed you, either on Github or Gitter, think something was easy or didn't make sense - when the reasons why things aren't simple or did make sense were blatantly obvious - is profound. The amount of energy that many other people have spent showing you what you should have been able to reason about on your own - is far too great.
Respectfully, I would appreciate if you can stop using Github as a place to chat it up and confine your responses to single well thought out and constructive ideas. At least 26 of the 35+ comments you made are one liners and many of these are simple emotional responses that aren't constructive. It's just noise and you are clogging up all of my feeds and wasting mine and everyone else's time. If you take the time to write a single thoughtful comment then maybe it will be of more substance and of less knee jerk emotional responses - responses that make you come off sounding very immature.

it's easy to automate just use user satisfaction

For the reasons above I can't be bothered to take the time to point out to you the various edge cases that the human element is meant to capture as a last line of defense, or why the simple dimension of user satisfaction is not enough (or the ways in which user satisfaction as its own system has flaws of its own that need to be addressed). It wouldn't be worth the discussion anyway, as I pointed out above, it's not the bottleneck. The system started off simple and has gotten increasingly complex for specific reasons.  "I can't be bothered to take the time to point out to you" to me means you don't have any good reasons.

you're immaturity is what makes it take so long for you to respond

try to keep up it's 2k17

and bare witness = be useless on the sidelines

and look at the users on this thread clearly people think this is an issue

also if emails are bothering anyone use the unsubscribe button under notifications to stop it, i did that

Just because you are spamming the issue board (which is extremely poor behavior), everyone else should stop getting notifications?
I get the feeling that you feel personally offended by something, because this is aggressive tone is absolutely uncalled for. And you aren't exactly backing up your attitude with Linus Torvalds-level credentials.
I suggest you take a step back, calm down, and think about how you are coming across to everyone else who is reading this thread. This isn't a chat forum, it's a place to discuss issues and solutions.

i unsubscribed it still emailed me

oh every time you comment it auto subscribes, and i'm not spamming haha shut up

oh you can leave a reaction and it won't auto subscribe you, personally offended i mean not really there's nothing much personal here, and i suggest you contribute useful ideas rather than comment uselessly.

but @OverZealous yah let's compare credentials -> I went to princeton, got a 1600, 137 iq, played varsity soccer for princeton -> 4th fastest runner -> published for research at MIT -> 17 months full time professional software dev exp -> 95 wpm dvorak -> 38.5 min 6 mile time -> not fat

your turn

Unfortunately I had to block eric for obvious reasons that I'm sure everyone else understands. I hate having to block people and don't do so lightly, but I don't think any of us have time for this nonsense.
To confirm that the rest of us are on the same page. This thread, as I understand it, is about getting to the approval phase of the beta process. The beta process up to that point is the bottleneck (obviously), the approval phase - the phase that once reached requires someone to manually approve a kata, has no need for automation as the community has gotten pretty good at keeping on top of that. We only have 16 kata currently in this phase. This phase is purely a last line of defense to have someone experienced in the community to give the kata one last look over. Unless someone can offer strong evidence as to this part of the phase actually being a bottleneck, I think its most productive to discuss other parts of the process and how we can keep quality high while overcoming some of the issues that cause kata to remain in beta for too long.
As for the true original purpose of this thread, which is to document how the system currently works - this should definitely be included within the new documentation site which is a WIP.

Unfortunately I had to block eric for obvious reasons that I'm sure everyone else understands.

Good riddance 👏 👏 👏  However, next time, before blocking a user, consider reporting him/her directly to GitHub which I have just done.

Speaking of which, should I open a new issue about (maybe) revising the current beta approval requirements so as to facilitate a more coherent discussion?

I think we should also collect past proposals somehow so that we can build on them and avoid people coming up with already discussed ideas.

So, I think maybe the required percentage should be reversed (75/80/85/90 instead of 90/85/80/75)? Because based on actual statistics, clearly white/yellow katas have lower overall score percentage than blue/purple katas.

@Voileexperiments as @kazk pointed out, would you want 75% white kata to be approved? I understand there is the issue with dead votes that stay around after a fix is made, but that withstanding.
I guess what I'm getting at, maybe some kata just aren't good enough right? Is anyone consistently seeing kata lower than say, 85% that are actually really good?

should I open a new issue about (maybe) revising the current beta approval requirements so as to facilitate a more coherent discussion?

Probably a good idea, this is likely to be an ongoing brainstorm.

@jhoffner As the usual flow that happens for beta katas "bad beta katas lower than 90% is approved quickly" should seldom happen:

For most of the times, new beta katas are solved by regular power user residents first, and not lots of other users. Power users rate accurately AFAIK, meanwhile the dangling votes are from other users. So a bad kata would have an incredibly bad score, while good katas can have any score between 80% to 100%, especially if the kata suffers from early issues (or the kata is 'too easy')
The power users will file issues and suggestions if there are rooms for them. A kata can't be approved with unresolved issues, so unless somebody erroneously resolves all the issues while they're not fixed, the will be stuck at beta
We still need a 6k moderator to approve kata. If a moderator don't look at the discourse for possible problems, solve the kata first to go through the kata, check if random tests exists, etc... then obviously the moderator is not doing his job very well
As a last resort, 6k moderators can always edit the kata and fix the stuff themselves. Maybe we can add an "un-approve" functionality there, but as long as the first 3 points are working properly, we shouldn't need to reach this point

Anyways, my original point is, for blue/purple katas only a few votes are required for approval, and nobody except power users will solve them while at beta anyway, so having a lower satisfaction rating requirement than white/yellow katas does not have any noticeable effects. Meanwhile, there are too many white/yellow katas stuck at beta but are nevertheless quite decent due to the high 90% rating requirement. Having lots of dangling katas at beta that has worth but would never be able to be approved seems like occupying everybody's resources to me.

I'm not really sure how much what I'm about to say plays into the issues we are discussing, but it feels like "How satisfied are you with this kata and its quality?" needs to change. "Quality" is misleading, at least in the way that it probably comes off. If you have an issue, you should file and issue. Issues can be fixed. If you think the kata is great but has a basic issue that can be fixed, then you should be marking it as "very satisfied" but has an issue I would think, but I don't know if anyone would think that way with how it is now. If you think the content of the kata is poor, or it's just so poorly implemented that it would have to be redone from the ground up, then yes I think the satisfaction rating should reflect this.
I bring this up because as we talk about the adjusting the satisfaction quality bar (which was arbitrarily set in the first place), we are now incorporating real user data but I'm feeling like that data is somewhat tainted by the overloading of the use-case (General Kata Concept quality vs Kata Implementation Qualities that can be easily fixed).
I guess to a degree I feel like lowering the quality limit might make sense, but on the other hand it might just be us sticking on a band-aid to a rating feature that needs to be improved.
A few questions I have, since you guys know the content better than I do these days:

How often do you think you see good kata (not just kata with no issues, but actually good/useful kata) rated way to low in your opinion? (lets say lower than 80%).
How often do you think poorly conceived or just plain useless kata are making it out of beta?
Which is a stronger feeling to you: You feel too many great kata are stuck in beta, or you feel like too many bad kata are making it out of beta?
Of the kata that you feel like are bad, is it more often that they seem bad due to their underlying concept/implementation being too weak or because they just have too many issues with them in general (but the concept its trying to challenge you on is sound?)

I just kind of spit these out, they are all very subjective data to collect so not sure how much we can rely on me getting a only a few of you to tell me your thoughts on these, but it would be nice to get a general feel for where we are at content wise (especially with all of the newer content).
I also wonder if something like  a simple boolean "Assuming all issues were fixed, would you recommend this kata to a friend?" rating would be better.
Beyond all of this, I also wonder how much of this would just be solved by adding some tweaks here and there to encourage power users to fix more kata. One idea is to make it easier to find kata waiting for issues to be fixed along with a reward for fixing the kata. The main issue there is how much of a rabbit hole would it be to reward power users for fixing a kata and do it in a way where they can't just close an issue and get points without actually doing the work.

Power users rate accurately AFAIK, meanwhile the dangling votes are from other users.

Do the rest of you agree with this observation? If thats the case then maybe it does make sense to incorporate 2x/3x/4x voting into the satisfaction score.

Another question for those who have been around long enough to know. Did the somewhat recently satisfaction score actually improve the quality/process or make it worse in your opinion?

I'm not really sure how much what I'm about to say plays into the issues we are discussing, but it feels like "How satisfied are you with this kata and its quality?" needs to change. "Quality" is misleading, at least in the way that it probably comes off. If you have an issue, you should file an issue. Issues can be fixed. If you think the kata is great but has a basic issue that can be fixed, then you should be marking it as "very satisfied" but also filing an issue I would think. However I don't know if anyone would think that way with how it is now. If you think the content of the kata is poor, or it's just so poorly implemented that it would have to be redone from the ground up, then yes I think the satisfaction rating should reflect this.

Unfortunately the UI is suggesting the contrary:

@jhoffner

it feels like "How satisfied are you with this kata and its quality?" needs to change.

I agree. We need objective feedbacks during beta process for QA and satisfaction is subjective by definition. The minimum criteria of qualified kata that's followed by every participating users needs to be officially defined.

If you think the kata is great but has a basic issue that can be fixed, then you should be marking it as "very satisfied" but also filing an issue I would think. However I don't know if anyone would think that way with how it is now.

I do something like that.
                   ┌─────────┐
       ┌──────────▶│Beta Kata│◀──────┐
       │           └─────────┘       │
       │                │            │
       │                ▼            │
   ┌──────┐         ┌───────┐    ┌───────┐
┌─▶│Report│◀────────│Broken?│    │Suggest│◀─┐
│  └──────┘         └───────┘    └───────┘  │
│                       │                   │
│   ┌────┐    ┌─────┐   │                   │
│   │Rank│◀───│Solve│◀──┘                   │
│   └────┘    └─────┘        ┌────┐   ┌───────────┐
│      │                 ┌──▶│ +1 │──▶│Improvable?│
│      ▼                 │   └────┘   └───────────┘
│  ┌──────┐           ┌────┐                ▲
└──│Issue?│──────────▶│Rate│────────────────┘
   └──────┘           └────┘
                         │   ┌────┐
                         └──▶│ -1 │
                             └────┘

I usually don't vote "Somewhat Satisfied". Sometimes there're katas that I personally disagree or dislike, but I don't think the author deserves the penalty.

Power users rate accurately AFAIK, meanwhile the dangling votes are from other users.

Do the rest of you agree with this observation? If thats the case then maybe it does make sense to incorporate 2x/3x/4x voting into the satisfaction score.

I agree that power users rate accurately based on their standards at the time. So whenever a power user down votes, the kata usually deserves it.
But if "dangling votes" mean negative votes persisting even after the root issues are resolved, I think power users do contribute to them because they usually move on to next kata and don't come back.

I'll try to answer other questions tomorrow after thinking about them little more and if I have something to say.

I'm not really sure how much what I'm about to say plays into the issues we are discussing, but it feels like "How satisfied are you with this kata and its quality?" needs to change. "Quality" is misleading, at least in the way that it probably comes off. If you have an issue, you should file an issue. Issues can be fixed. If you think the kata is great but has a basic issue that can be fixed, then you should be marking it as "very satisfied" but also filing an issue I would think. However I don't know if anyone would think that way with how it is now. If you think the content of the kata is poor, or it's just so poorly implemented that it would have to be redone from the ground up, then yes I think the satisfaction rating should reflect this.

I usually interpret the "quality" of a Kata as how well it is implemented in terms of an unambiguous Kata Description, code coverage etc., and as @Voileexperiments said, that impression is more or less from the UI itself.  If I see a Kata with 20 or less unique, distinct fixed assertions and no random assertions, I almost always vote "Not Satisfied" (>99%) without thinking twice and raise an Issue at the same time.  Otherwise, I usually vote "Very Satisfied".  Sometimes, when a Kata is well implemented but I think the concept is very crappy and I didn't have a good time solving it, I would rate it as "Somewhat Satisfied" but I almost never choose "Not Satisfied" purely due to bad content and not bad implementation.

@jhoffner

Probably a good idea, this is likely to be an ongoing brainstorm.

Can I open a new issue? I'm tired of scrolling unnecessarily :(
I wrote a small program that uses GitHub API to retrieve all comments and filter them.
Then outputs each comments prefixed with the user and the link to the original comment in this issue.
@username commented <- "commented" will be a link to the original comment

comment body

I'd like to be able to link to a specific comment, so I'm going to add a feature that posts each comment separately using POST /repos/:owner/:repo/issues/:number/comments.
What do you think? People can continue discussing on this issue while I work on this.

Can I open a new issue? I'm tired of scrolling unnecessarily :(

We can, or I can go back and delete all of the drama that happened above. I usually come to this thread from a  "view in github" email link so it scrolls for me.
This issue is off-topic from its original purpose so we can give it a shot and see if it's readable.

Thanks for the feedback everyone. It seems like everyone is using the voting a little bit differently (which is expected). In some cases very differently (which is not ideal). I was trying to go back over some of the internal discussions around this feature and it turns out it was all the way back on July 1st, so almost a year. Back then we had the system where during beta we asked "ready, minor issue, major issue" and then after beta you could simply just up vote, and ready votes and up votes were part of the same system. So this change was originally meant to try to structure voting into a single system, with a score that was more useful than up votes, since 100 up votes wasn't necessarily better than 20 up votes (the kata may just have been around longer, and most up votes came from the ready beta voting). Another issue was that if you wanted to downvote a kata, you had to say minor/major issue, but we forced you to specify an issue. A lot of users had the same issue as others, so we ended up with tons and tons of the same issue being filled.
So in retrospect I'm still happy with the satisfaction score relative to how it was before, but I think clearly it's still not good enough.

If I see a Kata with 20 or less unique, distinct fixed assertions and no random assertions, I almost always vote "Not Satisfied" (>99%) without thinking twice and raise an Issue

I totally can understand why you would do this @DonaldKellett and in retrospect to the original reasons for making this change, it doesn't seem to far off from how this feature was intended. I think over time I have forgotten those reasons and the distinctions between satisfaction being more about "would you recommend this to a friend?" type of satisfaction, VS "do you think this kata's test/language quality is good enough?" type of satisfaction have become more apparent.

Sometimes, when a Kata is well implemented but I think the concept is very crappy and I didn't have a good time solving it, I would rate it as "Somewhat Satisfied"

This is what I'm trying to get at. I personally think that satisfaction score should reflect how many users actually enjoyed the kata and found it valuable, not necessarily just how well it is constructed. If you thought the kata sucked, personally I think you should be giving a somewhat satisfied at best (though we may just want to kill the 3 vote system since "somewhat" is seldomly used anyway).

We need objective feedbacks during beta process for QA and satisfaction is subjective by definition

I agree and this point also illustrates the concept of while in beta vs out of beta. I would still like to find a system that works for both, to keep things simple and consistent - but it's a challenge because the contexts are not the same.
I'm leaning towards getting rid of generic voting all together and asking a few basic questions, that depending on their answer maybe they expand (so I guess a mini exit survey).

Did you find any issues with this kata?

Duplicate of another kata
Test cases are not thorough enough
Description is hard to understand
General concept of the challenge is not useful (this one is more subjective, possibly redundant with would you recommend to a friend)
There is a bug in the test cases

Do you have any suggestions for how this kata could be improved?
Assuming any issues were fixed, would you recommend this kata to a friend?

The 2nd top level question (recommend to a friend) may not be necessary if "general concept is not useful" makes sense as an issue.

@jhoffner

We can, or I can go back and delete all of the drama that happened above.

Deleting might be good enough, definitely easier.
Maybe save the current state (screenshot/save as PDF etc.) for the record?

I usually come to this thread from a "view in github" email link so it scrolls for me.

Yeah, but what about users who hasn't participated yet? Seeing those comments is really discouraging and uncomfortable. People might not even scroll to your comment about blocking him.
I didn't really get the recent "code of conduct" thing, but I understand it better now :(
The community can get hurt and it's hard to recover.
For example, I think the mood of Gitter channel changed completely and many people just left.
I did because some of his off-topic comments offended me and the amount of noise became unbearable. Why discuss political/racial opinions on Codewars channel? :/ Aggressive tone doesn't help :(
I know you're busy and don't have time to monitor how users behave, so I'd recommend coming up with official rules (see also #187) before toxic behaviors kill the community. Maybe something minimum like Ruby's is enough for now.

Ugh, well now the thread just has a million deleted comment line items.

I'd recommend coming up with official rules (see also #187) before toxic behaviors kill the community. Maybe something minimum like Ruby's is enough for now.

Yeah I agree. Though the docs section of CW is terrible, so we need to also prioritize getting the new docs site ready. I'm out of town again next week for a workshop, I've got a lot to catch up on still. I want to help get contribute some UI updates to the docs you built so that we can get that out ASAP.

It's fine, this thread has been cleaned up, we can start a new one and just reference this one in case anyone feels like getting fully caught up to speed. No need to copy and paste comments (maybe we can cherry pick a summary of the key points?)


OSM Tiles not displaying

Hello,
Unfortunately OSM tiles aren't displaying at all in the app. I have a version 2 T-watch. The app displays that it connects (to a server?) then appears to count something but no data is displayed. Could you please tell me how I can begin to debug this?
With thanks and best wishes.

First check the tiles are being stored correctly on the SD card. You can see if files are being created using Thonny by interrupting execution and looking at devices files. Or simply extract the card and look at the files on your laptop etc. They are PNG files so  you should be able to display them.
The usual problem is that the tiles are not being fetched and sometimes empty tile files are created - you need to delete these. Also you can check the tiles server is working correctly by typing the URL into a browser - see apps/openstreetmap.py for URL.
I am afraid that you are on your own for the next few weeks as I am going to be away.


Error upon compiling small .so program on g++8

Simple reproducible example:
logreg.h:
#pragma once
#include <iostream>
#include <xtensor/xarray.hpp>
#include <xtensor/xio.hpp>
#include <xtensor/xview.hpp>
#include <xtensor/xexpression.hpp>
#include <xtensor/xnpy.hpp>
#include <xtensor/xsort.hpp>
#include <xtensor-blas/xlinalg.hpp>

xt::xarray<float> run(const xt::xarray<float>&);

logreg.cpp:
#include "logreg.h"

xt::xarray<float> run(const xt::xarray<double>& x){
    xt::xarray<float> y { {1, 2.5} };
    return y;
}

Running it with the following flags on apple clang with following configs:
(cling) ❯ g++ --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-9<IP_ADDRESS>)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Gives us:
(cling) ❯ make
g++ -shared -fPIC -std=c++17 -Wall -I/Users/ray_zhang/anaconda3/envs/cling/include -o libxnor.so logreg.cpp
In file included from logreg.cpp:1:
In file included from ./logreg.h:3:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:19:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:23:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xmath.hpp:26:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xslice.hpp:109:50: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        XTENSOR_GLOBAL_CONSTEXPR rangemaker<> _r{0, 0, 0};
                                                 ^~~~~~~
                                                 {      }
In file included from logreg.cpp:1:
In file included from ./logreg.h:3:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:19:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:23:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xmath.hpp:27:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xstrided_view.hpp:26:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xstrided_view_base.hpp:877:25: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                return{ 0, 0, 0 };
                        ^~~~~~~
                        {      }
In file included from logreg.cpp:1:
In file included from ./logreg.h:3:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:19:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:23:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xmath.hpp:27:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xstrided_view.hpp:966:72: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        return squeeze(std::forward<E>(e), std::array<std::size_t, 1>{ axis }, check_policy);
                                                                       ^~~~
                                                                       {   }
In file included from logreg.cpp:1:
In file included from ./logreg.h:3:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:19:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:23:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xmath.hpp:1875:137: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        return sum(std::forward<E>(e) * reshape_view(std::forward<W>(weights), std::move(broadcast_shape)), std::array<std::size_t, 1>({ax})) / std::move(div);
                                                                                ^~
                                                                                { }
In file included from logreg.cpp:1:
In file included from ./logreg.h:9:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:300:42: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 1> vN = {N};
                                         ^
                                         {}
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:303:43: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 2> shp = {N, N};
                                          ^~~~
                                          {   }
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:350:42: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 1> vN = {N};
                                         ^
                                         {}
  1 CC=g++-8
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:353:41: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 2> shp({N, N});
                                        ^~~~
                                        {   }
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:382:42: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 1> vN = {N};
                                         ^
                                         {}
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:403:42: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 1> vN = {N};
                                         ^
                                         {}
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:429:42: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 1> vN = {N};
                                         ^
                                         {}
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:434:41: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 2> shp({N, N});
                                        ^~~~
                                        {   }
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:457:42: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 1> vN = {N};
                                         ^
                                         {}
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:461:41: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 2> shp({N, N});
                                        ^~~~
                                        {   }
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:486:42: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 1> vN = {N};
                                         ^
                                         {}
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:507:42: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 1> vN = {N};
                                         ^
                                         {}
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:936:13: warning: unused variable 'res' [-Wunused-variable]
        int res = lapack::getrf(LU, piv);
            ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:1088:47: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 2> tau_shp = {K, 1};
                                              ^~~~
                                              {   }
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:1443:53: warning: suggest braces around initialization of subobject [-Wmissing-braces]
        std::array<std::size_t, 1> residuals_shp = {0};
                                                    ^
                                                    {}
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:1441:13: warning: unused variable 'info' [-Wunused-variable]
        int info = lapack::gelsd(dA, db, s, rank, rcond);
            ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:1443:36: warning: unused variable 'residuals_shp' [-Wunused-variable]
        std::array<std::size_t, 1> residuals_shp = {0};
                                   ^
In file included from logreg.cpp:1:
In file included from ./logreg.h:9:
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:29:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp:482:15: warning: unused type alias 'xtype' [-Wunused-local-typedef]
        using xtype = xtensor<value_type, 2, layout_type::column_major>;
              ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp:540:15: warning: unused type alias 'xtype' [-Wunused-local-typedef]
        using xtype = xtensor<value_type, 2, layout_type::column_major>;
              ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp:596:15: warning: unused type alias 'xtype' [-Wunused-local-typedef]
        using xtype = xtensor<value_type, 2, layout_type::column_major>;
              ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp:652:15: warning: unused type alias 'xtype' [-Wunused-local-typedef]
        using xtype = xtensor<value_type, 2, layout_type::column_major>;
              ^
In file included from logreg.cpp:1:
In file included from ./logreg.h:9:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:345:15: warning: unused type alias 'underlying_type' [-Wunused-local-typedef]
        using underlying_type = typename value_type::value_type;
              ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:1080:15: warning: unused type alias 'result_xtype' [-Wunused-local-typedef]
        using result_xtype = xtensor<value_type, 2>;
              ^
27 warnings generated.

However, running the SAME command with g++-8, with details:
(cling) ❯ g++-8 --version
g++-8 (Homebrew GCC 8.1.0) 8.1.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

(cling) ❯ make
g++-8 -shared -fPIC -std=c++17 -Wall -I/Users/ray_zhang/anaconda3/envs/cling/include -o libxnor.so logreg.cpp
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:29,
                 from logreg.h:9,
                 from logreg.cpp:1:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp: In function 'int xt::lapack::geev(E&, char, char, W&, W&, V&, V&)':
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp:482:72: warning: typedef 'using xtype = xt::xtensor<typename E::value_type, 2, (xt::layout_type)2>' locally defined but not used [-Wunused-local-typedefs]
         using xtype = xtensor<value_type, 2, layout_type::column_major>;
                                                                        ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp: In function 'int xt::lapack::syevd(E&, char, char, W&)':
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp:540:72: warning: typedef 'using xtype = xt::xtensor<typename E::value_type, 2, (xt::layout_type)2>' locally defined but not used [-Wunused-local-typedefs]
         using xtype = xtensor<value_type, 2, layout_type::column_major>;
                                                                        ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp: In function 'int xt::lapack::geev(E&, char, char, W&, V&, V&)':
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp:596:72: warning: typedef 'using xtype = xt::xtensor<typename E::value_type, 2, (xt::layout_type)2>' locally defined but not used [-Wunused-local-typedefs]
         using xtype = xtensor<value_type, 2, layout_type::column_major>;
                                                                        ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp: In function 'int xt::lapack::heevd(E&, char, char, W&)':
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlapack.hpp:652:72: warning: typedef 'using xtype = xt::xtensor<typename E::value_type, 2, (xt::layout_type)2>' locally defined but not used [-Wunused-local-typedefs]
         using xtype = xtensor<value_type, 2, layout_type::column_major>;
                                                                        ^
In file included from logreg.h:9,
                 from logreg.cpp:1:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp: In function 'auto xt::linalg::eig(const xt::xexpression<E>&)':
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:345:64: warning: typedef 'using underlying_type = typename E::value_type::value_type' locally defined but not used [-Wunused-local-typedefs]
         using underlying_type = typename value_type::value_type;
                                                                ^
In file included from logreg.h:9,
                 from logreg.cpp:1:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp: In function 'auto xt::linalg::qr(const xt::xexpression<E>&, xt::linalg::qrmode)':
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor-blas/xlinalg.hpp:1080:52: warning: typedef 'using result_xtype = xt::xtensor<typename T::value_type, 2>' locally defined but not used [-Wunused-local-typedefs]
         using result_xtype = xtensor<value_type, 2>;
                                                    ^
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xstorage.hpp:22,
                 from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xbuffer_adaptor.hpp:20,
                 from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:18,
                 from logreg.h:3,
                 from logreg.cpp:1:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xutils.hpp: In instantiation of 'struct xt::get_strides_type<xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true> >':
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xutils.hpp:1094:61:   required by substitution of 'template<class C> using get_strides_t = typename xt::get_strides_type::type [with C = xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>]'
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:34:55:   required from 'struct xt::xcontainer_inner_types<xt::xarray_container<xt::uvector<float, std::allocator<float> >, (xt::layout_type)1, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>, xt::xtensor_expression_tag> >'
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:33:86:   required from 'struct xt::xcontainer_iterable_types<xt::xarray_container<xt::uvector<float, std::allocator<float> >, (xt::layout_type)1, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>, xt::xtensor_expression_tag> >'
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:44:12:   required from 'struct xt::xiterable_inner_types<xt::xarray_container<xt::uvector<float, std::allocator<float> >, (xt::layout_type)1, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>, xt::xtensor_expression_tag> >'
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xiterable.hpp:44:75:   required from 'class xt::xconst_iterable<xt::xarray_container<xt::uvector<float, std::allocator<float> >, (xt::layout_type)1, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>, xt::xtensor_expression_tag> >'
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xiterable.hpp:170:11:   required from 'class xt::xiterable<xt::xarray_container<xt::uvector<float, std::allocator<float> >, (xt::layout_type)1, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>, xt::xtensor_expression_tag> >'
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:72:11:   required from 'class xt::xcontainer<xt::xarray_container<xt::uvector<float, std::allocator<float> >, (xt::layout_type)1, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>, xt::xtensor_expression_tag> >'
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:384:11:   required from 'class xt::xstrided_container<xt::xarray_container<xt::uvector<float, std::allocator<float> >, (xt::layout_type)1, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>, xt::xtensor_expression_tag> >'
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:63:11:   required from 'class xt::xarray_container<xt::uvector<float, std::allocator<float> >, (xt::layout_type)1, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>, xt::xtensor_expression_tag>'
logreg.cpp:3:50:   required from here
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xutils.hpp:1081:72: error: ambiguous template instantiation for 'struct xt::rebind_container<long int, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true> >'
         using type = typename rebind_container<std::ptrdiff_t, S>::type;
                                                                        ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xutils.hpp:1073:12: note: candidates are: 'template<class X, template<class, long unsigned int <anonymous> > class C, class T, long unsigned int N> struct xt::rebind_container<X, C<T, N> > [with X = long int; C = xt::svector; T = long unsigned int; long unsigned int N = 4]'
     struct rebind_container<X, C<T, N>>
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xbuffer_adaptor.hpp:20,
                 from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:18,
                 from logreg.h:3,
                 from logreg.cpp:1:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xstorage.hpp:1231:12: note:                 'template<class X, class T, long unsigned int N, class A> struct xt::rebind_container<X, xt::svector<T, N, A> > [with X = long int; T = long unsigned int; long unsigned int N = 4; A = std::allocator<long unsigned int>]'
     struct rebind_container<X, svector<T, N, A>>
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xstorage.hpp:22,
                 from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xbuffer_adaptor.hpp:20,
                 from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:18,
                 from logreg.h:3,
                 from logreg.cpp:1:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xutils.hpp:1081:72: error: invalid use of incomplete type 'struct xt::rebind_container<long int, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true> >'
         using type = typename rebind_container<std::ptrdiff_t, S>::type;
                                                                        ^
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xutils.hpp:1063:12: note: declaration of 'struct xt::rebind_container<long int, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true> >'
     struct rebind_container;
            ^~~~~~~~~~~~~~~~
In file included from /Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:19,
                 from logreg.h:3,
                 from logreg.cpp:1:
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp: In instantiation of 'xt::xstrided_container<D>::xstrided_container() [with D = xt::xarray_container<xt::uvector<float, std::allocator<float> >, (xt::layout_type)1, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>, xt::xtensor_expression_tag>]':
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:338:21:   required from 'xt::xarray_container<EC, L, SC, Tag>::xarray_container(xt::nested_initializer_list_t<typename xt::xstrided_container<xt::xarray_container<EC, L, SC, Tag> >::value_type, 2>) [with EC = xt::uvector<float, std::allocator<float> >; xt::layout_type L = (xt::layout_type)1; SC = xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>; Tag = xt::xtensor_expression_tag; xt::nested_initializer_list_t<typename xt::xstrided_container<xt::xarray_container<EC, L, SC, Tag> >::value_type, 2> = std::initializer_list<std::initializer_list<float> >]'
logreg.cpp:4:36:   required from here
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:1252:9: error: using invalid field 'xt::xstrided_container<D>::m_strides'
         m_strides = xtl::make_sequence<inner_strides_type>(base_type::dimension(), 0);
         ^~~~~~~~~
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:1253:9: error: using invalid field 'xt::xstrided_container<D>::m_backstrides'
         m_backstrides = xtl::make_sequence<inner_backstrides_type>(base_type::dimension(), 0);
         ^~~~~~~~~~~~~
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp: In instantiation of 'void xt::xstrided_container<D>::resize(S&&, bool) [with S = xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>; D = xt::xarray_container<xt::uvector<float, std::allocator<float> >, (xt::layout_type)1, xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>, xt::xtensor_expression_tag>]':
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xarray.hpp:340:26:   required from 'xt::xarray_container<EC, L, SC, Tag>::xarray_container(xt::nested_initializer_list_t<typename xt::xstrided_container<xt::xarray_container<EC, L, SC, Tag> >::value_type, 2>) [with EC = xt::uvector<float, std::allocator<float> >; xt::layout_type L = (xt::layout_type)1; SC = xt::svector<long unsigned int, 4, std::allocator<long unsigned int>, true>; Tag = xt::xtensor_expression_tag; xt::nested_initializer_list_t<typename xt::xstrided_container<xt::xarray_container<EC, L, SC, Tag> >::value_type, 2> = std::initializer_list<std::initializer_list<float> >]'
logreg.cpp:4:36:   required from here
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:1343:30: error: using invalid field 'xt::xstrided_container<D>::m_strides'
             resize_container(m_strides, m_shape.size());
                              ^~~~~~~~~
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:1344:30: error: using invalid field 'xt::xstrided_container<D>::m_backstrides'
             resize_container(m_backstrides, m_shape.size());
                              ^~~~~~~~~~~~~
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:1345:70: error: using invalid field 'xt::xstrided_container<D>::m_strides'
             size_type data_size = compute_strides(m_shape, m_layout, m_strides, m_backstrides);
                                                                      ^~~~~~~~~
/Users/ray_zhang/anaconda3/envs/cling/include/xtensor/xcontainer.hpp:1345:81: error: using invalid field 'xt::xstrided_container<D>::m_backstrides'
             size_type data_size = compute_strides(m_shape, m_layout, m_strides, m_backstrides);
                                                                                ^~~~~~~~~~~~~
make: *** [libxnor.so] Error 1

Using the new version of xtensor:
(cling) ❯ conda list | grep xtensor
xtensor                   0.17.0               h2d50403_0    conda-forge
xtensor-blas              0.12.0          blas_openblash2d50403_0  [blas_openblas]  conda-forge

ok one idea to fix this would be to add the 4th template argument to svector which is a bool Init so that the template specialization would look like:
template <class X, class T, std::size_t N, class A, bool B>
struct rebind_container<X, svector<T, N, A, B>>

Not sure if that would help though.
Otherwise we need to disable the overload using enable_if I guess?

@wolfv Your solution should fix the issue, otherwise we can fill a bug report to gcc (although I'm not sure that gcc8 is right here).

Homebrew lists 8.2 as stable, let's see if that fixes the issue: https://formulae.brew.sh/formula/gcc

Homebrew lists GCC 8.2 as stable version:

The C++ 17 fixes for GCC 8 have been merged into master.


errors when building projects with multiple requirements

adding the suffix in the wrong place
the feature that allows a single project to have multiple docker images is adding the suffix to the tag, instead of the name. Furthermore, it's adding default to the default tag, but this should not  happen. For example, it'll generate:
project-name:latest-default
project-name:latest-another
but it should be:
project-name:latest
project-name-another:latest
argo spec does not take multiple docker images into account
when exporting to argo, all the tasks use the same docker image, I haven't tested with AWS Batch or Airflow, but I suspect the same.
correct image building
Also, I'm unsure if the logic to build the docker images is correctly implemented. I tried running the example and then checked the "plot" image:
docker run multiple_requirements_project:latest-plot-ploomber pip freeze | grep seaborn

and seaborn isn't there

Note: "adding the suffix in the wrong place" has been fixed


Fr buy fix

[FR]-[Buy]-User is not logged and buy a product previously selected fix.
Delete the pre-push script

We need a refactor in the code!
So keep rocking bro!
Thank you
See you soon...


Updated to return permanent invite instead of temporary

Type

[ ] Bug Fix
[✓] Functions: $getServerInvite
[ ] Callbacks: <Callback Name>
[ ] Handlers: <Handler Type>
[ ] Others: ______

Dependencies (Third Party Modules) needed: <Name | Github Link> (Maximum: 20MB~ size)
Want a credit? Discord tag or other social media link:
Referenced Issue: #NaN (Answer for an issue, if any)
Description
Pull Request Description Here

It might be a better idea to add fields to customize the function? This looks like an overkill tbh

It might be a better idea to add fields to customize the function? This looks like an overkill tbh

Hmm yeah true maybe i will try to add fields

Make a New PR when you've added optional fields.
For now this will be closed as enough time been given.


Fix the PORT for issue #895

Looks good to me :+1:

Go ahead and merge @ianblenke :)

I'll have to login as @icblenke, as @ianblenke doesn't have commit access. We should definitely switch commit access over to @ianblenke going forward.

@icblenke @ianblenke Sorry about that, I'm switching it to @ianblenke now.


What is findEvents

export class TiddlyWikiModelsDatastore implements IModelsDatastore {
  async findEvents(query: { 'events.subType': 'Timer' }): Promise<any[]> {
    return [];
  }

What does its input "Timer" mean? Also what should be returned?

Difficult to tell from the code, and its comment is difficult to understand to me.
/**
    returns Model Events (like timers) for authorized to the user and based on specifid query
*/

     findEvents(query:any, user?: ISecureUser);

bpmn models can have events that need to be processed by the engine without engine.start
So if a model has a start timer event, the engine need to monitor that and start the model.

Thanks, do you mean this?

Currently if reading of BPMN file is triggered by engine.start, then how to know some bpmn file have timer node and trigger timer event?
await api.engine.start('log-console.bpmn', { key: 'value' }, SystemUser);
// only after this, the ModelsDatastore.getSource is called to get bpmn file

Actually, there are few scenarios:

Timer Start Event
Message Start Event
Signal Start Event

On saving the model, data is parsed and those events are saved into the DB.

For Timer Start Events, on bpmn-server start ,findEvents is called for timers and then processed.
For Message and Signals, when a message is called, findEvents is called for the message/signal

On saving the model

This is another question, I haven't seem this gets called. Do I need to call something to trigger this?
I find many method is not called when I only use api.engine.start
https://github.com/tiddly-gittly/workflow/blob/1e086573e1ba416bb762c0e1a7807ede44570f43/src/workflow-engine/engine/data/twModelDataStore.ts#L16-L62

when a message is called

Am I understand correctly? When you api.engine.start a bpmn file, it register message/signal listener on computer memory, and when I trigger the "saving the model", it save to DB. And I can stop the bpmn file.
Later, when computer restart, and new BPMNServer(config, config.logger), it get the infomation back, and auto load the related BPMN file based on processId.

Not exactly Model save must happen first When message is fired it finds the corresponding responder; either a running workflow or a model start event; it doesn’t wait Sent from my iPhoneOn Jul 24, 2024, at 1:57 AM, lin onetwo @.***> wrote:
when a message is called
Am I understand correctly? When you api.engine.start a bpmn file, it register message/signal listener on computer memory, and when I trigger the "saving the model", it save to DB. And I can stop the bpmn file.
Later, when computer restart, and new BPMNServer(config, config.logger), it get the infomation back, and auto load the related BPMN file based on processId.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

I will test this and write doc.


"TURNU MĂGURELE" is listed in the drop-down menu

Description:
"TURNU MĂGURELE" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "TURNU MĂGURELE" in the search bar.

Expected results
The location is listed in the drop-down menu as "Oraș TURNU MĂGURELE, TELEORMAN (TURNU MĂGURELE)" and "Municipiul TURNU MĂGURELE, TELEORMAN".


Federation 2 supported?

Do async-graphql currently support federation 2 schemas?? For using it with new apollo router built with rust instead of nodejs apollo gateway..

We're deciding between Rust and Go to implement GraphQL sub-graphs. The Apollo page lists Rust as having very little Fed2 support:
https://www.apollographql.com/docs/federation/supported-subgraphs/#rust
Will this library be updated regularly? Is it production ready? Are there other (preferably official) Rust GraphQL libraries?

I'll support it when I'm free. 🙂

Fair enough. What that means is this project isn't ready for production use.

Will this library be updated regularly?

I suggest you take a look at the releases, commits and issue board. @sunli829 is generously donating an enormous amount of time to supporting this project, and I for one am very grateful.

Is it production ready?

https://github.com/async-graphql/async-graphql#whos-using-async-graphql-in-production

Fair enough. What that means is this project isn't ready for production use.

That's terribly unfair. Many companies and projects are using it successfully in production. If your particular use-case isn't answered, perhaps you could consider sponsoring the project or contributing to it?

I am not very familiar with the async-graphql codebase, but I do want to contribute to the community in any way I can here. I think it'd be helpful if we at least have ideas written down about how to implement each of the remaining pieces.
looking over the apollo compat list, i think the things we need still are:

@link directive
@tag directive
@override directive
plus ftv1 might be a "nice-to-have"

the override directive should be pretty straightforward since it only applies to fields; the changes that have been made so far should provide a good example for how to proceed.
I managed to find a definition of the tag directive - it's documented here: https://specs.apollo.dev/tag/v0.2/; i think it should be pretty similar to existing directive support as well.
ftv1 is almost straightforward as per the apollo documentation: https://www.apollographql.com/docs/federation/metrics/#how-tracing-data-is-exposed-from-a-subgraph
it just requires looking for a header in the http request, and then computing the value to put in the response extensions. does anyone have any thoughts about how to do this, given the various web frameworks async-graphql integrates with?
the really tricky one is @link. I think there are several challenges here based on what I've seen from Apollo about its use, which seem to require totally new features in async-graphql.

we need a way to have schema-level directives.
the really tricky part is that it can import totally new schema directive definitions into the subgraph. so we need a way to add custom schema directives all over the place.
there's also this extend schema syntax associated with it (as seen here https://specs.apollo.dev/link/v1.0/). the subgraph spec documentation for it is maybe easier to understand: https://www.apollographql.com/docs/federation/federation-spec/#link

re: @link directive support - while the full functionality is pretty complex as it allows for namespacing and renaming of the imported definitions, due to the flexible type merging that is available in Federation v2, router should be able to compose subgraph schemas even if subset of functionality is provided.
extend schema syntax is not required as directive can be applied directly on the schema type. At a minimum you just need to import the spec (but as a side effect all federation directives will have to be namespaced with federation__ prefix).
schema @link(url : "https://www.apollographql.com/docs/federation/federation-spec/"){
  query: Query
}

directive @link(url: String!) repeatable on SCHEMA
directive @federation__key(fields: federation__FieldSet!, resolvable: Boolean = true) repeatable on OBJECT | INTERFACE
scalar federation__FieldSet

NOTE: @tag and @inaccessible currently cannot be renamed/namespaced, attempting to do so will led to composition errors

Alternatively, if you import those directive definitions (even without supporting renaming) then you don't need to namespace them anymore, e.g.
schema @link(url : "https://www.apollographql.com/docs/federation/federation-spec/", import : ["key", "FieldSet"]){
  query: Query
}

directive @link(url: String!, import: [String]) repeatable on SCHEMA
directive @key(fields: FieldSet!, resolvable: Boolean = true) repeatable on OBJECT | INTERFACE
scalar FieldSet

I am not familiar with async-graphql so unsure if this is possible but within graphql-java world you could use schema transformer to rename the definitions (so in the code there is only a single definition).

@leebenson

That's terribly unfair. Many companies and projects are using it successfully in production. If your particular use-case isn't answered, perhaps you could consider sponsoring the project or contributing to it?

It was harsh I admit. I appreciate the time that @sunli829 has contributed to this project. I also maintain open source projects and it's a thankless job. Kudos to sunli, I meant no offense to him and others who've contributed to this project.
My response was directly to the comment "I'll support it when I'm free".  Having used numerous open source libraries, it's painful when a bug is discovered, a fix provided, but the maintainer goes AWOL.  Yes I could fork this, but that introduces all sorts of downstream problems.

I have taken a little time to try to implement the override directive ... currently trying to solve some mystifying build issues locally. If I can figure it out I might put up a change over the weekend.
ftv1 (subgraph) tracing ... should that be a separate crate, maybe? I've seen that there's already a separate crate for publishing traces to apollo studio directly, maybe the subgraph tracing support should be implemented similarly (if not in the same repo)?
@dariuszkuc if you have a chance - re

extend schema syntax is not required as directive can be applied directly on the schema type.
Would you mind elaborating on the distinction (if there is any)? How does federation treat the two differently?

I see that your example uses @federation__key, which worries me a little - async-graphql currently supports printing the @key directive when instructed in that form. This means supporting this link directive needs to be done to prevent this namespacing.
Either way, the issue is figuring out how to configure it for printing.  It only needs to be output as part of the federation schema, right?
Maybe it could be added as an optional field on the Schema struct, so that it can be output when printing in federation mode.

within graphql-java world you could use schema transformer to rename the definitions (so in the code there is only a single definition).

i am pretty sure async-graphql does not have anything like this - it appears to be very straightforward in printing the definitions registered in the schema.
Overall I still consider link to be the biggest challenge - i.e.

router should be able to compose subgraph schemas even if subset of functionality is provided.
is not actually encouraging given that the subset of functionality that is needed provides some challenges.

extend schema syntax is not required as directive can be applied directly on the schema type.
Would you mind elaborating on the distinction (if there is any)? How does federation treat the two differently?

From federation perspective there is no difference as either one (extend schema @link("foo") or (schema @link("foo")) is valid from composition perspective. There is a small difference from the subgraph perspective as if you apply directive directly on the schema type then you also need to include default Query types, e.g.
# using extension you can omit defaults
extend schema @link("foo")

# applying directive on schema directly requires specifying default types
schema @link("foo") {
  query: Query
}

In regards to implementing @link directive support, there are 4 use cases
1. Link to spec only
schema @link(url : "https://specs.apollo.dev/federation/v2.0"){
  query : Query
}

When we link to the target spec, we have to explicitly namespace* federation directives with federation__
directive @link(url: String!) repeatable on SCHEMA
directive @federation__key(fields: federation__FieldSet!, resolvable: Boolean = true) repeatable on OBJECT | INTERFACE
scalar federation__FieldSet

Simplest way to support it, is to define your directives as federation__<directive> so there is no need for renames (you may want to have separate definitions for v1 which does not support namespacing and v2 that requires namespacing).

*NOTE: @tag and @inaccessible currently cannot be renamed/namespaced, attempting to do so will led to composition errors

2. Link to spec and specify custom namespace
schema @link(url : "https://specs.apollo.dev/federation/v2.0", as: "fed"){
  query : Query
}

When using custom namespace you have to explicitly namespace federation types (except for @tag and @inaccessible) with specified namespace.
directive @link(url: String!, as: String) repeatable on SCHEMA
directive @fed__key(fields: fed__FieldSet!, resolvable: Boolean = true) repeatable on OBJECT | INTERFACE
scalar fed__FieldSet

IMHO this is somewhat complex to support as it requires dynamic renaming of the types based on the user input.
3. Explicitly import federated types
schema @link(url : "https://specs.apollo.dev/federation/v2.0", import : ["@key", "FieldSet"]) {
  query: Query
}

When explicitly importing types you don't need to rename/namespace any of the underlying types.
directive @link(url: String!, import: [String]) repeatable on SCHEMA
directive @key(fields: FieldSet!, resolvable: Boolean = true) repeatable on OBJECT | INTERFACE
scalar FieldSet

IMHO this is arguably the easiest to implement as we don't need to rename/namespace any of the underlying types. There is a small drawback that there is a small chance that imported types could conflict with the types defined locally (guessing it generally shouldn't be common).
3. Explicitly import federated types and rename them to avoid collisions
schema @link(url : "https://specs.apollo.dev/federation/v2.0", import : [ { name: "@key", as: "@mykey" }, "FieldSet"]) {
  query: Query
}

directive @link(url: String!, import: [link_Import]) repeatable on SCHEMA
directive @mykey(fields: FieldSet!, resolvable: Boolean = true) repeatable on OBJECT | INTERFACE
scalar FieldSet
# note that Import scalar is imported from different spec, hence the namespace, Import can be either a string or `name/as` value pair.
scalar link__Import

Similarly to custom namespacing, IMHO this is pretty complex to support as it requires dynamically renaming types based on user input.

Full link support would imply automatically applying namespacing (possibly custom) for non-imported types and providing ability to rename the types to avoid the collision. Minimal functionality to support is option 1 above or option 3.

just marked my PR ready for review - https://github.com/async-graphql/async-graphql/pull/1060
it's a simple approach to implementing the link directive that relies on the fact that async-graphql does not presently have any custom schema directive support. (if` in the future such support is added, that addition will need to entirely replace what i've done.)

Support was released in v4.0.14 🎉

I think this can be closed now that the fed2 compatibility is all "green" in the test matrix. I think federated tracing can be a separate feature in the future if folks are looking for that, specifically.

that makes sense to me @dbanty, especially since federated tracing is probably something that should be implemented as a separate crate.

Thanks for pushing this over the finish line @raptros !!


Add Link to CONTRIBUTING.md file in the README.md

**Short introduction what you want to change in README.md **
There should be a link for the contributing guide in the README.md file

True 👍


PowerRename

Description of the new feature / enhancement
Hello. It would be convenient to be able to put your own name generation template. For example
example 1
sample:
name-[inc number]
result
name - 1
name - 2
name - 3
example 2
sample:
[date] summer photo-[inc number]
result
01 08 2022  summer photo - 1
02 08 2022  summer photo - 2
02 08 2022  summer photo - 3
Scenario when this would be used?
When creating photo albums. Or product photos.
Supporting information
No response

I'm not sure I understand, but I think a lot of what you're asking is already possible with date/time variables and Regular expressions. Have another look at the documentation.

Okay. Yes, the looks of the numbers can't be changed directly. But, maybe you could first do a rename action to get the numbers, and later do another action to give them the place and looks that you want.


[main] Upgrade to latest dependencies (#73)

upgrade to latest dependencies
Signed-off-by: Knative Automation<EMAIL_ADDRESS>

OCF Webhook is merging this PR


Fix HTML syntax in classic slides example

The current HTML in examples/classic-slides/index.html is invalid syntax. This PR fixes the two problems.
In 81b49d0ec250e4e4b7b49b381b26cdcf066447e2, I removed the link to the tutorial at all, since inline links are disabled by default since Mermaid.js v8.2.0: see 'click functionality is disabled' in their release notes.

Thanks


Pr att bias cleanup2

I'll get the changes in that @sanderux  requested for the fixed wing controller.

@priseborough thanks for addressing my comments.
I mentioned inconsistent use of airspeed_mode vs airspeed_disabled and you choose to use airspeed_mode consistently. reading the code perhaps airspeed_disabled would have been clearer, but not a big issue. I'm fine with it either way.

I can change it to be airspeed disabled everywhere assuming that it will always be used as a boolean and we will not be adding other mode selections (eg use none, use estimated, use measured).

considering now it is a boolean and if in the future that changes the code would have to change anyway, i say lets make it airspeed_disabled

@PX4TestFlights Please thoroughly re-test this. Thanks!

On all airframes that is - multicopter, VTOL, fixed wing.

Rebased.

a few flights with pixracer (v4)
https://logs.px4.io/plot_app?log=23e9ccd1-66ae-4225-9fba-a838bc5a0a9b
https://logs.px4.io/plot_app?log=cfb8bd26-aa36-4ad4-bf7e-1838d995bf6f
https://logs.px4.io/plot_app?log=7afbd5d8-92e6-4568-bd69-e5f037f7a37e
very stable; seemingly better tracking; no issues

Flight with pixhawk 1(V3); Good flight, no issues
https://logs.px4.io/plot_app?log=70e4aca1-4882-4b38-9250-7480e5b96c53
Flight with pixhawk pro (V4PRO); Good flight, no issues
https://logs.px4.io/plot_app?log=7dc4c2cf-58f7-4e3e-b944-b811abe4f4e8
Flight with pixhawk 1 (V2); Good flight, no issues
https://logs.px4.io/plot_app?log=d89361b0-a187-4f83-a61b-3eba8ff3e25e

@santiago3dr @Avysuarez Thanks! We still need coverage on VTOL and FW. :)

Unrelated to the PR, but one of the logs have that annoying transformation bug. Those tracking errors would've constituted a flyaway in reality :

Unrelated to the PR, but one of the logs have that annoying transformation bug. Those tracking errors would've constituted a flyaway in reality :

Any clues for where it's happening? When have you seen this bug?

@dagar It's filed here : https://github.com/PX4/pyulog/issues/13, but I don't think anyone is closer to finding the core problem.

vtol flight:
https://logs.px4.io/plot_app?log=da7635c7-209f-4567-a5d8-efbe06ca3769
compared to master:
https://logs.px4.io/plot_app?log=d71c9cbc-ceef-4c96-a786-dd1f09b34fd9
...and compared to stable:
https://logs.px4.io/plot_app?log=8ab54dbc-4c72-4134-98a8-1b52aae0cf4c
FW flights:
https://logs.px4.io/plot_app?log=d7b17818-2d28-40a4-9829-615a7cc1b09f
https://logs.px4.io/plot_app?log=4a79be68-d2ab-4b5a-a6d7-81607bd8d865
compared to master:
https://logs.px4.io/plot_app?log=04f281af-624d-48d2-b345-29eb792ff665
good flight performance; stable with nice tracking with both platforms

@santiago3dr Many thanks for the excellent test coverage!
@LorenzMeier @priseborough @dagar I wil merge this soon after a final review unless any of you have any objections.  Do you think i should give it a quick test on the deltaquad?

@sanderux Yes definitely! Please do test and let us know if airspeed-less operation works as expected.

@sanderux Any chance to get this done today?

Sorry, no luck yet, planning and weather keep interfering. I will try in the next 2 days

@sanderux Updates? If none, let's get this in anyway.

Rebasing

@dagar does @PX4TestFlights need to re-test?

Rebase became difficult and didn't seem worth it.
Continued here as a squashed commit, https://github.com/PX4/Firmware/pull/7882.
We can split it into smaller commits if desired.


Update for iOS 10 SDK

Update for iOS 10 SDK, but this is not compatible with iOS 9 SDK because it doesn't declare CALayerDelegate protocol publicly.

+1

the preprocessor conditional compilation directive around the using of CAAnimationDelegate should help:
+@interface ZXCapture : NSObject <AVCaptureVideoDataOutputSampleBufferDelegate, CAAction
#if defined(__IPHONE_10_0) && __IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_10_0
, CALayerDelegate
#endif
>
// ......

Check seems fine to me!


feat(TCOMP-628):add tcomp identifier in json logs

What is the current behavior? (You can also link to an open issue here)
tcomp web service is missing some ways to identify it's logs
What is the new behavior?
logs are using the service custom field identifier for the json logs.
Also an attempt to remove the filebeat logs.
Please check if the PR fulfills these requirements

[x] The commit message follows Talend standard
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features) ?
[ ] The code coverage on new code >75%
[ ] The new code does not introduce new technical issues (sonar / eslint)

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build / CI related changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Pull request test result: success :star:
Sonar results