Add new module XMonad.Hooks.Focus .

Hi.
So, i've fixed documentation and here i am, trying to jump into leaving train
again.
Here is another way to solve #110, #93 and
https://github.com/xmonad/xmonad/issues/45 : a module, which extends
ManageHook EDSL with combinators working on focused window and current
workspace. Please, see documentation for examples and detailed description in
the module for more details.
I apologize to authors of two proposed above solutions for releasing this so
late, but this module provides a much more generic way to solve focus grab
problem. E.g. it allows to move activated window to current workspace, but not
grab focus, or grab focus, but not switch workspace.
Unfortunately, it has some pitfalls:

I've decided to apply manageHook to activated window too. It seems very
natural to me, but it may lead to unexpected results for many people using
ewmh, when manageHook previously working only for new windows, start
working for activated windows too. It may be solved, by adding
 not <$> activated

before those part of manageHook, which should not be called for
activated windows.  But this lifts manageHook into FocusHook and it
needs to be converted back later.

(fixed) This module is incompatible with XMonad.Hooks.EwmhDesktops in its current
state, because ewmh also handles activated window and it'll overwrite any
decisions made by FocusHook. And i think, the fixes proposed above are
not very good: they effectively disable entire handleEventHook for
activated window, but i'd prefer to disable only handling in ewmh (e.g.
provide a different handle, whatever). Though, even proposed fixes can be
used, if they'll be applied in correct order:
 handleFocusQuery ..
   . ignoreNetActiveWindow ..
   . ewmh

so may be it's fine.

(fixed) It requires more general versions of XMonad.Hooks.ManageHelpers
combinators, then currently provided. E.g. now we have
 composeOne :: [MaybeManageHook] -> ManageHook

but i need
 composeOne :: (Monoid a, Monad m) => [m (Maybe a)] -> m a

This may be easily fixed, though.

(fixed) handleFocusQuery adds modMask automatically to focus lock key.
Probably, that should be changed (to not adding modMask) for consistency.

There is no tests even for pure functions yet.

(fixed) Probably, i shouldn't overwrite _NET_WM_NAME and just set it, if it's
missed.

I can fix 3, 4 and 6 in a few days. The 1 is a decision on which entire module
is built and can be either accepted or not (with the module itself). The 2 needs
a decision to be made. I've cc-ed all participants of above issues.
@SirBoonami , @liskin , @unclechu , please, try this module for your use case.
Does it solve your problem?
/cc @liskin @geekosaur  @pjones  @f1u77y  @byorgey  @SirBoonami  @unclechu

@sgf-dma thanks! It works for me!
https://github.com/xmonad/xmonad/issues/45#issuecomment-266317556

I've pushed another commit, adding function getWMName to X.H.SetWMName and fixing point 6 from the first post: do not overwrite wm name, if user has set it.

Another commit changing the type of ManageHook combinators and fixing point 3 above.
I'll add edit the CHANGES.md, when all fixes will be here. I hope, that will be soon.

I've fixed the point 4 above (about not adding 'modMask' to key for toggling focus lock in handleFocusQuery), added changes into CHANGES.md and rebased all commits. The build fails, but i have no idea why.
I do not plan any more changes to X.H.Focus. Please, review the code.
And the only point left - is incompatibility with X.H.EwmhDesktops. I've seen several PRs modifying EwmhDesktops and discussions about rewriting it. So.. i'm unsure should i and how particularly fix this.

On Thu, Dec 15, 2016 at 2:24 PM, sgf-dma<EMAIL_ADDRESS>wrote:

The build fails, but i have no idea why.

Spurious failures: it's unclear where the problem is, but it's fairly
common for Travis to encounter network failures while setting up the build
container. The logs for the 7.6.3 and 7.8.1 builds both show it failing to
install packages from Ubuntu's repo.
--
brandon s allbery kf8nh                               sine nomine associates
<EMAIL_ADDRESS><EMAIL_ADDRESS>unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

Finally, i think, i've found a way of fixing incompatibility with X.H.EwmhDesktops: i moved all ewmh-related code from X.H.Focus to X.H.EwmhDesktops. And now manageHook is applied to activated window. That means:

Window activation in ewmh do nothing by default (with empty ManageHook).
You can change activation behavior using ManageHook combinators. Now X.H.EwmhDesktops provides additional combinator activated to match on activated window.
You can use X.H.Focus combinators to create more complex focus/workspace switch strategies.

@unclechu , please, test your config with current master. Note the changes:

The type of activated combinator has changed from FocusQuery Bool to Query Bool and its now exported by X.H.EwmhDesktops.
There is no handleFocusQuery function now. You should use ewmh instead (to announce _NET_ACTIVATE_WINDOW and handle an event) and just add FocusHook (converted to ManageHook by manageFocus) to your manageHook (usually, it should be the leftmost).

I hope, there will be no more rebases.
And we may go even further with this: add netActivated property, which is now the value stored in extensible state, to Query and handle window activation in xmonad. That way only xmonad will call manageHook. Probably, that'll be more consistent.

@sgf-dma is handleFocusQuery still exist?
https://github.com/xmonad/xmonad-contrib/compare/master...sgf-dma:master#diff-8b1c3fd0d4a6765c16dfd18509182f9dR105

@sgf-dma it works, I did some changes in my config for new API.

@unclechu , thanks!
I've removed no longer relevant changes from CHANGES.md (mentioning handleFocusQuery) and tried to resolve merge conflict. And though the last have failed, now the resolving is straightforward: just use theirs version.

@sgf-dma What is the status of this PR?  I'm thinking of waiting until after v0.13 to merge this.

I've fixed all issues i was aware of and was able to fix (see first post). But since there was a little feedback, all these issues was mine own. Anyway, for now, i think i've finished this PR (well, apart from conflicting CHANGES, but there is a little sense in fixing it until actual merge).

Sorry for not reacting to this earlier, I've been way too busy the last few months.
Anyway, I've looked over your code and while I've yet to test it, it looks pretty good so far. There are many different possible ways to handle window activation, which is always good.
I'd suggest adding a few drop-in hook presets (like the ones DynamicLog provides) for the most common use cases, as I've found them to be

Handy building blocks for your xmonad.hs if you just want a quick, generic solution without looking into the inner workings of the module,
Good stepping stones to understand how the module is supposed to be used by looking at their implementation.

You've already provided a bunch of examples in the description text, it should be easy to turn them into presets and maybe put their explanations into regular comments so that newbies (like me lol) aren't immediately overwhelmed by your module when they open its documentation.

I've added more examples and predefined configurations:

activateSwitchWs - default EWMH behavior (switch workspace and focus).
activateOnCurrentWs - bring activated window on current workspace and switch focus.
activateOnCurrentKeepFocus - the same, but leave focus unchanged.

@SirBoonami As i understand your module, it's equivalent to something like
not <$> (className =? ...) --> activateSwitchWs

Alright, I tested your changes on three different settings:

Ignore all focus events (new default)
Pull the window's workspace to the front (old default)
Ignore requests for some nasty windows (my approach)

Ignoring the three hours spent in cabal hell, everything went smoothly and behaved exactly as expected. From what I can tell, this seems ready for production.

So it seems there is a lot of momentum behind this PR, several users who were complaining about/working on similar things have endorsed it, and it seems well thought out and well-documented as far as I can tell.  I just don't think I have the time/knowledge/desire to test it myself.  Are there any remaining objections to merging this?  ( @geekosaur , @pjones , what do you think? )

I don't have any issues with this PR.  I think it's a great idea.

Merged!  Thanks @sgf-dma and others for the hard work putting this together and testing it.


Implement keyboard attribute for textarea and textfield

As discussed at https://github.com/Jasonette/documentation/issues/72
Add a keyboard attribute which supports:

text (default)
number
phone
email
url

PR: https://github.com/Jasonette/JASONETTE-iOS/pull/259

Resolved


Added "checkpoint" articles

This PR makes it so that there can be checkpoint articles, which are articles that must be visited in order before reaching the ending article.
The startingArticle and endingArticle have been replaced with the articles array and targetArticle, which specifies the index of the article the user is currently looking for. The current target article will appear in yellow text on the wiki page to be easily identifiable.
Users can add and remove articles directly from the settings pages.
Translations have been provided for the new required controls.

Hey! Thank you for your contribution! I really appreciate it.
I haven't looked into the PR that much, but there seem to be a couple of issues:

There is an error in the console when I start the dev server
If you select some starting and ending article -> press add new article -> delete the second one. You can now start the game, but there is no win condition.
Also i havent been able to reproduce this yet, but some combination of deleting and adding articles resulted in an error (I think it was something about too many calls to history API).

I`ll try to take a more thorough look at it on the weekend.

I'll take a look and see if I can figure those out when I have time as well.


found grammatical error in delfin documentation

Issue/Feature Description:
Why this issue to fixed / feature is needed(give scenarios or use cases):
How to reproduce, in case of a bug:
Other Notes /  Environment Information: (Please give the env information, log link or any useful information for this issue)

done


Fix time period of Fig Tree ESMAP station

When start and end year are the same, only one year should be shown


Velocity in spherical mesh

This is should not be posted as an issue, but I don't know where else to post.
My current data is from the Copernicus platform, a global reanalysis product.  It is given in m/s unite. I saw the how parcels convert to m/degree. However, when I use the spherical mesh , the particles are advected too slowly. In reality, the particles ( Larvae or eggs which are passive swimmers) should be crossed at least two lon-lat degrees within 2-3 months.
In the flat mesh, it looks more reasonable.
The area of interest is not that polar. It is in the northern coast of Norway.
Do I have to consider something else when using the spherical mehs? Do I have always to consider the spherical mesh?
Best Regards
Salah

Dear @SaAlrabeei. This depends on what the units are of your longitude and latitude.

If the units of longitude and latitude are in degrees, then you should use mesh='spherical' so that Parcels converts the velocities to degrees/m.
If the units of longitude and latitude are in meters, then you should use mesh='flat' so that Parcels does not convert the velocities and keeps them in m/s

Hope this helps. Good luck!


chore: cast to ICS4Wrapper

Description

See comment.
closes: #XXXX
Commit Message / Changelog Entry
type: commit message

see the guidelines for commit messages. (view raw markdown for examples)

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[x] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

Codecov Report

Merging #4460 (657748b) into main (5729cef) will decrease coverage by 0.04%.
Report is 3 commits behind head on main.
The diff coverage is 55.55%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4460      +/-   ##
==========================================
- Coverage   79.50%   79.47%   -0.04%
==========================================
  Files         188      188
  Lines       13038    13045       +7
==========================================
+ Hits        10366    10367       +1
- Misses       2241     2245       +4
- Partials      431      433       +2

Files Changed
Coverage Δ

...dules/light-clients/06-solomachine/client_state.go
82.73% <46.66%> (-5.55%)
:arrow_down:

modules/core/23-commitment/types/merkle.go
69.09% <100.00%> (+1.04%)
:arrow_up:

modules/light-clients/07-tendermint/upgrade.go
73.86% <100.00%> (ø)


WinUI 2: CommandBarFlyout does not allow keyboard navigation the second time it is opened

Describe the bug

WinUI 2 CommandBarFlyout does not allow keyboard navigation the second time it is opened.
Steps to reproduce the bug

Steps to reproduce the behavior:

Open this solution: https://github.com/lyahdav/XamlPlayground/tree/text-block-context-menu
Run the UwpXamlApp project in that solution
Select text in "TextBlock with bug"
Right click
Use up/down arrow keys to navigate CommandBarFlyout
Click away to hide CommandBarFlyout
Select text again
Right click again
Use up/down arrow keys to navigate CommandBarFlyout

Expected behavior
Expected: CommandBarFlyout's AppBarButtons get focused and show focus border.
Actual: No focus happens.
Screenshots
Here's a video of the issue and a workaround:
https://user-images.githubusercontent.com/359157/131182493-93bfaa1f-0a1e-46cb-92d0-df2775f114e0.mov
Version Info

NuGet package version:
Microsoft.UI.Xaml.2.7.0-prerelease.210816001

Windows app type:

UWP
Win32

Yes
Yes

Windows version
Saw the problem?

Insider Build (xxxxx)

May 2021 Update (19043)
Yes

October 2020 Update (19042)

May 2020 Update (19041)

November 2019 Update (18363)

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Xbox

Surface Hub

IoT

Additional context
The offending code can be summarized as:
		TextBlock tbl;
		mux::TextCommandBarFlyout cbf;
		tbl.SelectionFlyout(cbf);
		tbl.ContextFlyout(cbf);
		tbl.Text(text);
		tbl.IsTextSelectionEnabled(true);
		xamlContainer.Children().Append(tbl);

The workaround is to recreate the CommandBarFlyout on close:
			cbf.Closed([=](auto&&...) {
				mux::TextCommandBarFlyout newCbf;
				tbl.SelectionFlyout(newCbf);
				tbl.ContextFlyout(newCbf);
				});

I'm also able to repro this in MUXControlsTestApp on a TextBox with a TextCommandBarFlyout, but only when the menu doesn't have a proofing submenu:
https://user-images.githubusercontent.com/359157/131197209-21d05f8d-665d-4705-8c6e-fe07199d9e7f.mov

I'm also able to repro this in MUXControlsTestApp on CommandBarFlyout that's unrelated to TextCommandBarFlyout:
https://user-images.githubusercontent.com/359157/131197505-586ab91d-0ea2-4853-86c9-97d65a71b62f.mov

@llongley this sounds similar to a bug you looked into earlier this year, thoughts?

Likely still relevant

@lyahdav, thank you for reporting this. Unfortunately we are not currently investigating WinUI2 issues that are not business or security critical (more on the policy here). From a quick look, this does not appear to repro in WinAppSDK 1.5. If you see the issue in latest WinAppSDK, please comment here and we will investigate.


AttributeError: module 'tensorflow' has no attribute 'Session'

When I call any function in python3.6, I get the error below; however, it works fine in python3.4. Any idea?
import tensorflow as tf
tf.Session()
Traceback (most recent call last):
File "", line 1, in
AttributeError: module 'tensorflow' has no attribute 'Session'

Here is my  System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Debian 8.7
TensorFlow installed from (source or binary): by pip3
TensorFlow version (use command below): 1.7.0
Python version: 3.6.5
CUDA/cuDNN version: cuda 9.0 and cudnn 7.0
GPU model and memory: K80, 12 GB
Exact command to reproduce:
import tensorflow as tf
tf.Session()

Thank you for your post. We noticed you have not filled out the following field in the issue template. Could you update them if they are relevant in your case, or leave them as N/A? Thanks.
Have I written custom code
Bazel version

Have I written custom code: Yes. But I get the error in either of the codes in tensorflow models.
Bazel version: I did not install tensorflow from source, so I did not install Bazel.

Try reinstalling or upgrading tensorflow-gpu.
pip install --upgrade tensorflow-gpu

Nagging Assignee @yifeif: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @yifeif: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @yifeif: It has been 44 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

pip3 install --upgrade --force-reinstall tensorflow-gpu worked for me

Nagging Assignee @yifeif: It has been 16 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @yifeif: It has been 31 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

@oroojlooy is this still an issue for you? Could you check if there is tensorflow folder or tensorflow.py from where you were seeing the error?

@yifeif No, I installed a newer version of Python3.6, then installed tensorflow and it works.

Nagging Assignee @yifeif: It has been 20 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @yifeif: It has been 36 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @yifeif: It has been 51 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @yifeif: It has been 66 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

I close the issue.

Can someone help me? I am getting the same issue.
I have already tried both ways as told by 43061b4a and aznshodan but the problem still persists.

Please open a new issue, filling in the template.
Note that 1.7 is very old and outside of support window. You should consider using 2.0 in which case Session is no longer needed.

thanks @mihaimaruseac
I was encountering this on Tensorflow 2.0 only.
As i am enrolled in a bootcamp so they are teaching us using previous version but in my PC i was getting error as I didn't know that 2.0 don't support Session.
Note:Sorry for grammatical mistakes.

I solved this problem by unistall the tensorflow，and install tensorflow by this "conda create -n tensorflow_env tensorflow"

I'm also encountering this problem on Tensorflow 2.0 . I have no Anaconda install, tensorflow 2 installed in local env of Windows10.

If tf.Session() is deprecated, Please use tf.compat.v1.Session() instead

If tf.Session() is deprecated, Please use tf.compat.v1.Session() instead

sess.run() is not working. is there any alternative?

sess= tf.compat.v1.Session()
sess.run() is not working. its saying, "The Session graph is empty. Add operations to the graph before calling run()"

@rj1346 try the following it worked for me
import tensorflow as tf
with tf.compat.v1.Session() as sess:
a = tf.constant(3.0)
b = tf.constant(4.0)
c = a+b
print(sess.run(c))
sess.close()

If tf.Session() is deprecated, Please use tf.compat.v1.Session() instead

sess= tf.compat.v1.Session()
sess.run() is not working. its saying, "The Session graph is empty. Add operations to the graph before calling run()"

you are getting this error because of the indentation

Same error using ELMo. It seems solved using tensorflow==1.15, that includes CPU and GPU packages.

Guys, this issue is solved and for a very old version of TF. Please open new issue, no one is really watching the closed issues

tensorflow 2.x
import tensorflow as tf
hello = tf.constant('Hello, TensorFlow!')
sess = tf.Session()
print(sess.run(hello))

There is no session in TF 2.x.
Locking conversation as this has been already answered multiple times.


Revert certifi to older version to avoid SSL error

For some reason, using the newer certifi lib results in SSL errors when connecting to AWS S3.

CC @Receiptful/developers


Declarative Gateway Filter Factory for MVC

currently to create filter, we need to use WebMVC function, and it's programmatic, we need to use Java Code : https://docs.spring.io/spring-framework/reference/web/webmvc-functional.html#webmvc-fn-router-functions
In gateway reactive, we have Gateway Filter Factory per route : https://docs.spring.io/spring-cloud-gateway/reference/spring-cloud-gateway/developer-guide.html#writing-custom-gatewayfilter-factories
And use Gateway Filter Factory using properties (declarative)
it's better we also have this for Gateway MVC

I will not be creating a gateway filter factory for mvc


export isl_ast_node as subclasses

Yes, exposing the ast nodes as subclasses is a great idea. Now, tests would obviously be helpful. And at the same time, it would be a lot better for me to see these cleanups to happen in public. As pointed out, we need them in Polly as well and we are waiting since quite some time to get access to them.


Experiment: disallow artifact path traversal

Description
Add an experiment to prevent .. path components in artifact records from causing artifact download to traverse outside the destination path.
A secondary change is the removal of the loop from target path calculation that compared every 100th download path component against the final destination path component; the probability anyone has exercised the code path is effectively zero, and the behaviour would be incredibly surprising if it were hit.
Context
https://linear.app/buildkite/issue/PS-68/fix-surprising-agent-behaviour-in-artifact-download
Changes

Add the experiment
The removal of the astonishing for ... i += 100 loop
A bunch of cleanup

Testing

[x] Tests have run locally (with go test ./...). Buildkite employees may check this if the pipeline has run automatically.
[x] Code is formatted (with go fmt ./...)

I'm strongly considering inverting the experiment, as there's little evidence I can find that anyone is relying on the old behaviour.


[LGO] Bug fix on price increment check + small enhancements.

I've also added the price history (candlesticks) feature

Sorry for the new feature, I thought this PR was already merged and did not verify


broadcast flow has problems with uploading photo

Sometimes, there are problems with the photo ratio
Also, suggest to take the photo in landscape (mention it in the text of the message).

Can we do anything other than specifying the ratio to the PhotoUploadWidget?

Another question, the following message is shown, or what kind of problems happen when uploading the photo?

Could not get the photo of the news item!

When uploading the image, the cropper is shown after selecting or taking a picture, but the ratio at the end is not 16:6
INFO     2017-11-01 11:12:49,602 news.py:416] Image has an invalid ratio. (expected 16:6, got 72:26)

the suggention to take the foto  in landscape is not there yet


WIP: [SETL-113] Check deliveries before computing

Comparing string type and string deliveryId of:

Input Deliverables in the Pipeline and factories output that can be used as an input Deliverable
Needed Deliverable in Factories

Bug with autoLoad = true:
SparkRepository[T]  doesn't match with Dataset[T]


[DOC] enhance distance doc strings

something in differences and clusterers needs further investigation. Keeping this PR because I think it fixes #1857, but I'm sure Franz will have something to say on that.
Note that, clustering and classifying with derivative distances using these functions is very inefficient, since it will repeatedly just take the same differences. It makes much more sense to just take the differences once during fit and predict, so will move to that soon.

@TonyBagnall, sorry, didn´t see this earlier. Changes look good, but :-) for the formulae to display correctly in the docs, I think you need to use :math: (and then accents) instead of TeX dollar.

yeah I have several other doc strings to adapt with distances, I will iteratively work it out :)


Upgrade go-github from v54 to v58

Description of your changes

Fixes #
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable to ensure this PR is ready for review.
[ ] Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

lgtm

thanks for your contribution @iul1an !


Add locale for spanish

Hi, I saw this and wanted to add the spanish translations for this. I saw that in #189 there was a small discussion on whether to make the PR to master or to the Typescript branch. Let me know if the branch is far ahead than what it was a couple of months ago and if the PR should be adjusted or if you would prefer two different PRs (one to master and one to Typescript branch). Cheers from Costa Rica 🇨🇷!

Hey, @CodingAleCR! Thanks for the PR!
Indeed, the PR should be updated on top of the _F-TypeScript branch.
And although not obligatory (at least from @emagnier point of view), it would be awesome if you translate all the keys from src/locales/en.ts file into Spanish. Yes, it might take you some time and you would need to search for some lesser known saints/blesseds (esp those not celebrated in Spanish speaking countries), but it might be useful when viewing calendars with those saints/blesseds in Spanish locale. But yes, that might be dealt with in another PR.
Also it might be a good idea to review the src/calendars/costaRica.ts calendar if it is corrent. Maybe you already did that. :smiley:
And just a note: although it not fully in accord with the JSON standard, we use the final trailing commas at the end of the key values, as you can see in en.ts L788-789. Also note that in that branch, everywhere we use single quotes.
And it might a good idea to use .editorconfig, because e.g. you have removed the final trailing newline from the es.js file. And we use 2 spaces for indentation. However, all of this would be fixed by using .editorconfig settings.
And a final note: current code cannot be just copied over to the _F-TypeScript branch, as we have modified some keys. Also the syntax has been changed a bit (like the keys are not quoted anymore and we are importing RomcalLocale at the beginning. Take you time to update the PR.
And once again, thank you for your time to create this PR! :+1:

Awesome Alejandro! Your work is a very nice addition, thanks a lot!
We are currently working on a major refactor and the Typescript branch isn't ready yet. But no worries, I'll take care of merging your work in the good branch. I'll do a quick review tomorrow or Thursday, so your work will be merged ASAP!

Hey, @CodingAleCR! Thanks for the PR!
Indeed, the PR should be updated on top of the _F-TypeScript branch.
And although not obligatory (at least from @emagnier point of view), it would be awesome if you translate all the keys from src/locales/en.ts file into Spanish. Yes, it might take you some time and you would need to search for some lesser known saints/blesseds (esp those not celebrated in Spanish speaking countries), but it might be useful when viewing calendars with those saints/blesseds in Spanish locale. But yes, that might be dealt with in another PR.
Also it might be a good idea to review the src/calendars/costaRica.ts calendar if it is corrent. Maybe you already did that. 😃
And just a note: although it not fully in accord with the JSON standard, we use the final trailing commas at the end of the key values, as you can see in en.ts L788-789. Also note that in that branch, everywhere we use single quotes.
And it might a good idea to use .editorconfig, because e.g. you have removed the final trailing newline from the es.js file. And we use 2 spaces for indentation. However, all of this would be fixed by using .editorconfig settings.
And a final note: current code cannot be just copied over to the _F-TypeScript branch, as we have modified some keys. Also the syntax has been changed a bit (like the keys are not quoted anymore and we are importing RomcalLocale at the beginning. Take you time to update the PR.
And once again, thank you for your time to create this PR! 👍

Thanks for the .editorconfig tip, will check it and apply the needed fixes. I will check on Costa Rica's calendar but I will do it separately to avoid mixing it up with the translation and for sure put another PR for it. Thanks a lot for the suggestions @tukusejssirs.

As for the .editorconfig you should not need to edit the files manually (as you seamingly did in your last commit); you should use an editor (with .editorconfig plugin if needed; see the .editorconfig website for more info) and simply re-save it.
I have just noticed that you sometimes use el apóstol with el article, sometimes without it. Although my knowledge of Spanish is absolutely minimal, I have found the liturgical calendar for Costa Rica at vercalendario.info, which also uses el apóstol both with and without the article. It might a good idea to get the official directory / liturgical calendar (which should be published annually) or other official liturgical books (like the Roman Missal), but those might be a bit out of date as the celebrations might be moved/removed/changed since the publication date of those books.
However, even if the official books / directory / liturgical calendar should be inconsistent, I would suggent you to be consistent and set (yourself) some rules you would keep. Also you could contact the Liturgical Commision of your diocese and/or country to be more consistent.
And if you know of some linguistic differences in the Spanish Spanish as opposed to Costarican Spanish, you should keep the Spanish Spanish in es.ts and the changes (and only them) for Costarican Spanish in es-CR.ts. Take for example the spelling differences in the American and British Englishes: Savior would go into en.ts and Saviour into en-GB.ts.
Anyway, why do you (and that website sometimes use santo and sometimes san for one single male saint? Like in Santo Tomás el Apóstol and San Antonio Zaccaria, el sacerdote. I’m just curious. Actually, you don’t translated St Anthony Zaccaria. :smiley: I suggest you to copy en.ts fo es.ts and translate all the strings into Spanish. If you choose to not translate celebration names for celebrations that are not celebrated in Costa Rica, that you should remove those lines from the code.

As for the .editorconfig you should not need to edit the files manually (as you seamingly did in your last commit); you should use an editor (with .editorconfig plugin if needed; see the .editorconfig website for more info) and simply re-save it.

Yes, what happened was that my latest commit was fixing a minor mistake I did while installing the plugin for VSCode.

I have just noticed that you sometimes use el apóstol with el article, sometimes without it. Although my knowledge of Spanish is absolutely minimal, I have found the liturgical calendar for Costa Rica at vercalendario.info, which also uses el apóstol both with and without the article. It might a good idea to get the official directory / liturgical calendar (which should be published annually) or other official liturgical books (like the Roman Missal), but those might be a bit out of date as the celebrations might be moved/removed/changed since the publication date of those books.
However, even if the official books / directory / liturgical calendar should be inconsistent, I would suggent you to be consistent and set (yourself) some rules you would keep. Also you could contact the Liturgical Commision of your diocese and/or country to be more consistent.

Whenever we use 'el' in the case of apostles we use it when there's no comma in between, I'll probably change them all to use the comma since it's what we mostly use in spanish.

And if you know of some linguistic differences in the Spanish Spanish as opposed to Costarican Spanish, you should keep the Spanish Spanish in es.ts and the changes (and only them) for Costarican Spanish in es-CR.ts. Take for example the spelling differences in the American and British Englishes: Savior would go into en.ts and Saviour into en-GB.ts.

Yep, in spanish there's not that much of a difference at least regarding the roman calendar since we were all related to Spain at one point or another, that's why I didn't go with creating the es-CR.ts, I think I might even have to check out guides on the difference to be honest, lol

Anyway, why do you (and that website sometimes use santo and sometimes san for one single male saint? Like in Santo Tomás el Apóstol and San Antonio Zaccaria, el sacerdote. I’m just curious.

As a language rule we use santa for all saints that are women, we use san for all saints that are men excepting Tomé, Toribio, Tomás, Domingo which by rule we use santo. As a side note, Santiago does not need to be prepended with anything since the name already includes it. It's a weird language rule to be honest haha but yeah, that's why we use it.

Actually, you don’t translated St Anthony Zaccaria. 😃 I suggest you to copy en.ts fo es.ts and translate all the strings into Spanish. If you choose to not translate celebration names for celebrations that are not celebrated in Costa Rica, that you should remove those lines from the code.

I tried to accomplish the same thing that was done for pt-BR but yeah, I started the job as a copy of en.ts but then proceeded to delete most of the celebrations that I have not seen been celebrated around our latin american countries and in Spain so I don't know if it's necessary to add them all. I did notice, however, that there's no key related to what we call el Día de los Reyes Magos or Día de Reyes which I don't know how it's called in English, I guess it would be (after googling a bit) something like Three Kings Day. This celebration is really important for spanish speaking countries so I don't know if there's a way to add it.
By the way, where did you get the hex color values for the liturgical colors? I've being searching for those for a while now 😮.
P.s: I fixed the usage of el according to how we commonly refer to those days during the celebration.

Yep, in spanish there's not that much of a difference at least regarding the roman calendar since we were all related to Spain at one point or another, that's why I didn't go with creating the es-CR.ts

I was not talking the calendars, but about the language and the celebration names. Calendar and celebration differences (non-linguistic ones) should/will be dealt in src/calendars/*.ts.

I think I might even have to check out guides on the difference to be honest, lol

If you're not sure, don't do anything with this. :smiley: I’d rather wait if any Spanish Spanish speaker would come in and then we’ll fix any issues. But when you learn something, do it the proposed way. :smiley:

As a language rule we use santa for all saints that are women, we use san for all saints that are men excepting Tomé, Toribio, Tomás, Domingo which by rule we use santo. As a side note, Santiago does not need to be prepended with anything since the name already includes it. It's a weird language rule to be honest haha but yeah, that's why we use it.

Thanks for the explanation. The way I get it, san is with male saints, unless the saint’s name with -o or -é or -s, right? I’m quite curious about san/santo Tomás, as here all Tomás are santo except for Tomás Moro—is that correct or is it a mistake? Again, you didn’t list St Thomas More listed in es.js, but the reason might be that we have a joint celebration key only (see en.ts L697. If you miss a key for a celebration, you should create the key and it would be nice of you give us (me) a list of the added keys in order add then fo other languages (I personally would add them at least to en.ts and sk.ts if no one else do that). Anyway, it might be a good idea to double-check if all celebration keys (the celebration names) for all celebrations celebrated in CR are in es.ts.

I tried to accomplish the same thing that was done for pt-BR

Well, from my point of view pt-Br.tss quite incomplete (as far as I can tell, it contains
only celebrations celebrated in PT, which is sufficient for some needs, but I think that translating all the keys to every (supported) language is better, becauce then anyone could generate any calendar in any locale (e.g. the Slovak calendar in Spanish), but I know that (1) one needs more time to translate all the keys; (2) there many people (like me) who would like to check liturgical calendars of other countries.

then proceeded to delete most of the celebrations that I have not seen been celebrated around our latin american countries and in Spain so I don't know if it's necessary to add them all.

Well, if you do it that way, it’ll be better than nothing, but as I said above, it might be better to translate them all if you have the time (even if it would be in a separate PR).

I did notice, however, that there's no key related to what we call el Día de los Reyes Magos or Día de Reyes which I don't know how it's called in English, I guess it would be (after googling a bit) something like Three Kings Day. This celebration is really important for spanish speaking countries so I don't know if there's a way to add it.

Three Kings celebration is officially called the Epiphany [of the Lord]. :smiley: Therefore it is on L14 of es.js. I hope you don’t have a separate celebration with that nams on a date diffedent from 6 January (or the Sunday following it)—I could find it here at least.

By the way, where did you get the hex color values for the liturgical colors? I've being searching for those for a while now 😮.

I am not sure what exactly do you mean by hex colours, but AFAIK the colours aren’t defined in romcal apart from `lliturgical-colors.constant.ts](https://github.com/romcal/romcal/blob/_F-TypeScript/src/constants/liturgical-colors.constant.ts. I think fhe exact colour code might be defined in [`romcal-api` repo, but @emagnier might know better.

I was not talking the calendars, but about the language and the celebration names. Calendar and celebration differences (non-linguistic ones) should/will be dealt in src/calendars/*.ts.

Oh, yeah, sorry. I was referring to the same thing but didn't explain myself well enough.

Thanks for the explanation. The way I get it, san is with male saints, unless the saint’s name with -o or -é or -s, right? I’m quite curious about san/santo Tomás, as here all Tomás are santo except for Tomás Moro—is that correct or is it a mistake? Again, you didn’t list St Thomas More listed in es.js, but the reason might be that we have a joint celebration key only (see en.ts L697. If you miss a key for a celebration, you should create the key and it would be nice of you give us (me) a list of the added keys in order add then fo other languages (I personally would add them at least to en.ts and sk.ts if no one else do that). Anyway, it might be a good idea to double-check if all celebration keys (the celebration names) for all celebrations celebrated in CR are in es.ts.

Kind of, so, here's the thing, you would only use Santo when you are using the specific names: Tomé, Toribio, Tomás, Domingo. I think the website you are using even uses it for one called Charbel which is a saint I've never heard of so I can't give the specifics on the why they do it.

Three Kings celebration is officially called the Epiphany [of the Lord]. 😃 Therefore it is on L14 of es.js. I hope you don’t have a separate celebration with that names on a date different from 6 January (or the Sunday following it)—I could find it here at least.

Gotcha, yeah, then it should probably stay the same in spanish. I guess my confusion was due to the popular name that's been given to the celebration. You are correct on that.

Well, from my point of view pt-Br.tss quite incomplete (as far as I can tell, it contains
only celebrations celebrated in PT, which is sufficient for some needs, but I think that translating all the keys to every (supported) language is better, becauce then anyone could generate any calendar in any locale (e.g. the Slovak calendar in Spanish), but I know that (1) one needs more time to translate all the keys; (2) there many people (like me) who would like to check liturgical calendars of other countries.

Oh, I understand, I will try to do that, although it's difficult with some names since there's no translation for them, do you suggest I leave those as is and just translate the 'saint' to 'san' accordingly?

I am not sure what exactly do you mean by hex colours, but AFAIK the colours aren’t defined in romcal apart from liturgical-colors.constant.ts. I think fhe exact colour code might be defined in romcal-api repo, but @emagnier might know better.

What I meant to ask is, are those the official hex color values? Meaning, is that the standard liturgical colors for everything Church-related?

Oh, I understand, I will try to do that, although it's difficult with some names since there's no translation for them, do you suggest I leave those as is and just translate the 'saint' to 'san' accordingly?

The way I did it for the Slovak locale (sk.ts) is that I searched the Internet if those names are already used somewhere on a Slovak website. If I did not find that name (which happened very rarely), I simply translated the first name into Slovak (which is kind of tradition coming from Latin) and for female saints added a suffix of -ova (which is a Slovak grammar rule). For the names like St John of the Cross we need to translate the of the Cross part too. In general, try to localise the names as naturally as possible and follow the way it is already done for other, similar names.

What I meant to ask is, are those the official hex color values? Meaning, is that the standard liturgical colors for everything Church-related?

Aaah, sorry, I think you mean LiturgicalColors.js from the master branch. I was talking about the Typescript branch, which does not have the hex colour codes.

There is no official shade of a particular colour that must be used.

I advise you to use the _F-TypeScript for development, where there are many (breaking) changes in comparison with the master and which will be released probably in August 2020.

Ok sounds great, I will try to do the full translation over the weekend.
Thanks for all the guide around this and the effort the team is making to improve this library! 🥳🎉

Thanks for your contribution @CodingAleCR !
Yes if you feel confortable to work on the Spanish translation from the _F-TypeScript, go for it 😉
I'm currently planning to have a few days at the beginning of august dedicated to Romcal. So if all goes well, we could get a new release by the end of august, containing a major refactor and a switch to Typescript.
And about the liturgical colors, Romcal will output a color name only, because the General Instruction of the Roman Missal only recomnand a color, without any specific color code. Then you are free to use any hex color in your app, based on this name outputed by Romcal.

Hola @CodingAleCR ! I took a quick look on your work and everything looks good 🍻! Although I'm not a Spanish speaking, I made 2 years of Spanish at school but it's been a long time ago now 😄
Do you think you will have the time to adjust your PR on the Typescript branch? If it's possible, that would help us a lot. Otherwise I will try to do something during the next month.
And about translating everything in Spanish, I will say it's a nice to have, but not a priority. As far as we can have the necessary for most of the Spanish speaking calendars (this is the great job you already made).
Having everything translated is only a requirement in English (for example, if you add a localisation key in Spanish, you will have to add it in English as well).
For the translation, calendars and keys in general, you can lean on @tukusejssirs, he is the keeper of all the localisation work!

Hi, yes, I will update it to point towards the Typescript branch, I have being waiting to see how it is implemented with the new PR that I just noticed was merged. I will also update the needed keys. What I was thinking, since it would take less time, was that I could translate the current keys and then add the missing ones in the future to have parity with english. I also found a couple of keys that I might add since they are common celebrations in spanish speaking countries.

[@CodingAleCR]
[…] and then add the missing ones in the future to have parity with english. I also found a couple of keys that I might add since they are common celebrations in spanish speaking countries.

Just double-check if the celebrations actually aren’t in en.ts (they might be there with different key name/value. When unsure, rather ask us before you actually add a new key (just to remove any possibility of introducing yet another duplicate).

Will do, for example I wanted to add this one (https://en.wikipedia.org/wiki/Virgen_de_los_Angeles) which is roughly translated to Our Lady of the Angels. It is our patron here in Costa Rica but I have it on good authority that it is celebrated across Central America as well

Yeah, that one is indeex missing. And there are a few churches in the US with that patron (incl the Cathedral of Our Lady of the Angels).
I’ve noticed that you have written the first letter of the titles (like priest, doctor of the Church or virgin) in uppercase—is it really writte that way?

@CodingAleCR, I have no idea if you have already started the l10n (I have not found any new code in your fork of romcal), but just now I have found a quite good source of Spanish names of the lesser known saints and blessed: Martirologio Romano (2001). It is a Spanish translation of the original Martyrologium Romanum from 2001, which is written in Latin. How much it is official and/or accurate, I cannot tell.
There is a newer edition of MR, the MR2004 which is currently officially in Latin only and the Wiki says this about the differences between the two editions:

After the Second Vatican Council, a fully revised edition was promulgated in 2001, followed in 2005 by a version (bearing the publication date of 2004) that adjusted a number of typographical errors that appeared in the 2001 edition and added 117 people canonized or beatified between 2001 and 2004, as well as a number of more ancient saints not included in the previous edition. "The updated Martyrology contains 7,000 saints and blesseds currently venerated by the Church, and whose cult is officially recognized and proposed to the faithful as models worthy of imitation."

Wow, that's a great find, I have started the work but have not pushed to the repo, I'll try to compliment and verify translations with that resource. Do you plan using it for Latin translations?

You might push your work to the repo and than change the branch in this PR. That way we might see some progress (see #207 PR, where I push a new commit each day I work on it); the commits will be squashed before merging.

Do you plan using it for Latin translations?

I’d like get the MR2004 and then use it as the base for the more comprehensive list of venerated persons. I’d like to use all the saints/blesseds feom MR2004, all the saints/blesseds addes since 2004, as well as saints/blesseds which are not in the MR2004, but they are celebrated at least in one particular calendar. But currently I have no access to it.

Just a note: the MT2001_es I have shared contains only months July to December; here is the first part, i.e. January through June. ;smiley:

And also suggest to keep an eye on #208 issue.

Alright, I will add my changes and change branch so you can make the suggestions we might need.

@CodingAleCR, could you please note down what sources have you used for the localisation (and later for the calendar of Costa Rica)? If you used online sources (publicly available), the URL is enough; if you used some printed books, some bibliographical metadata would be nice to have (at least book name, publisher and year). I’d like to create a list of validated calendars and locales. Thanks in advance.

Hello @CodingAleCR,
Instead of merging your PR into master, I've cherry-picked all your work from this PR to the _F-TypeScript: https://github.com/romcal/romcal/commit/2d6992f0a293c5aeee4277b7b29fbcb2587684a5
We are about to do a massive refactor of all locale keys, but we wanted to have all your work into our new TypeScript codebase. FYI, in a few days we plan to do a release of our new codebase in the dev branch.
Thanks again for all this nice work! 🎉 🎉 🚀
If you made other work since that you didn't push yet, please let us know, and we will see how to integrate your work.

I'm sorry I didn't get to it in time, stuff's being crazy at work. Hope it helps out, I really do believe it's awesome what you people are doing 🙌🏼🎉

No worries, thank you for your message 😉
And Spanish locale makes a great addition for romcal!

@CodingAleCR, there are some keys which are not (fully) localised:
saintBeunoAbbot: 'Saint Beuno, Abbot',  // This key is not localised at all
saintRomualdAbbot: 'Sant Romuald, Abbot',  // Sant or San? Abbot or Abad?
saintAlbanMartyr: 'Saint Alban, Mártir',  // Saint or San?

My another question is if in Spanish the titles (like abbot, priest, pope) in the celebration names are capitalised (i.e. the first letter is in uppercase) or not. I have the expression you tried to localise the English keys as faithfully as you could, however, I believe it would be better if you tried to be as faithful as possible the the Spanish language.
Could you re-read es.ts please? I think there are more issues with the current version of es.ts.

So, according to the RAE (biggest authority regarding the Spanish language) with titles, particularly the ones we are using here ("abad"-abbot, "presbítero"-priest, "papa"-pope) can be written just fine in lowercase. I think I left most capitalized so they might need correction.
The thing is that with Spanish, the proper way would be with lowercase. However, you sometimes can refer to those as capitalized out of respect, it's something called "mayúsculas genuflexivas". I would suggest using lowercase however just to comply with language rules.

So, according to the RAE (biggest authority regarding the Spanish language) with titles, particularly the ones we are using here ("abad"-abbot, "presbítero"-priest, "papa"-pope) can be written just fine in lowercase, especially in the cases that the word is used a lot in the text. However, you sometimes can refer to those as capitalized out of respect, it's something called "mayúsculas genuflexivas".
Now, that rule changes a bit when we are referring to celebration names, whenever you are writing the name of a celebration, you should always write the substantives and adjectives in the name capitalized, this has to be done regardless of it being a civil, military or religious festivity.

So, according to the RAE (biggest authority regarding the Spanish language) with titles, particularly the ones we are using here ("abad"-abbot, "presbítero"-priest, "papa"-pope) can be written just fine in lowercase, especially in the cases that the word is used a lot in the text. However, you sometimes can refer to those as capitalized out of respect, it's something called "mayúsculas genuflexivas".

Thanks for the answer. I have read this Spanish article (translated to English) on those mayúsculas genuflexivas (genuflective capital letters). It seems that the Spanish language at least prefers not using the mayúsculas genuflexivas. It seem to me as this practice is similar to English language, where is is grammatically correct the use the Pope, the President or the Prime Minister when talking about a particular person (it is incorrect to use the pope with lowercase letter, but a pope or the popes is correct).
It might a good idea to localise all titles (I have already created a list of them in a Google Sheets table) in order to help me correct this issue.
Another subissue: do you use uppercase first letter in names of Our Lady (e.g. Patroness, Medeatrix)?

Now, that rule changes a bit when we are referring to celebration names, whenever you are writing the name of a celebration, you should always write the substantives and adjectives in the name capitalized, this has to be done regardless of it being a civil, military or religious festivity.

You mean you use title case in titles and heading of articles/books? Do you use similar title case rules to those defined by Chicago Manual of Style? The general rules are that all nouns, adjectives, pronounes, verbs, numbers are written with uppercase first letter and the last word of the title/heading is capitalised. Usually, the words with less than four letters are written in lowercase.
https://titlecaseconverter.com/

So, according to the RAE (biggest authority regarding the Spanish language) with titles, particularly the ones we are using here ("abad"-abbot, "presbítero"-priest, "papa"-pope) can be written just fine in lowercase, especially in the cases that the word is used a lot in the text. However, you sometimes can refer to those as capitalized out of respect, it's something called "mayúsculas genuflexivas".

Thanks for the answer. I have read this Spanish article (translated to English) on those mayúsculas genuflexivas (genuflective capital letters). It seems that the Spanish language at least prefers not using the mayúsculas genuflexivas. It seem to me as this practice is similar to English language, where is is grammatically correct the use the Pope, the President or the Prime Minister when talking about a particular person (it is incorrect to use the pope with lowercase letter, but a pope or the popes is correct).
It might a good idea to localise all titles (I have already created a list of them in a Google Sheets table) in order to help me correct this issue.

Yes, it could be a good idea, not sure if it's something you might want to abstract though since it might be more effort maintaining it.

Another subissue: do you use uppercase first letter in names of Our Lady (e.g. Patroness, Medeatrix)?

Yes we do, "Nuestra Señora", "Patrona",  "Mediadora", "Mother" are all used capitalized normally.

Now, that rule changes a bit when we are referring to celebration names, whenever you are writing the name of a celebration, you should always write the substantives and adjectives in the name capitalized, this has to be done regardless of it being a civil, military or religious festivity.

You mean you use title case in titles and heading of articles/books? Do you use similar title case rules to those defined by Chicago Manual of Style? The general rules are that all nouns, adjectives, pronounes, verbs, numbers are written with uppercase first letter and the last word of the title/heading is capitalised. Usually, the words with less than four letters are written in lowercase.
https://titlecaseconverter.com/
It's a little bit different than a title case, we do not capitalize articles used in the name of a festivity, for example: "Sacred Heart Of Jesus" is translated to "Sagrado Corazón de Jesús". Same way we would not capitalize articles in Spanish like "la", "el", "de", "los", "sus" amongst others.

Also, I fixed the missing translations in #219.

Yes, it could be a good idea, not sure if it's something you might want to abstract though since it might be more effort maintaining it.

Context: I have proposed to moved all titles from the l10n keys to the celebration definitions (i.e. calendars; see #201, #154 and #208), therefore in the end, we will (hopefully) remove the titles from the l10n keys.
Question: Why do you think that it might be more effort maintaining it?

It's a little bit different than a title case, we do not capitalize articles used in the name of a festivity, for example: "Sacred Heart Of Jesus" is translated to "Sagrado Corazón de Jesús". Same way we would not capitalize articles in Spanish like "la", "el", "de", "los", "sus" amongst others.

I (as many others, but not everybody) differentiate between title case (sometimes called true title case) and First Letter Uppercase (sometimes called title case). Sacred Heart Of Jesus is chiefly used in North America. However, Chicago Manual of Style says the following (CMOS, paragraph 8.159 is the source, but you need to have at least a free trial subscription and log in):

The conventions of headline style are governed mainly by emphasis and grammar. The following rules, though occasionally arbitrary, are intended primarily to facilitate the consistent styling of titles mentioned or cited in text and notes:

Capitalize the first and last words in titles and subtitles (but see rule 7), and capitalize all other major words (nouns, pronouns, verbs, adjectives, adverbs, and some conjunctions—but see rule 4).
Lowercase the articles the, a, and an.
Lowercase prepositions, regardless of length, except when they are used adverbially or adjectivally (up in Look Up, down in Turn Down, on in The On Button, to in Come To, etc.) or when they compose part of a Latin expression used adjectivally or adverbially (De Facto, In Vitro, etc.).
Lowercase the common coordinating conjunctions and, but, for, or, and nor.
Lowercase to not only as a preposition (rule 3) but also as part of an infinitive (to Run, to Hide, etc.), and lowercase as in any grammatical function.
Lowercase the part of a proper name that would be lowercased in text, such as de or von.
Lowercase the second part of a species name, such as fulvescens in Acipenser fulvescens, even if it is the last word in a title or subtitle.

We might want to use change-case NPM package:

titleCase readme;
titleCase example from the main readme of the package;
titleCase function source code.

It also supports capitalCase and sentenceCase.


dapr init -k --dev is in crash loop on redis init, failing redis component load

Actual
This quickstart repro's the issue.

This appears to only happen in the GH action runner, and not on my local kind installations.
https://github.com/dapr/quickstarts/actions/runs/9702023201/job/26776912327#step:18:82
Expected
It should look like this fully passing

Steps to Reproduce the Problem

Release Note

RELEASE NOTE:

@paulyuk I've tested this locally and see that it works in the GH runners now, can we consider it fixed?


Align ER diagrams and dataset docs across frontends

data.world and Kaggle currently use an asset diagram that is different from the newest, mermaid based, one from the README. We should aim for presenting the same diagrame across all frontends.
Additionally, some asset and column descriptions that that are available in the dataset schemas are not displayed. It would be ideal to align metadata across all frontends.

The first part (ER diagram) closed in the related PR.
As for the second one (column description)

This should already be working for Kaggle, as we are filling up these details in the metadata file as recommended here. Still column description are not populated correctly in Kaggle, hence the issue seems to be with their API, or at least with there python client
Doing this in data.world would require working with their API and making individual calls for each column to have these details populated. It sound quite a bit of effort, and it's not clear the the users would benefit a lot from this, since the column descriptions are anyways quite hidden in their UI

Given the above, I'll not make the time investment to add the column and asset desc in these two frontends in the near future.


feat: support ESM subpath imports

Description

resolve #7385
Vite now uses https://github.com/lukeed/resolve.exports to determine the target file of exports filed. According to the node.js spec and this https://github.com/lukeed/resolve.exports/issues/14. This PR made a little fork of resolve.exports based on https://gist.github.com/okikio/3f07571c7707dc6e6eb4906b951c6bc3 to implement resolve.imports. We can remove the code from Vite until resovle.exports supports imports filed.
Additional context

https://github.com/fi3ework/vite/blob/7acab6a9db3aecb7b11d955598c1b48d58f7956b/packages/vite/src/node/plugins/resolve.ts#L152-L154
This PR re-assign id at the beginning for imports, I'm not sure is it the best way to do this or we could add another plugin like pre-alias? 🤔

The test cases referenced https://github.com/evanw/esbuild/commit/62a3943bfc354898442b6cd8b5291c749bebfa05

What is the purpose of this pull request?

[ ] Bug fix
[x] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[x] Ideally, include relevant tests that fail without this PR but pass with it.

Any blockers for this one?

Awesome job, been looking for a way to do this, hope will be merged soon :)

Maybe this isn't the right place, but if you're using package.json (assuming I got it right)  for storing the module maps, that means everything else would have to infer from it.
Wouldn't that be an issue, if you would have to repeat it again for TSConfig?

Update: From the last team meeting, we discussed that this is a feature we want, but we would want to use a centralized standard package to resolve subpath imports instead of a fork. We're currently coordinating with @lukeed to get this done, and after that we can update this PR to use it.

Hi guys, vite newcomer over here, first of all, let me tell you how amazing vite project it's, in our case we've been already suffering some issue with a large CRA app that has hundreds of components and I'd really like to give it a shot to vite eventually but there are few blockers I'd need to solve before reaching that point and one of them being subpath imports support by the bundler.
I've tried to see if subpath imports was already working with latest vite atm<EMAIL_ADDRESS>but it seems is not, then I just found this PR.
Attaching a little reproducer in case it may help somehow test_storybook_subpath_imports.zip
When uncommenting line 2 of

You should get a crash like

Also, I guess this feature should be able to handle properly subpath imports containing non-js/jsx code, right? ie: assets such as json, svg, css, ...
ie: import reactLogo from '#assets/react.svg'`

It seems like https://github.com/privatenumber/resolve-pkg-maps is an alternative to https://github.com/lukeed/resolve.exports. Maybe we could move to resolve-pkg-maps as resolve.exports hasn't been maintained for a while. There is some difference described in https://github.com/privatenumber/resolve-pkg-maps, not sure these will be the breaking change. 🤔

@fi3ework I think it is a good idea. IIRC @aleclarson also started a fork of lukeed/resolve.exports. Alec, it would interesting to hear your opinion here about @privatenumber new library.

We already have https://github.com/vitejs/vite/pull/10504 and https://github.com/vitejs/vite/pull/7770 to integrate @alloc/resolve.exports with Vite. I think there's value in using a solution built with Vite in mind, instead of a general purpose solution. Also, I think merging my resolve.exports fork into the Vite org would be worth while, so we don't have to rely on a third party for bug fixes to this critical piece of Vite's path resolution going forward.

I like how “critical” resolve.exports is to vite & how much chatter there has been about it here (and elsewhere) yet there are no PRs from the work done here to fix the few bugs & add the really easy imports support. Nor have there been any offers to fund its maintenance or continued support. Not sure if it’s because people continue to assume/expect me to be a full-time OSS maintainer for free or because they see an opportunity to fork/copy-edit a new variant to siphon some “popularity” … either way, OSS has become such a game and I’m not here for it. Vite/Vue is sitting on a pile of cash & should be setting a clear example, while it has the attention, for how an open source ecosystem can grow and thrive sustainably instead of relying on an exorbitant amount of free labor.

Hey @lukeed, first of all, thank you for your work on resolve.exports. Please note that we would never consider it your responsibility to implement anything that Vite needs specifically. It is your package, we do not expect anything more than what you've already done.
On the other hand, I think your accusation of "relying on an exorbitant amount of free labor" is misdirected. Vite is not making "a pile of cash" by any means. Our sponsorships barely generate enough to cover the salary of an entry level engineer, and we try to disperse it among team members who make consistent, direct contribution to Vite itself. Also do note I actually work on OSS fulltime, sponsor a lot of other devs in the Vue / Vite ecosystem, and need to make a living. Funding dependencies will be nice and we may consider it in the future, but I don't think that should be considered a responsibility.
We used resolve.exports because it aligned with what Vite needed. I think a fork / replacement is considered mainly because (1) assumed maintenance inactivity on resolve.exports. and (2) the possibility of needing more, maybe Vite-specific logic in the future.
The part I think we should have done better here is better communication with you from the beginning. I also 100% agree that we should've submitted a PR with the desired feature before moving towards a fork. Would you be open to consider that if we did?

I like how “critical” resolve.exports is to vite & how much chatter there has been about it here (and elsewhere) yet there are no PRs from the work done here to fix the few bugs & add the really easy imports support. Nor have there been any offers to fund its maintenance or continued support. Not sure if it’s because people continue to assume/expect me to be a full-time OSS maintainer for free or because they see an opportunity to fork/copy-edit a new variant to siphon some “popularity” … either way, OSS has become such a game and I’m not here for it. Vite/Vue is sitting on a pile of cash & should be setting a clear example, while it has the attention, for how an open source ecosystem can grow and thrive sustainably instead of relying on an exorbitant amount of free labor.

@lukeed I feel a need to defend myself here. My fork of resolve.exports was strictly out of necessity. I just don't have the time or desire to jump through the hoops needed to get a PR merged into your library. I mean no offense. It really doesn't matter whether your library, a fork of it, or another library entirely is used for imports/exports mapping. What matters is that Vite users get this feature as soon as possible. I've done as much as I can to provide for that within my means. Finally, might I ask that you refrain from posting criticism openly before reaching out in private.

We all know it’s much easier to patch fixes than it is to set up a new repo with all new tests, docs, and comparisons.  And there’s nothing Vite needs that the ”general public” doesn’t also need. So I don’t understand that argument.
@yyx990803 theres clearly been motions towards a desired outcome already. Not that it was intentional or that you had any part in it, but the work has already been done and I’m not motivated by others’ desire for exposure/popularity/downloads. I have real bills to pay now and so OSS dramatically fell off the wayside. Congrats to you & others who’ve made it financially feasible, but I’ve invested 60+ hour weeks into OSS for years now and can’t justify “exposure” and “networking opportunities” for the time spent any more. I don’t mean this to be a personal soap opera hour but I’ve given away $500k equivalence of consulting hours over the years for little return. I don’t care about resolve.exports but it seemed like a great opportunity to point out the issues in OSS that are/were present here & I feel like Vite is in a great place to start changing things. Myself removed.

It really doesn't matter whether your library, a fork of it, or another library entirely is used for imports/exports mapping. What matters is that Vite users get this feature as soon as possible.

Imho it does matter to the node/web ecosystem at large. Having multiple packages doing the same thing in often subtly different ways isn't great. Fragmentation and all. This would hurt vite in the long run too as it has to deal with the fallout of any incompatibilities that arise out of this mess.
Vite has been great at working together with some upstream packages it depends on, rollup being the most prominent example here. Extending that pattern to other packages would benefit everyone. Sharing the burden of maintaining, using the public outreach it has to match up people who want to help with projects that need help etc. magic-string has been another example at this.
So please lets do OSS cooperation instead of fragmenting things even more :pleading_face:

resolve.exports@next just went out for early preview. It includes "imports" support via an imports function. The resolve function still exists & acts the same, but it's actually a convenience helper that reroutes to r.imports() or r.exports() depending on the target specifier it received. You can look over the API docs for more info.
Planning to release 2.0 stable this Monday or Tuesday if all looks to be ok

Sorry, forgot to come back here with an update – the 2.0 was released a day after my last comment.

Thanks @lukeed! It looks like Vite was upgraded to 2.0 here: https://github.com/vitejs/vite/pull/11712. We'll need another PR to leverage the imports support

Ah cool! :)

Have updated this PR with resovled.exports 2.0. Looking for some code reviews. 👀

Amazing! thanks @fi3ework for the hard work on this!

Having read through the PR finally, I just realized that a massive thank you needs to go to @lukeed. I recognize the burden of maintaining OSS, and I appreciate all the work you're putting in for the rest of us!

Thanks :) big thanks to @fi3ework for the integration here & to @bluwy for the all-around encouragement/motivation

Unless I am using this incorrectly this doesn't appear to work in-situ. It does resolve a subpath import correctly but it cannot be used with a real world codebase because import-analysis does not understand what to do with a subpath import when given it and so it resolves to null instead which returns:
PM [vite] Internal server error: Failed to resolve import "#src/routes/app_router" from "src/main.tsx". Does the file exist?
Plugin: vite:import-analysis
File: /path/to/codebase/apps/www/src/main.tsx:1:26
4  |  import { $$registry as _$$registry } from "solid-refresh";
5  |  const _REGISTRY = _$$registry();
6  |  import { AppRouter } from '#src/routes/app_router';
   |                             ^

Annotated with a bunch of console.log statements when trying to debug this I can see the following:
(1) asked to resolve: #src/routes/app_router
(2) asked to resolve: #src/routes/app_router resolved to: [ './src/routes/app_router.js' ]
(3) poroblem is here: null

(1) is from within vite:import-analysis right before it switches on if (!resolved).
console.log('asked to resolve:', url)
const resolved = await this.resolve(url, importerFile);
                if (!resolved) {

(3) is from within that if statement.
(2) is from within vite:resolve.
import-analysis calls some resolve method (I'm working with the post-bundled source here so there are umpteen definitions for that function) which doesn't know what to do hence the failure.
I'll try actually find this in the normal codebase before it's been bundled.
Minimum reproducible example here: https://stackblitz.com/edit/github-c6tkmr-1eubsp?file=src/index.tsx

Looks like it's because your import map entry is:
"#src/*": "./src/*.js"

but you're using a TypeScript import:
import { Foo } from '#src/foo';

to resolve ./src/foo.tsx.
Vite will need a TypeScript compliant resolver for this. I'm actually working on one for tsx because it has the same issues.

Looks like it's because your import map entry is:
"#src/*": "./src/*.js"

but you're using a TypeScript import:
import { Foo } from '#src/foo';

to resolve ./src/foo.tsx with a .js extension.
Vite will need a TypeScript compliant resolver for this. I'm actually working on one for tsx because it has the same issues.

AFAIK that is correct because Typescript does not rewrite import paths (even though they actually do but that's a whole different discussion and a contentious one within the Typescript repo). Specifically here they do not rewrite the extensions. Even without an import map the only way to use that component would be to import it with the .js extension even though on-disk it is a .tsx component because after compilation it will be a .js file and... Typescript does not rewrite extensions.

Question as far as I can tell, this is not working atm for vite 5.2.11. I still had to provide a tsconfigPaths() plugin to my vite.config.ts file.


SSD1306 dimensions

Can you please specify the dimensions of your tested SSD1306 display?
I seem to own a SSD1306 1.3" display and it does not work well with this library. It shows only 5-10% of the display area and the rest is just white noise

I've used a 0.96" display with 128x64 pixels. Did you specified the right width and height when using ssd1306_init ?https://github.com/daschr/pico-ssd1306/blob/088f5e68daae73e87293c512da7ab75437cf35bc/ssd1306.h#L86
Make sure that there's no loose connection between the display and the controller, I've experienced your issue caused by that.

Make sure that there's no loose connection between the display and the controller,

It helped me when I used external pull up resistors too, and no I dont think there is a loose connection issue here as I have used decent quality wires

I just tested it using my arduino, and then realised I need an equivalent of U8glib.h for RPi pico.


Adding user authentication option in apk-generator

Actual Behaviour
As the user authentication option is added we can now add an option to enable user authentication.
Expected Behaviour
Doing the above changes.
Steps to reproduce it

LogCat for the issue

Screenshots of the issue

Would you like to work on the issue?
Yes.
Target Milestone to solve the issue
https://github.com/fossasia/open-event-android/milestone/35

@arp95 Could you please describe the issue in some detail. I don't exactly get the issue.


Remove A, MR, AN, THE etc from nouns before checking dictionaries

A, AN, THE, MR, MS, MRS, DR, (and more I'm sure) are getting pulled out as part noun phrases and causing the term not to match what it needs to in the dictionaries. Before that step happens, they should be deleted.
See, for example these [fictitious!!!] sentences. The first one does not code, the second one does.
"The head of Russia’s foreign intelligence service met with Mr. Assad in Damascus."
"The head of Russia’s foreign intelligence service met with Bashar al-Assad in Damascus."
This sentence only gets coded when THE_EUROPEAN_UNION gets added to the dictionaries:
"The Philippines and the European Union (EU) agree that territorial disputes in the South China Sea should be resolved through international arbitration."

It works now in my tests.


Multiple models using same table behave inexplicably

There seems to be one other issue involving how to use Single Table Inheritance, however I believe it would make sense to either throw an error or at the very least address this situation in the documentation. Currently Waterline will just pick one of the models, and the remaining models will have an empty schema/fail silently should they be connected to the same DB table.

Leaving some feedback regarding this issue.
We are trying to get into sails.js to provide the API part of our tech stack upgrade and software overhaul. however our database design is rather basic at the moment and a lot of data which could be considered separate is currently lumped into the same table. Trying to create an API for our old database design is proving troublesome because of this issue.
I've attempted @rudeluv's "fix" unsuccessfully; specifying a where clause in the find method and not.
There are a few ways I see around this, most undesirable. One is to bypass the blueprint API altogether and create my own responses via the query function in the controllers. The other is to create views of the table containing the desired columns, effectively creating two new tables to model off of.
Stack is Sails.js (Waterline) and Postgres by the way.
To reproduce the issue I have a table which is called 'exampletable' with around 10 columns called 'columnone' - 'columnten'. I then create 2 APIs using the sails generate API CLI called 'modelone' and 'modeltwo'. Within the models the code looks something like this:
module.exports = {
	tableName: 'exampletable'
	,attributes: {
		id: {
			type: 'number'
			,columnName: 'columnone'
			,primaryKey: true
		}

		,column_two: { type: 'string', columnName: 'columntwo' }
		,column_three: { type: 'string', columnName: 'columnthree' }
		,column_four: { type: 'string', columnName: 'columnfour' }
	}
};

With the second model having similar code except the columns are for 5-10 (including the ID column).
Calling these APIs (with Blueprint controller) results in one containing the correct response of JSON, with  the attribute names paired with the column values; calling the other API results in JSON of the first model's data except the attribute names are replaced with raw column names.
modelone:
[
  {
    "column_two": "columntwo value",
    "column_three": "columnthree value",
    "column_four": "column_four value",
    "id": 1
  }
]

modeltwo:
[
  {
    "columntwo": "columntwo value",
    "columnthree": "columnthree value",
    "columnfour": "columnfour value",
    "id": 1
  }
]

Where you would expect 'modeltwo' to look something like:
[
  {
    "column_five": "columnfive value",
    "column_six": "columnsix value",
    "column_seven": "columnseven value",
    "column_eight": "columneight value",
    "column_nine": "columnnine value",
    "column_ten": "columnten value",
    "id": 1
  }
]


Have this error when trying to configure the plugin

javax.lang.model.type.UnknownTypeException: Unknown type: java.lang.Object&java.io.Serializable&java.lang.Comparable (com.mysema.maven:apt-maven-plugin:1.0.5:process:default:generate-sources)
		<plugin>
<groupId>com.mysema.maven</groupId>
<artifactId>apt-maven-plugin</artifactId>
<version>1.0.5</version>
<executions>
    <execution>
        <goals>
            <goal>process</goal>
        </goals>
        <configuration>
            <outputDirectory>target/generated-sources/java</outputDirectory>
            <processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
        </configuration>
    </execution>
    </executions>
    <dependencies>
        <dependency>
            <groupId>com.mysema.querydsl</groupId>
            <artifactId>querydsl-apt</artifactId>
            <version>${sm-core.querydsl.version}</version>
        </dependency>
        <dependency>
            <groupId>com.mysema.querydsl</groupId>
            <artifactId>querydsl-jpa</artifactId>
            <classifier>apt</classifier>
            <version>${sm-core.querydsl.version}</version>
        </dependency>
    </dependencies>
</plugin>

Which Querydsl version do you use? And which JDK? Also do you have the full stacktrace?

@shopizer-ecommerce Could you provide a little bit for information on your issue?

Closing due to lack of response. Please comment again and we can reopen the issue if you're still having trouble.

This issue is related to kind of instrumentation in the class JPAAnnotationProcessor. It should have been fixed in mentioned but for the time being, following is the way around of this problem.
modify class definition of  com.salesmanager.core.business.generic.model.SalesManagerEntity to
SalesManagerEntity<K extends Comparable<K>, E extends SalesManagerEntity<K, ?>>

Could you provide the full stacktrace?
On 17 Jun 2015 08:15, "SheikhG1900"<EMAIL_ADDRESS>wrote:

This issue is related to kind of instrumentation in the class
JPAAnnotationProcessor. It should have been fixed in mentioned but for
the time being, following is the way around of this problem.
modify class definition of
com.salesmanager.core.business.generic.model.SalesManagerEntity to
SalesManagerEntity<K extends Comparable, E extends
SalesManagerEntity<K, ?>>
—
Reply to this email directly or view it on GitHub
https://github.com/querydsl/apt-maven-plugin/issues/33#issuecomment-112653890
.

I was having same error mentioned by @shopizer-ecommerce that is
javax.lang.model.type.UnknownTypeException: Unknown type: java.lang.Object&java.io.Serializable&java.lang.Comparable (com.mysema.maven:apt-maven-plugin:1.0.5:process:default:generate-sources)

Actually problem was in JPAAnnotationProcessor it is assuming java.lang.Object&java.io.Serializable&java.lang.Comparable a single class, instead of checking them individually.

hi @SheikhG1900  i wonder how to fix these problem.
i just can't import  shopizer into eclipse for developing without problems.

@karlchan-cn
modify class definition of com.salesmanager.core.business.generic.model.SalesManagerEntity to
SalesManagerEntity<K extends Comparable, E extends SalesManagerEntity<K, ?>>
it is the workaround, not a proper resolution.
Hope it will help you.

@SheikhG1900
Thanks SheikhG1900.but can you pls send all the modifications by email to<EMAIL_ADDRESS>

I changed the version of com.mysema.querydsl:querydsl-* to the newest 3.6.6 and compile works fine now. I'm using JDK8u45.

i have the same problem and i solve it use @SheikhG1900 provided method,but now i meet another problem when i use Right-click shopizer > Run As > Maven install :below is my full full stacktrace:
[INFO] Reactor Summary:
[INFO]
[INFO] shopizer ........................................... SUCCESS [  0.490 s]
[INFO] sm-core-model ...................................... SUCCESS [ 21.172 s]
[INFO] sm-core-modules .................................... SUCCESS [  0.747 s]
[INFO] sm-core ............................................ FAILURE [03:32 min]
[INFO] sm-shop ............................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 03:55 min
[INFO] Finished at: 2015-10-05T12:51:05+08:00
[INFO] Final Memory: 36M/350M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project sm-core: Could not resolve dependencies for project com.shopizer:sm-core:jar:2.0.3-SNAPSHOT: The following artifacts could not be resolved: com.shopizer:sm-search:jar:0.0.5-SNAPSHOT, com.shopizer:shopizer-shipping-distance-processor:jar:0.0.1, javax.ws.rs:jsr311-api:jar:1.1.1, com.mysema.querydsl:querydsl-apt:jar:3.6.6: Could not find artifact com.shopizer:sm-search:jar:0.0.5-SNAPSHOT in org.springframework.maven.snapshot (http://maven.springframework.org/snapshot) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :sm-core

@yuzhiping That doesn't look like a querydsl problem. Please ask questions like that on Stackoverflow.


Port std.zip tests from the dmd test suite to std.zip.

For whatever reason, the dmd test suite has tests for std.zip, though
for the most part, they seem to just run it without actually checking
the results, making them of questionable value. But this commit ports
them to std.zip (to remove a Phobos dependency in the dmd test suite)
and attempts to make it so that they actually check the results. So, the
tests are not identical by any means, but they're similar. Perhaps the
most significant test is the one that tests a file that's written with
std.zip against the unzip utility, since that's testing against
something that we didn't write.
The corresponding PR for dmd to remove the tests from the dmd test suite is here: https://github.com/D-Programming-Language/dmd/pull/4987

LGTM

Auto-merge toggled on


[Update] Replace current.sync with v-model on SfPagination

After some discussions and feedback I decided to use v-model for every data bindings in components (this is what Vue docs are suggesting too).
This task involves changing current.sync prop to v-model in SfPagination component

I can take this one on @filrak


fix(tauri/webview): Use different user_data_path for Windows (#1365)

What kind of change does this PR introduce? (check at least one)

[x] Bugfix
[ ] Feature
[ ] New Binding Issue #___
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes. Issue #___
[x] No

The PR fulfills these requirements:

[x] When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
[x] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
For more details please refer to the issue.

FYI Tested and working fine.


Only generate API and CLI docs on release

There's no point running the slow ./scripts/gendocs/generate script on every build, because the files are already committed to the repository.
We should run that script when necessary and commit the results, which is what I've documented in this PR.
This should speed up the deployment and it should make it clear what is being generated,
vs the current situation where problems with the generated output may go unnoticed unless a developer meticulously checks the CLI and API pages that are published.

$ time ./scripts/build-release
...

Export successful. Files written to /home/richard/projects/cert-manager/website/out

real    0m57.096s
user    4m48.119s
sys     0m27.888s

vs
$ time ./scripts/build-release
...
Export successful. Files written to /home/richard/projects/cert-manager/website/out

real    4m58.418s
user    14m51.916s
sys     2m13.773s

@wallrj is it possible to still check that gendocs are not out-of-date?

@wallrj is it possible to still check that gendocs are not out-of-date in CI?

It is possible, but they never did that. They just regenerated the docs and threw away the results.
https://github.com/cert-manager/website/blob/9f40b713605095d1a0a969ab5d5bda10f8785896/scripts/verify-release
I could add that check as a periodic action, but in another PR.

Thanks @inteon here are my answers:

we don't want to fail unrelated PRs because a new API version was released

That is true, but not related to this PR.
None of the scripts which I deleted or modified in this PR (or in #1177) would have failed if the API version changed.

we will not check anymore that the committed API docs are actually the result of running the generator tool

"anymore" implies that this PR (or #1177) removed such a check, but such a check never existed.
The scripts have never checked whether the committed API docs were out of sync with the APIs.
They simply regenerated them and published them on the website without committing the changes (if there were any).

we don't have to build the API docs for every PR, since they are not supposed to change

(except from when we manually build the API docs)

That is true.

we will have to be more diligent about making sure we manually generate the API docs

That is true. And in this PR I've made it part of the release process that the API and CLI docs should be regenerated,
so that they get updated and committed at release time.

(there will be no non-related PRs that fail automatically)

That was never the case.

@wallrj thank you for the clarifying that I was incorrectly assuming that we checked for outdated docs already.

/lgtm


Feat/season list fix

Fix overflow issue in season list by allowing scroll.

@eliezerben can you merge master

@eliezerben can you merge master

@andreasgan Merged


Performant Mod Incompatibility

Affected Product(s)
SpongeForge
Version
spongeforge-1.16.5-36.2.5-8.0.0-RC1073-universal.jar
Operating System
Windows
Java Version
Adopt OpenJDK Hotspot 1.8.0_322
Plugins/Mods
SpongeForge
Performant (performant-1.16.2-5-3.85m.jar)
Optionally: Not Enough Crashes (notenoughcrashes-4.1.4+1.16.5-forge.jar)

Describe the bug
Originally discovered with not enough crashes -> Loads to menu but all characters are white squares

Testing without Not Enough Crashes caused the game to crash (Shocking isn't it), I have attached the logs from the crash below
Link to logs
https://paste.ee/p/K5J7U

Try this build based off the PR

That's fixed it, thanks for the awesome work!

For reference, build 1.16.5-36.2.5-8.0.0-RC1079 has the fix, no need to use the specific build from the PR ;)


[FP]: MongoDB.Bson identified as MongoDB

Package URl
<EMAIL_ADDRESS>CPE
cpe:2.3:a:mongodb:mongodb:2.22.0:::::::*
CVE
No response
ODC Integration
None
ODC Version
9.0.8
Description
A false positive for the mongodb library (https://github.com/mongodb/mongo) is reported, when in reality it is the MongoDB.Bson NuGet package (https://www.nuget.org/packages/MongoDB.Bson).

@echalone
I'm pretty sure this related to https://github.com/jeremylong/DependencyCheck/issues/6358
We're facing similar problems because the ecosystem of mongodb:mongodb is not consistent for all CPEs

approved


Added basename config

use basename in socket.io path fix #1973
The use of window.location.pathname in the socket.io path (introduced in #1937) broke some modules, because the url was not always the basename of MagicMirror. To resolve this the basename is now a configuration option which can be set in the configuration. The default value is / which results in the behavior as before #1937 was added.

Thanks for this PR. I like this approach, but I'm not sure basename is the best config name. It doesn't explain well what it does. Any other options?

Other name could be basepath or rootpath.

Let’s go for basePath. Could you update the PR?

Yes I can update the PR

sorry, but couldn't test earlier ...
This works for the basic MM installation but still not for modules using own html sites. This should be fixed on module site, but I think we should be backward compatible for the standard use case with basePath="/".
Now the used config object is undefined in the case of MMM-Remote-Control so loading the html page end in a reference error.
So I would prefer a fix like the following in socketclient.js:
  // Private Methods
  var base = "/";
  if (typeof config !== "undefined") {
    base = config.basePath;
  }

  self.socket = io("/" + self.moduleName, {
    path: base + "socket.io"
  });

I think this is a problem of the MMM-Remote-Control it should define the configuration object, or should not load the socketclient.js.

yes, I know this, that was meant by

This should be fixed on module site

but this module (and may others) must be updated and you know not if or when this happens. And meanwhile all users will getting errors using these modules and have again to patch something.
This could be avoided by using / if config is undefined.

@khassel Ok, can you create the PR?

o.k., next evening ...


docs(localdebug): add start local tunnel into cli preview steps

detail: https://msazure.visualstudio.com/Microsoft Teams Extensibility/_workitems/edit/17825928

For other bot samples, will we add local cli part to readme?

For other bot samples, will we add local cli part to readme?

Not all of the templates and samples' readme files include information about the CLI preview process. In the prerelease branch, I'll only fix existing errors related to the CLI local preview steps. The unified readme format will be implemented in the dev branch.

Target v3 branch.

Target v3 branch.

Thx! Updated.


docs: create the openapi spec for the document service

Ticket Number

UCD-1079
Description of change

Create the OpenAPI spec. Published on /api-docs and /api-docs/swagger.json (for the raw JSON)
Checklist

[ ] Requires infrastructure changes
[ ] I have updated the documentation accordingly
[ ] I have merged commits to avoid fixing things in this PR
[ ] New features have tests
[ ] Breaking change (team conversation required)

Important
Please do not merge from master (please only rebase). This keeps the history linear and easier to debug.

Superseded by #201


⚠ Jenkins Plugins Artifactory has degraded performance

In fbc361c, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1231 ms

Resolved: Jenkins Plugins Artifactory performance has improved in c41ddcb after 23 minutes.